VPN Traffic Not Leaving FortiGate

[rharms_tarc]

I'm working on setting up an IPSEC VPN tunnel between a remote cellular router (Digi TX64) and the FortiGate 300E at our headquarters. 

I've got the tunnel up and stable, but can't seem to get traffic to flow properly.  If I run a ping from a device behind the Digi to a device behind the FortiGate, I can run packet sniffer on the FortiGate and see the ping packets coming into the FortiGate from the VPN interface, but I never see them leave the FortiGate to go on to the actual host. 

Once I get the formula for this sorted out, I get to duplicate it about 180 times for routers across our bus fleet.  All of the bus routers use the same 192.168.x.0/24 internal subnet, so I need to NAT the traffic as it is passing through the FortiGate into our main network, and then reverse that as it passes back through the FortiGate to return to the bus.  I also need to ensure that NAT is always one-to-one such that traffic from a specific 192.168.x.0 address will always translate to the same address and vice versa.

I've pasted the relevant config snippets below.  Guessing it's something simple that I'm not seeing, so would appreciate some fresh eyes.

config firewall policy
  edit 141
    set name "From-Coach-2xxx"
    set uuid 53513b9a-eb35-51ef-7e8b-5acxxxxxxxx
    set srcintf "Coach-2xxx-VPN"
    set dstintf "LAN-ZONE"
    set action accept
    set srcaddr "all"
    set dstaddr "all"
    set schedule "always"
    set service "ALL"
    set utm-status enable
    set ssl-ssh-profile "SSL-INSPECTION"
    set av-profile "default"
    set dnsfilter-profile "default"
    set application-list "Monitor-and-Block-Botnets"
    set nat enable
    set fixedport enable
    set ippool enable
    set poolname "Coach-2xxx-Inbound"
  next
end

config firewall policy
  edit 142
    set name "To-Coach-2xxx"
    set uuid b642e94c-eb35-51ef-d7ab-f545xxxxxxxx
    set srcintf "LAN-ZONE"
    set dstintf "Coach-2xxx-VPN"
    set action accept
    set srcaddr "all"
    set dstaddr "Coach-2xxx-Outbound"
    set schedule "always"
    set service "ALL"
    set utm-status enable
    set ssl-ssh-profile "INSPECTION"
    set av-profile "default"
    set dnsfilter-profile "default"
    set application-list "Monitor-and-Block-Botnets"
  next
end

config firewall vip
  edit "Coach-2xxx-Outbound"
    set uuid 0bb2482e-eb35-51ef-f975-c48axxxxxxxx
    set extip 10.2x.5x.0-10.2x.5x.255
    set mappedip "192.168.x.0-192.168.x.255"
    set extintf "any"
    set nat-source-vip enable
    set color 19
  next
end

config firewall ippool
  edit "Coach-2xxx-Inbound"
    set type one-to-one
    set startip 10.2x.5x.0
    set endip 10.2x.5x.255
  next
end

config router static
  edit 18
    set dst 10.2x.5x.0 255.255.255.0
    set distance 1
    set device "Coach-2xxx-VPN"
  next
end

[Toshi_Esumi]

The config is the same I would configure in case SNAT on the VPN at TX64 is absolutely not an option. And, based on your description, the inbound SNAT policy is not working as you intended.

In that case, you need to run flow debugging to see how the FGT is treating the inbound packets with the policy.
I would run like.
   diag debug reset
   diag debug flow filter addr 192.168.x.x(source IP)
   diag debug flow trace start 10 (or how many more flows you want to capture)
   diag debug enable

You need to run the debug first, then start pinging from the client side. Otherwise, it would be sent to NPU and show like "found an existing session" only for every incoming packet.

Toshi

[rharms_tarc]

Here is an excerpt from the debug:

id=20085 trace_id=33 func=print_pkt_detail line=5867 msg="vd-root:0 received a packet(proto=1, 192.168.x.100:1->10.xxx.100.86:2048) tun_id=10.0.0.7 from Coach-2xxx-VPN. type=8, code=0, id=1, seq=18870."
id=20085 trace_id=33 func=init_ip_session_common line=6046 msg="allocate a new session-70992410, tun_id=10.0.0.7"
id=20085 trace_id=33 func=ip_route_input_slow line=2267 msg="reverse path check fail, drop"
id=20085 trace_id=33 func=ip_session_handle_no_dst line=6132 msg="trace"
id=20085 trace_id=36 func=print_pkt_detail line=5867 msg="vd-root:0 received a packet(proto=1, 192.168.x.100:1->10.xxx.100.86:2048) tun_id=10.0.0.7 from Coach-2xxx-VPN. type=8, code=0, id=1, seq=18871."
id=20085 trace_id=36 func=init_ip_session_common line=6046 msg="allocate a new session-70992600, tun_id=10.0.0.7"
id=20085 trace_id=36 func=ip_route_input_slow line=2267 msg="reverse path check fail, drop"
id=20085 trace_id=36 func=ip_session_handle_no_dst line=6132 msg="trace"
id=20085 trace_id=38 func=print_pkt_detail line=5867 msg="vd-root:0 received a packet(proto=1, 192.168.x.100:1->10.xxx.100.86:2048) tun_id=10.0.0.7 from Coach-2xxx-VPN. type=8, code=0, id=1, seq=18872."
id=20085 trace_id=38 func=init_ip_session_common line=6046 msg="allocate a new session-70992786, tun_id=10.0.0.7"
id=20085 trace_id=38 func=ip_route_input_slow line=2267 msg="reverse path check fail, drop"
id=20085 trace_id=38 func=ip_session_handle_no_dst line=6132 msg="trace"

So it looks like the problem is failing the reverse path check.  From reading, it seems like I need to give it a route for those 192.168.x.0/24 addresses.  But not sure how to set that up being that I'm going to have traffic for that same subnet coming in from 180 different VPN tunnels.

[Toshi_Esumi]

so, this means the FGT receives the packet from 192.168.x.100, and it drops the packet because there is no route to go back to the tunnel for 192.168.x.100.
I'm not sure how to avoid that in case all VPNs have the same destination subnet.
First, try setting a static route into the tunnel for 192.168.x.0/24 to make sure it works with the route.

Then, if it works as you intended, you need to set up a second tunnel to the second TX64 and put in the EXACT same static route to the second tunnel as well. It would show up as a parallel route with the first one. I'm hoping the FGT takes it as is not to drop the second tunnel traffic.


Toshi

[sw2090]

you could use dial up ipsec instead of s2s here. Then you won't need to deduplicate the vpn at all.

You would only need to route 192.168.0.0/16 via the vpn and maybe set proper quickselectors in phase2.

Then you must only make sure your policies (and vips) match all the coaches subnets.

A dialup supports up to 500 concurrent connections. In interface mode those will be enumerated.