Access to VLANs via IPSEC VPN

[siayred]

Hi there,

I've been stuck on this for some weeks now, so hoping someone can help!

We have a third party vendor that needs access to our network and VLANs. The setup (which we inherited recently) has a Fortigate 80F in front of Alcatel switches. I have set up an IPSEC VPN on the Fortigate to the remote side, and this is up and passing traffic. The remote side is attempting to ping the gateway address of one of the VLANs and not getting a response (I've verified this with packet capture on the firewall).

I have tried adding the VLAN network into Phase 2 on the VPN on our side, and verified that this has also been done on the remote side, but the pings are still failing. One thing I think may be causing it is that none of the VLANs currently have an interface on the firewall; all the VLAN config is on the core switch and there are static routes for each VLAN on the firewall with the core switch as the gateway IP. Is there anything else I can try short of changing the setup to administer the VLANs from the Fortigate?

[Wuggles14]

Quite difficult to pick up anything obvious without looking at the config

But just to check that you have a route on the core switching for the subnets on the remote end of the VPN to go via the FGT

In the same vein, do you have NAT enabled on your firewall policies between the remote end and the VLANs on your local subnets?

[siayred]

Hi there,

Yes, routes are configured for the VLANs to go through the FGT, and NAT is enabled on the VPN.

[hbac]

Hi @siayred,

Please run the follow debug flow commands to see if the traffic is being dropped or not: 

di deb disable
di deb res
diagnose debug flow filter clear
di deb flow filter addr x.x.x.x
di deb flow filter proto 1
diagnose debug flow show function-name enable
di deb flow show iprope en
diagnose debug console timestamp enable
diagnose debug flow trace start 500
diagnose debug enable

Regards, 

[siayred]

Hi,

Thank you for this (fairly new to Fortigates!). I get the following response when running the debug:

2024-01-11 15:53:19 id=20085 trace_id=1 func=print_pkt_detail line=5822 msg="vd-root:0 received a packet(proto=1, x.x.x.x:13->x.x.x.x:2048) from vpn-0d04503165b. type=8, code=0, id=13, seq=22082."
2024-01-11 15:53:19 id=20085 trace_id=1 func=init_ip_session_common line=5993 msg="allocate a new session-036ee050"
2024-01-11 15:53:19 id=20085 trace_id=1 func=iprope_dnat_check line=5121 msg="in-[vpn-0d04503165b], out-[]"
2024-01-11 15:53:19 id=20085 trace_id=1 func=iprope_dnat_tree_check line=823 msg="len=0"
2024-01-11 15:53:19 id=20085 trace_id=1 func=iprope_dnat_check line=5134 msg="result: skb_flags-02000008, vid-0, ret-no-match, act-accept, flag-00000000"
2024-01-11 15:53:19 id=20085 trace_id=1 func=ip_route_input_slow line=2264 msg="reverse path check fail, drop"
2024-01-11 15:53:19 id=20085 trace_id=1 func=ip_session_handle_no_dst line=6077 msg="trace"

I'm going to guess that the bolded part is the problem, but I can't find a clear answer on how to fix it?

[hbac]

@siayred,

"reverse path check fail, drop" means there is no static route to the source IP via "vpn-0d04503165b". You can create a static route and test again.

Regards, 

[Wuggles14]

Agree with this post, you need the routes for the remote subnets on the FGT

Tech Tip for RFP (it's a bit old but explains it)

Technical Tip: Details about FortiOS RPF (Reverse ... - Fortinet Community

[mle2802]

Hi @siayred,

Can you please do the command 
get router info routing-table detail x.x.x.x (the source Ip where the ping from)

[siayred]

Hi @mle2802 ,

Output of that command is:

Routing table for VRF=0
Routing entry for 172.16.0.200/32
Known via "static", distance 10, metric 0, best
* 169.254.8.89, via vpn-0d04503165b distance 0

[mle2802]

Hi @siayred,

can you confirm if remote site route traffic to the tunnel rather than the default route?. Please also run the command to confirm if traffic is seen on FortiGate. 

diag sniffer packet any "host X.X.X.X and icmp" 4 0 l