Fortigate IPsec Dial-in behind NAT, no outgoing data

[mwillems27]

Hi,

Have an Issue with an IPSec Site-to-Site between set of Fortigate units:

1 x 200E behind a public IP / LAN 10.184.0.0/16

1 x 60F behind a dynamic, natted IP. / LAN 10.151.0.0/16

I'm running 7.0.2

I've established the tunnel, using dial-in from the 60F, all easy enough.

Problem is that it seems no traffic is exiting the 200E, over the tunnel (outgoing data remains at 0).

In the other direction It seems to work fine (so from 60F to 200E)

I've checked policies, and done some packet sniffing, and all the policies are fine, the packets enter the tunnel, I can see this in a sniff capture as well as in the counters of the policies. However, when I sniff on the WAN port, no outgoing data whatsoever. It seems like the data is entering the tunnel but not encapsulated on the WAN port?

This is the Sniffer on the Tunnel IF.

MeetMe-FGT200E # diagnose sniffer packet VPN-TO-Korea
interfaces=[VPN-TO-Korea]
filters=[none]
pcap_lookupnet: VPN-TO-Korea: no IPv4 address assigned
4.932745 10.212.134.201.45392 -> 10.151.100.250.443: syn 2100634384
4.932758 10.212.134.201.45386 -> 10.151.100.250.443: syn 85500106
20.701265 10.212.134.201.58654 -> 10.151.0.1.22: syn 2136697446
21.706119 10.212.134.201.58654 -> 10.151.0.1.22: syn 2136697446
35.072702 10.184.21.249.60313 -> 10.151.0.1.22: syn 765367915
37.359246 10.212.134.201.45386 -> 10.151.100.250.443: syn 85500106
37.359539 10.212.134.201.45392 -> 10.151.100.250.443: syn 2100634384
38.072951 10.184.21.249.60313 -> 10.151.0.1.22: syn 765367915
41.073175 10.184.21.249.60313 -> 10.151.0.1.22: syn 765367915
44.073315 10.184.21.249.60313 -> 10.151.0.1.22: syn 765367915
47.073525 10.184.21.249.60313 -> 10.151.0.1.22: syn 765367915
49.510687 10.212.134.201.37728 -> 10.151.100.250.443: syn 268559521
49.763256 10.212.134.201.37738 -> 10.151.100.250.443: syn 1569137478
50.073776 10.184.21.249.60313 -> 10.151.0.1.22: syn 765367915
50.532805 10.212.134.201.37728 -> 10.151.100.250.443: syn 268559521
50.772685 10.212.134.201.37738 -> 10.151.100.250.443: syn 1569137478
51.546010 10.212.134.201.37728 -> 10.151.100.250.443: syn 268559521
51.785989 10.212.134.201.37738 -> 10.151.100.250.443: syn 1569137478
52.559335 10.212.134.201.37728 -> 10.151.100.250.443: syn 268559521
52.799274 10.212.134.201.37738 -> 10.151.100.250.443: syn 1569137478

Sniffer on the WAN is empty for the gateway destination (173.221.174.130)

Here is the vpn config (omitted keys and changed public ip's:

MeetMe-FGT200E # get vpn ipsec tunnel details

gateway
name: 'VPN-TO-Korea_0'
local-gateway: 173.221.174.132:4500 (static)
remote-gateway: 173.221.174.130:64916 (dynamic)
dpd-link: on
mode: ike-v1
interface: 'wan1' (17)
rx packets: 0 bytes: 0 errors: 0
tx packets: 0 bytes: 0 errors: 0
dpd: on-idle/negotiated idle: 60000ms retry: 3 count: 0
nat traversal mode: silent RFC 3947
selectors
name: 'VPN-TO-Korea'
auto-negotiate: disable
mode: tunnel
src: 0:10.184.0.0/255.255.0.0:0
dst: 0:10.151.0.0/255.255.0.0:0

Am I missing something?

[hhasny]

Hi,

How does the routing table looks? Is the destination correct via the VPN tunnel?

Check this KB article (step 4)and see if it helps if it matches the nexthop/interface and policy matching.

https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-First-steps-to-troubleshoot-connecti...

regards,

[mwillems27]

Hi, First thank you for your reply.

The routing table shows this:

tab=254 vf=0 scope=0 type=1 proto=11 prio=0 0.0.0.0/0.0.0.0/0->10.151.0.0/16 pref=0.0.0.0 gwy=10.151.0.1 dev=41(VPN-TO-Korea)

The gwy ip address seems weird, as I would expect it to use the public IP the DIal-Up Fortigate is NAT'd behind?

It generates this "10.151.0.1" as the first host IP in the remote subnet? This is done automatically when creating a static route with the tunnel IF as outgoing interface.

flow debug result:

MeetMe-FGT200E # 2023-12-14 09:32:59 id=20085 trace_id=301 func=print_pkt_detail line=5783 msg="vd-root:0 received a packet(proto=1, 10.184.21.249:37199->10.151.0.1:2048) from internal. type=8, code=0, id=37199, seq=0."
2023-12-14 09:32:59 id=20085 trace_id=301 func=init_ip_session_common line=5955 msg="allocate a new session-35c97ccd"
2023-12-14 09:32:59 id=20085 trace_id=301 func=iprope_dnat_check line=5213 msg="in-[internal], out-[]"
2023-12-14 09:32:59 id=20085 trace_id=301 func=iprope_dnat_tree_check line=830 msg="len=0"
2023-12-14 09:32:59 id=20085 trace_id=301 func=iprope_dnat_check line=5226 msg="result: skb_flags-02000000, vid-0, ret-no-match, act-accept, flag-00000000"
2023-12-14 09:32:59 id=20085 trace_id=301 func=vf_ip_route_input_common line=2605 msg="find a route: flag=04000000 gw-10.151.0.1 via VPN-TO-Korea"
2023-12-14 09:32:59 id=20085 trace_id=301 func=iprope_fwd_check line=790 msg="in-[internal], out-[VPN-TO-Korea], skb_flags-02000000, vid-0, app_id: 0, url_cat_id: 0"
2023-12-14 09:32:59 id=20085 trace_id=301 func=__iprope_tree_check line=561 msg="gnum-100004, use addr/intf hash, len=3"
2023-12-14 09:32:59 id=20085 trace_id=301 func=__iprope_check_one_policy line=1995 msg="checked gnum-100004 policy-58, ret-no-match, act-accept"
2023-12-14 09:32:59 id=20085 trace_id=301 func=__iprope_check_one_policy line=1995 msg="checked gnum-100004 policy-61, ret-matched, act-accept"
2023-12-14 09:32:59 id=20085 trace_id=301 func=__iprope_user_identity_check line=1816 msg="ret-matched"
2023-12-14 09:32:59 id=20085 trace_id=301 func=__iprope_check_one_policy line=2228 msg="policy-61 is matched, act-accept"
2023-12-14 09:32:59 id=20085 trace_id=301 func=iprope_fwd_check line=827 msg="after iprope_captive_check(): is_captive-0, ret-matched, act-accept, idx-61"
2023-12-14 09:32:59 id=20085 trace_id=301 func=iprope_fwd_auth_check line=846 msg="after iprope_captive_check(): is_captive-0, ret-matched, act-accept, idx-61"
2023-12-14 09:32:59 id=20085 trace_id=301 func=fw_forward_handler line=869 msg="Allowed by Policy-61:"
2023-12-14 09:32:59 id=20085 trace_id=301 func=ipsecdev_hard_start_xmit line=625 msg="enter IPSec interface VPN-TO-Korea"
2023-12-14 09:33:01 id=20085 trace_id=302 func=print_pkt_detail line=5783 msg="vd-root:0 received a packet(proto=1, 10.184.21.249:37199->10.151.0.1:2048) from internal. type=8, code=0, id=37199, seq=256."
2023-12-14 09:33:01 id=20085 trace_id=302 func=resolve_ip_tuple_fast line=5864 msg="Find an existing session, id-35c97ccd, original direction"
2023-12-14 09:33:01 id=20085 trace_id=302 func=npu_handle_session44 line=1161 msg="Trying to offloading session from internal to VPN-TO-Korea, skb.npu_flag=00000400 ses.state=00000204 ses.npu_state=0x00000000"
2023-12-14 09:33:01 id=20085 trace_id=302 func=fw_forward_dirty_handler line=396 msg="state=00000204, state2=00000001, npu_state=00000000"
2023-12-14 09:33:01 id=20085 trace_id=302 func=ipsecdev_hard_start_xmit line=625 msg="enter IPSec interface VPN-TO-Korea"
2023-12-14 09:33:03 id=20085 trace_id=303 func=print_pkt_detail line=5783 msg="vd-root:0 received a packet(proto=1, 10.184.21.249:37199->10.151.0.1:2048) from internal. type=8, code=0, id=37199, seq=512."
2023-12-14 09:33:03 id=20085 trace_id=303 func=resolve_ip_tuple_fast line=5864 msg="Find an existing session, id-35c97ccd, original direction"

[hbac]

Hi @mwillems27,

Based on the outputs, traffic was Allowed by Policy-61. Can you run the same debug and sniffer on the remote FortiGate to see if it receives the traffic or not. Please also check if npu-offload is enabled or not by running 'show full vpn ipsec phase1-interface'. 

Regards, 

[mwillems27 · Accepted solution]

Hi @hbac 

Just solved the issue by adding a static route in CLI, using as next-hop the Public IP the Dial-in is natted behind. It seems the next-hop the GUI wizard for static routes generates is incorrect?

Only strange thing is that I would expect the Fortigate to do this dynamically?

SInce now this will have to be changed manually when moving to a different location?