no session match

Forum|Forum|14 years ago
May 12, 2012
8 replies
8880 views

Hi, Any body know this weird behavior? We have the VIP setting for the address and setup a policy to allow the traffic to pass from the internal to external. But whenever our user initiate the connection, they got the below message. Log Number 2 Last Activity 2012-05-11 17:23:46 Device ID xxxxx Type traffic Level warning Status [deny] Src 192.168.x.x Dst 211.xx.xxx.xx Service HTTPS Sent 0 B Received 0 B Destination Country United States VDom root Serial Number 4294xxxxx Duration 0 User N/A Group N/A Rule 0 Policy ID 0 Protocol 6 Log ID 7 Device Time 2012-05-11 16:23:46 Src Name 192.168.x.x Cluster ID FG300B3910603647_CID Dst Name 211.xx.xxx.xx Src Interface port5 Dst Interface N/A Subtype other Sent Packets 0 Received Packets 0 LAN In 0 LAN Out 0 WAN In 0 WAN Out 0 Src Port 53909 Dst Port https VPN N/A Dst NAT Port 0 Src NAT Port 0 Carrier End Point N/A Application Type N/A Application N/A Application Category N/A Shaper Dropped Sent Bytes 0 Shaper Dropped Received Bytes 0 Sent Traffic Shaper Name N/A Rcvd Traffic Shaper Name N/A Per-IP Shaper Name N/A Per-IP Shaper Bytes Dropped 0 VPN Type ipsec-static Message no session matched Identity Index 0 VPN Tunnel N/A Profile Group Name N/A 8 Empty fields (Show) Any feedback would be greatly appreciated. Regards,

jeff_richeson

New Member

Did you ever get a resolution to this problem? We are seeing lots of this in our logs.

ede_pfau

SuperUser

This message indicates that the traffic didn' t match ANY policy and was discarded by the last, implicit DENY policy. Watch out for the ' policy ID 0' line - no policy matching.

seadave

New Member

Right, but the question is why? I have one rule setup that inspects traffic, IDS/IPS, AV, the works. I have another rule that allows ALL to ALL outbound NAT' d, no filters. If I use my no filtering rule then the " no session matched" errors are less prevalent (as one would expect), but if I use my filtering rule then I get a ton of these and browsing is slower for the users and some pages take longer to load. One persistent target being blocked I see is 1e100 hosts which is google. Another strange issue is I see lots of traffic to one of our file servers being blocked. I' m at a remote site communicating through a FG-100D over policy based IPSec VPN to FG-110C. I have a policy setup that says all traffic from my remote LAN should be able to communicate with anything in at /16 private range over the IPSec link. It works as expected. I can ping, and browse these remote hosts without any problem, but if I look in my logs I see a ton of the " no session matched" messages for SAMBA to the host that I am browsing. Another host that has our AV management system installed shows " org dir, ack in state syn_sent, drop" blocks. I' m confused as I have a rule that says " allow everything back and forth" over the IPSec VPN, but the Fortigate is blocking some of it for some reason. I' ve attached a log if anyone cares to take a look. The WAN IP noted in the log is fake for the purpose of site privacy. The attached log file is a ZIP file. Replace .txt with .zip to extract. I find using Notepad++ makes the file clean and readable. Notepad will not wrap correctly. I do see in that log a few unauthorized telnet attempts from Poland and India. People are always probing :)

Mk25257.txt

ede_pfau

SuperUser

In the logs, I see 172.19.0.1 on port1 sending to 172.16.10.12 to an unknown interface. Can you clarify how this traffic flows across the FGT?

seadave

New Member

The traffic from 172.19.0.1 is flowing over a policy based IPSec VPN connection. 172.19.0.1 is the IP of one of my VLAN. I have VLAN routing enabled on my switches. 172.19.0.1 routes to an interface in my core with an IP of 172.31.0.2 with has a route of last resort to 172.31.0.1 which is the Internal port of the FG-100D. There is an IPSec policy setup that says all traffic bound for 172.16.0.0/16 should flow over the IPSec VPN. On the remote side the Internal interface is 172.16.14.1/16 and 172.16.10.12 is a file server. Hope that makes sense. What is the " subnet overlap routing issue" that Phuoc Ngo, identifies? A simple IP addressing issue, or is there a bug that I' m not aware of?

Phuoc_NgoAuthor

New Member

Yes, sorry. we was able to identify the issue and fix it. It was the subnet overlap routing issue. We didn' t have subnet overlapping set. Regards,

ede_pfau

SuperUser

Ahem, Phuoc and David, are we talking about the same network? Are we talking about YOUR network then? Apart from that confusion, I' ve had a look into the logfile. For example,

 2012-11-11 15:28:40 log_id=0038000007 type=traffic subtype=other pri=warning   status=deny vd=" root"  src=172.19.0.11 srcname=172.19.0.11 src_port=49374   dst=172.16.10.12 dstname=172.16.10.12 dst_country=" Reserved"  src_country=" Reserved"    dst_port=139 service=SAMBA proto=6 app_type=N/A duration=19 rule=2 policyid=2   identidx=0 sent=0 rcvd=0 shaper_drop_sent=0 shaper_drop_rcvd=0 perip_drop=0   shaper_sent_name=" N/A"  shaper_rcvd_name=" N/A"  perip_name=" N/A"  vpn=" N/A"    vpn_type=UNKNOWN(65535) vpn_tunnel=" N/A"  src_int=" port1"  dst_int=" wan1"    SN=1343653 app=" N/A"  app_cat=" N/A"  user=" N/A"  group=" N/A"  msg=" org dir, ack in state   syn_sent, drop"  carrier_ep=" N/A"  profilegroup=" N/A"  subapp=" N/A"  subappcat=" N/A"

looks pretty OK. This is traffic aimed at the remote network behind a VPN tunnel when the tunnel is down. Instead of the tunnel interface traffic is routed to the wan1 interface via the default route. If you don' t want this to happen you can install ' black hole routes' for all RFC1918 private address spaces. You' ll find a post about this in the forums. Now, there' s the other type of error like this one:

 2012-11-11 15:26:40 log_id=0038000007 type=traffic subtype=other pri=warning status=deny   vd=" root"  src=172.19.0.11 srcname=172.19.0.11 src_port=49362 dst=172.16.10.12   dstname=172.16.10.12 dst_country=" Reserved"  src_country=" Reserved"  dst_port=139   service=SAMBA proto=6 app_type=N/A duration=0 rule=0 policyid=0 identidx=0 sent=0 rcvd=0   shaper_drop_sent=0 shaper_drop_rcvd=0 perip_drop=0 shaper_sent_name=" N/A"    shaper_rcvd_name=" N/A"  perip_name=" N/A"  vpn=" N/A"  vpn_type=UNKNOWN(65535)   vpn_tunnel=" N/A"  src_int=" port1"  dst_int=" N/A"  SN=0 app=" N/A"  app_cat=" N/A"    user=" N/A"  group=" N/A"  msg=" no session matched"  carrier_ep=" N/A"  profilegroup=" N/A"    subapp=" N/A"  subappcat=" N/A"

where I suspect that the traffic is a broadcast, not addressing any specific target address so the FGT doesn' t know where to route it. The SAMBA service led me to this conclusion. As such, this event is to be expected. There is a CLI only parameter in the interface setup which allows/denies netbios broadcast traffic:

 config sys interface     ...     set netbios-forward enable/disable  end

You may experiment with it to see if you get less logs. Coming to logging. I remember a logging command enabling logs for denied traffic to the FGT which is rarely used...I found it:

 config sys global      set fwpolicy-implicit-log enable      set fwpolicy6-implicit-log disable      set loglocaldeny disable

I would set ' loglocaldeny' to disable first, before starting to fiddle with the netbios setting. HTH

Phuoc_NgoAuthor

New Member

Sorry for the confusion. I am referring to our network configuration side. Our VPN subnet is configure to share the same subnet range with one of our internal test subnet. Hope this give some clarification to my response.

Sign up

Login with SSO

Login to the community

Login with SSO