"No matching IPsec selector, drop" - bad Tunnel Selection

[Phinestra200]

Hi All,

i've recently setup a New  site-to-site VPN Tunnel  Tunnel Mode on our 200D, in 5.4.

Tunnel is Up and Running and i'm able to reach the remote FW  in https and remote Users are Able to reach Local resources.

but, but....

Here is my issue :

there is an UDP traffic which not working correctly, namely SIP traffic (5060).

i'm able to see the Original direction going throuh different VDOMs, but the reply direction on the last VDOM going through the bad Tunnel IPsec and the IP phoone never succeed in registration.

already check diag sni pack during while pinging --> ok

already check diag debug flow while pinging and it is matching the good tunnel :(

already check diag debug flow to see what happens ( UDP 5060 traffic)--> some traces

id=20085 trace_id=2116 func=print_pkt_detail line=4751 msg="vd-VPN received a packet(proto=17, 192.168.XXX.2:5060->192.168.200.XXX:5060) from FWA-FWB. " id=20085 trace_id=2116 func=resolve_ip_tuple_fast line=4815 msg="Find an existing session, id-000574d4, original direction" id=20085 trace_id=2116 func=npu_handle_session44 line=904 msg="Trying to offloading session from FWA-FWB to VPN-jun, skb.npu_flag=00000400 ses.state=00000010 ses.npu_state=0x00040000" id=20085 trace_id=2116 func=__ip_session_run_tuple line=2790 msg="run helper-sip(dir=original)" id=20085 trace_id=2116 func=ipsec_tunnel_output4 line=1176 msg="enter IPsec tunnel-VPN_site1" id=20085 trace_id=2116 func=ipsec_common_output4 line=766 msg="No matching IPsec selector, drop"

as you can see, the traffic going through tunnel VPN_site1 instead of my VPN_site2 which is temporarily down.

how this can be possible?

what another i can check  ?

how to solve this?

thanks in advance for any help.

Regards,

Phi.

[Phinestra200 · Accepted solution]

HI All,

After several Checks, I finally solved my issue.

A first VPN Tunnel (VPN_site1) was set up with An Any/Any phase 2 subnets ( Local and remote)

the second tunnel ( VPN_site2) was set up in first with the same full permissive Phase 2 and then adjust to the appropriate Local and remote Subnets.

the reply UDP 5060 traffic  was going through the first Phase 2 ( VPN_site2).

I changed the Phase 2 of VPN_site1 with the only ones conerned, then reset all session comming from the remote subnet of VPN_site2

--> BINGO!!!

actions:

diagnose sys session filter clear  --> TO clear any filter apply diagnose sys session filter src 192.168.X.X --> add a filter for my SIP session only diagnose sys session list --> check that the filter is applied diagnose sys session filter clear --> clear the session so that to re-establish traffic on the good Tunnel

Then i checked my flows :

diag debug reset --> to reset any current traffic debug.

diag debug flow filter add 192.168.X.X diag debug flow show console enable diag debug flow trace start 100 diag debug enable

!!!! Do not forget to Disable debug!!!

diag debug or di de di

So in my case, the "No matching IPsec selector, drop"  was due to the fact that the not only the traffic was going through the bad Tunnel VPN policy, but only because this Tunnel VPN was Down.

Hope this Help Anyone!

PHI.

[Marcvbuuren]

Life can be so simple sometimes.

I had the same message as above, i test these connections from the command-line at the remote Fortigate.

Turns out that the default source interface on a Fortigate can sometimes be different than you expect.

So i was testing this from the wrong source-interface from a subnet that was not part of the IPsec setup.

Setting the exe ping-options to the right source-interface fixed it.

Just as tip for anyone who runs into it.

Regards,

Marc.

[José_Oliveira]

For this problem I solved by adding the network I wanted to reach / communicate in Phase II of VPN.

Best regards.

[emnoc]

Are this route-based? The route determine what tunnel it's going thru and you could have only use quad 0s ( aka 0.0.0.0/0 ) for the src-dst subnets

Whatever you do, the traffic selectors has to match the remote end.

Ken Felix

[hljunior]

Forgive for my bad english.
I had a same problem.
The solution in my case is:
config system sdwan
config zone
edit "virtual-wan-link"
next
end
config members
edit 1
set interface "MY_VPN"
set source 192.168.100.1 ## this IP address is the same of LAN interface
next
end
end