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

New Member
  • Total Posts : 10
  • Scores: 0
  • Reward points: 0
  • Joined: 2018/02/13 00:53:44
  • Status: offline
2018/05/03 03:14:30 (permalink) 5.4

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

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.

2 Replies Related Threads

    New Member
    • Total Posts : 10
    • Scores: 0
    • Reward points: 0
    • Joined: 2018/02/13 00:53:44
    • Status: offline
    Re: "No matching IPsec selector, drop" - bad Tunnel Selection 2018/05/16 06:22:53 (permalink)
    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!!!
    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!
    post edited by Phinestra200 - 2018/05/16 06:25:51
    New Member
    • Total Posts : 1
    • Scores: 0
    • Reward points: 0
    • Joined: 2018/09/13 13:49:41
    • Status: offline
    Re: "No matching IPsec selector, drop" - bad Tunnel Selection 2019/05/17 23:53:21 (permalink)
    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.
    Jump to:
    © 2019 APG vNext Commercial Version 5.5