" No matching IPsec selector, drop"

[zmag]

FG 620B 4.0 MR2 patch 1 Interface mode IPsec Trying to bring IPsec tunnels up. the monitor show the tunnel is up. No traffic (echo) is passing. First step was; chifgt02 (root) # diagnose sniffer packet any " host 192.168.37.150 or host 10.x.x.x" 4 ****started ping from 37.150 >10..x.x.x now*************** interfaces=[any] filters=[host 192.168.37.150 or host 10.66.6.14] 3.376838 port1 in 192.168.37.150 -> 10..x.x.x: icmp: echo request 8.877053 port1 in 192.168.37.150 -> 10..x.x.x: icmp: echo request 14.376863 port1 in 192.168.37.150 -> 10..x.x.x: icmp: echo request 19.877578 port1 in 192.168.37.150 -> 10..x.x.x: icmp: echo request 4 packets received by filter 0 packets dropped by kernel So this indicates the firewall sees the traffic, not sure what else this tells me. second step; chifgt02 (root) # diagnose sniffer packet any " host 192.168.37.150 or host 10..x.x.x or arp" 4 I see no references to 10..x.x.x third step; chifgt02 (root) # diag debug enable chifgt02 (root) # diag debug flow filter add 192.168.37.150 chifgt02 (root) # diag debug flow show console enable show trace messages on console chifgt02 (root) # diag debug flow trace start 100 chifgt02 (root) # diag debug enable ****START PING NOW FROM 37.150 > 10.x.x.x*********** chifgt02 (root) # id=36870 trace_id=1 msg=" vd-root received a packet(proto=1, 192.168.37.150:512->10.x.x.x:8) from por t1." id=36870 trace_id=1 msg=" allocate a new session-000c8cd6" id=36870 trace_id=1 msg=" find a route: gw-10.x.x. via meditech" id=36870 trace_id=1 msg=" Allowed by Policy-114:" id=36870 trace_id=1 msg=" enter IPsec interface-meditech" id=36870 trace_id=1 msg=" No matching IPsec selector, drop" id=36870 trace_id=2 msg=" vd-root received a packet(proto=1, 192.168.37.150:512->10.x.x.:8) from port1." id=36870 trace_id=2 msg=" Find an existing session, id-000c8cd6, original direction" id=36870 trace_id=2 msg=" enter IPsec interface-meditech" id=36870 trace_id=2 msg=" No matching IPsec selector, drop" 4th step; I looked at my P2 Quick Mode Selector which is chifgt02 (meditech_2) # set dst-addr-type name chifgt02 (meditech_2) # set dst-name vpn_remote_meditech chifgt02 (meditech_2) # set src-addr-type name chifgt02 (meditech_2) # set src-name vpn_local_meditech I think this is my problem? I have seen people suggest to set these to 0.0.0.0/0.0.0.0 and filter at the policy but I think this will fail if the set up on the other side of the tunnel (which I don' t manage) is not the same. I deleted this P2 and created a new one with all 0s, this time the tunnel would not come up. The debug showed something to the effect of SA is not ready, sorry i didn' t save that output. I changed P2 back to chifgt02 (meditech_2) # set dst-addr-type name chifgt02 (meditech_2) # set dst-name vpn_remote_meditech chifgt02 (meditech_2) # set src-addr-type name chifgt02 (meditech_2) # set src-name vpn_local_meditech Am I misunderstanding the Quick Mode Selector? I am wondering why it has a static source and static dst since it seems to me that i would need 2 selectors, one for each direction. I will re-read the guides and forum posts, but hopefully someone can tell me if I' m on the right track. Thanks in advance

[zmag]

some more info - In CLI: * diag debug app ike -1 * diag debug ena h:21526:22769: responder received first quick-mode message ike 0:meditech:21526: received notify type 24578 ike 0:meditech:21526:22769: peer proposal is: peer:0:10.66.4.74-10.66.4.74:0, me:0:192.168.40.140-192.168.40.140:0 ike 0:meditech:21526:22769: trying meditech_2 ike 0:meditech:21526:22769: no matching phase2 found ike 0:meditech:21526:22769: failed to get responder proposal ike 0:meditech:21526: error processing quick-mode msg from 199.26.x.x as responder ike 0: comes 199.26.x.x:500->12.178.80.242:500,ifindex=21.... ike 0: IKEv1 exchange=Quick id=be8c7eb7ed609079/a5b369c213e735c1:159fe787 len=164 ike 0: found meditech 12.178.80.242 21 -> 199.26.x.x:500 ike 0:meditech:21526:22770: responder received first quick-mode message ike 0:meditech:21526:22770: peer proposal is: peer:0:10.66.4.75-10.66.4.75:0, me:0:192.168.40.156-192.168.40.156:0 ike 0:meditech:21526:22770: trying meditech_2 ike 0:meditech:21526:22770: no matching phase2 found ike 0:meditech:21526:22770: failed to get responder proposal ike 0:meditech:21526: error processing quick-mode msg from 199.26.x.x as responder

[zmag]

What the heck, Ill keep going. I was able to verify the issue is my quick mode selector addresses. I get one good P1 followed by many failed P2s. As a test I populated QM source address = single local host destination address = single remote host and I was able to connect. If i leave them open it fails and if I fill in the address group I' ve created it also fails. The address groups are called vpn_local_meditech and vpn_remote_meditech Each group is populated with all /32 hosts addresses I know in our Check Point there is an option to create 1 vpn tunnel per subnet pair or 1 per gateway pair or 1 per each pair of hosts. They call it VPN tunnel sharing. Is there a similar setting in Fortigate? As always thanks in advance.

[rwpatterson]

From what I recall, groups are not widely used between vendors. Stick with subnets, you should be OK.

[TopJimmy]

We are having the same problem building an IPSec tunnel from my end (FGT800s running 4.2.x) to a Checkpoint appliance on the remote end. Not sure what model or version but I' m getting the same errors in the ike debug. No matching phase 2 and failed to get responder proposal. My problem is compounded in that I have upwards to 30 subnets on my end (dmz, internal, etc) that would talk with the the subnet on the Checkpoint end. Setting up quick-mode selectors is a bit confusing for me and I really don' t understand what they do and why it' s not working leaving them at 0.0.0.0/0. Any suggestions?

[emnoc]

Believe it or not, but I' m turning up a ipsec tunnel to a checkpoint right at this very moment. We are not using qm selectors of 0.0.0.0/0 but have defined all of the local local/remote subnets. In our case, we are defining a summary 10.88.9.0/20 for my address in my p2 configuration. The chkpt appliance has the same define on his end, so our configuration is quite small and simpler. In my understanding, QM selectors of 0.0.0.0/0 is only good when you have a simular fgt on both ends or a netscreen-fw. This sucks when you have multiple subnets, but when the SA proposal is looked up, it has to match both sides when you go to a non-Fortigate firewall. If they don' t , then you will get the dread no " matching SA proposal. You can check the CPUG group for more examples and discussion on this subject.

[emnoc]

Oh btw, I liked your troubleshooting methodology and logic. You don' t see too many person doing it when they have a VPN problem nowadays. Typically you get, my vpn doesn' t work and what should I look at

[TopJimmy]

can you specify part of the quick-mode selector section? What I mean is can I define the destination (their end with only the one subnet) but not the source section (our end with dozens of subnets) and have it work properly?

[emnoc]

I would probably say that would not work, but give it a try if you want to experiment.Have you checked out the CPUG forum?

[TopJimmy]

we got it working tonight. as long as your Fortinet quick mode selector source is set to the Checkpoints encryption domains destination and your quick mode selector destination is set to the encryption domains source, you are good to go.