VPN communication problem between firewalls

[IT_Network]

Hello everyone, I can't figure out a problem .. I have a configuration of 2 fortigate 80c clusters connected via VPN, from the network of site A I reach the VPN network of site B and there the opposite.

If from the firewall of site B where some services are published on the servers of site A, I try to reach any IP of the network of site A, this drops the packets ..., from the debug log I have an error "msg =" No matching IPsec selector, drop "", I checked phase 1 and 2 of both firewalls and networks match.

the strange thing is that if from the fortigate of site B I do a ping to an internal IP of the network of site A I do not go out, all packets expire.

from the log I see that the request is not made by the private IP of the firewall but by its public ip, I am attaching the stamp log.

I know the explanation is complex, I ask you for support. Thanks

[SankaraNarayanan_S]

Kindly Do the following :

Re-Check : IPSEC Tunnels phase2 IP selectors settings for both site A and Site B .

Check the access policies for the IPSEC VPN Tunnel ,If it requires any NAT configuration for the VPN based access policies .

Please check if this resolves your issue.

[IT_Network]

I have already checked everything and I do not find any anomalies, I do not explain why if I try to reach an IP of the destination network from the firewall B, it proposes me as the public IP and not the private one, the NAT is configured correctly.

id = 20085 trace_id = 20 func = print_pkt_detail line = 4489 msg = "vd-root received a packet (proto = 1, 85.34.xx.xx: 3840-> 10.9.xx.xx: 8) from local. code = 8, type = 0, id = 3840, seq = 1024. "

Now I had to go back through the MPLS network, but since this type of network will be decommissioned, I will try the VPN again as soon as possible.

Do you have any other suggestions?

[Jess07]

When I use my Verizon MiFi device, and sometimes when I VPN to work from my mother's place, I experience a similar problem with the old client, which I believe has something to do with her ISP. With 'crypto isakmp nat-traversal 25', I was able to solve it.

The default value is 20, but because that doesn't show up in the config, I changed it to something else.

[leszek]

You should set source interface. There is proto=1 (icmp) in your example so you have to set source by entering this command:

exec ping-options source [here ip of some internal iface]

The same story is with other services where FGT can be configured as a client- there is always option like "set source-ip" to explicit set source interface.

BTW: When you not set source ip FGT sends packets from interface taken from routing table. In your case FGT should use ip of VPN interface. Why FGT uses WAN ip address? Maybe your VPN iface has no ip address or there is some issue with routing table etc.

Best regards

L.

[IT_Network]

Hello again, I have migrated the services to another firewall and now I am struggling to fix the VPN problem, starting from the last post now I have turned everything around by changing the routes and policies etc .. everything works as before, ie the clients of SITE B reach all PCs / DEVICES of SITE A and vice versa but if I try to reach any device of site A from the firewall of site A, the files are DROPPED, I am attaching the stamp log. I don't know what to check anymore ..., it seems that pinging from the SITE B firewall an IP of SITE A takes the default and not the VPN interface. Thanks for support

From CLIET SITE_B to IP SITE_A -> OK id=20085 trace_id=91 func=resolve_ip_tuple_fast line=4552 msg="Find an existing session, id-00003974, original direction" id=20085 trace_id=91 func=ipsecdev_hard_start_xmit line=121 msg="enter IPsec interface-VPN_SITE_B" id=20085 trace_id=91 func=esp_output4 line=899 msg="encrypting, and send to 62.xx.xx.xx with source 85.xx.xx.xx" id=20085 trace_id=91 func=ipsec_output_finish line=232 msg="send to 85.xx.xx.xx via intf-wan1" id=20085 trace_id=92 func=print_pkt_detail line=4489 msg="vd-root received a packet(proto=1, 10.9.xx.xx:1->10.20.xx.xx:0) from VPN_SITE_B. code=0, type=0, id=1, seq=10446." id=20085 trace_id=92 func=resolve_ip_tuple_fast line=4552 msg="Find an existing session, id-00003974, reply direction"

From FORTIGATE SITE_B to IP SITE_A -> DROP id=20085 trace_id=98 func=print_pkt_detail line=4489 msg="vd-root received a packet(proto=1, 85.xx.xx.xx:3584->10.9.xx.xx:8) from local. code=8, type=0, id=3584, seq=256." id=20085 trace_id=98 func=resolve_ip_tuple_fast line=4552 msg="Find an existing session, id-00003c73, original direction" id=20085 trace_id=98 func=ipsecdev_hard_start_xmit line=121 msg="enter IPsec interface-VPN_SITE_B" id=20085 trace_id=98 func=ipsec_common_output4 line=625 msg="No matching IPsec selector, drop"

[IT_Network]

some idea? I tried to ping from the firewall by modifying the source and I reach the devices.

Strange thing is that on the other firewall without setting the ping interface I can still reach the firewall.

I try to post the configuration you tell me if you find something abnormal .. Let me know, thanks Routing:

S* 0.0.0.0/0 [10/0] via 85.xx.xx.xx, wan1 S 10.9.0.0/16 [10/0] is directly connected, VPN_Site_A C 85.xx.xx.xx/28 is directly connected, wan1 S 192.168.9.0/24 [10/0] is directly connected, VPN_Site_A VPN Config:

show vpn ipsec phase1-interface VPN_Site_A config vpn ipsec phase1-interface edit "VPN_Site_A " set interface "wan1" set ike-version 2 set keylife 28800 set proposal aes128-sha256 aes256-sha256 set dhgrp 14 set remote-gw 62.xx.xx.xx set keepalive 15 next

show vpn ipsec phase2-interface VPN_Site_A config vpn ipsec phase2-interface edit "VPN_Site_A" set phase1name "VPN_Site_A" set proposal aes128-sha1 aes256-sha1 set dhgrp 5 set keepalive enable set auto-negotiate enable set src-addr-type name set dst-addr-type name set keylifeseconds 28800 set src-name "VPN_Local_IP" -> subnet group (10.20.0.0/16 and 192.168.20.0/24) set dst-name "VPN_Remote_IP" -> subnet group (10.9.0.0/16 and 192.168.9.0/24) next end

Policy:

edit 43 set srcintf "internal" set dstintf "VPN_Site_A" set srcaddr "VPN_Local_IP" -> subnet group (10.20.0.0/16 and 192.168.20.0/24) set dstaddr "VPN_Remote_IP"-> subnet group (10.9.0.0/16 and 192.168.9.0/24) set action accept set schedule "always" set service "ALL" set logtraffic all next edit 44 set srcintf "VPN_Site_A" set dstintf "internal" set srcaddr "VPN_Remote_IP"-> subnet group (10.9.0.0/16 and 192.168.9.0/24) set dstaddr "VPN_Local_IP" -> subnet group (10.20.0.0/16 and 192.168.20.0/24) set action accept set schedule "always" set service "ALL" set logtraffic all next

[leszek]

so if setting source ip works but it does not meet your requirements then simple give ip address on both sides of your tunnel.

for example on one side:

config system interface

edit [your vpn interface]

set ip 10.30.1.1 255.255.255.255

set remote-ip 10.30.1.2 255.255.255.252

and on other side:

set ip 10.30.1.2 255.255.255.255

set remote-ip 10.30.1.1 255.255.255.252

best regards

L

[GGUSMC]

In your security policy under action select IPSEC and then select the VPN tunnel that you would like to use for the traffic. 

[ede_pfau]

@GGUSMC: what you describe is a policy-based VPN. OP is using an interface-based VPN, which is used in 99% of all cases today. Besides, a policy-based VPN would not resolve the issue.

@OP: in your first post you wrote that NAT would be used. Hopefully, you use it only on the internal->WAN policy, not on the policy towards the VPN.

I would use wildcards in the phase2 QM descriptors ('0.0.0.0/0'), on both sides, which enable the tunnel negotiations for any destination address. This will work for FGT-to-FGT VPNs easily, but not against other vendor's firewalls.

Seeing that traffic is sent out to the WAN interface is no surprise if the tunnel is down. So the debugging focuses on tunnel setup. Once the tunnel is up, you should not see any traffic leaking to the WAN interface - the routing looks OK.