Description
This article describes how to reverse route missing when user is trying to access the destination behind IPSEC VPN from SSL VPN.
Solution
In this scenario, source/user is behind the SSL VPN connected to Fortigate A and destination is behind ISPEC VPN terminated on Fortigate B.
SSL VPN User 10.1.1.1 >>> Fortigate A ---------- Ipsec ------ Fortigate B ---- Destination subnet (192.168.1.0/24)
Related document.
https://docs.fortinet.com/document/fortigate/6.2.0/cookbook/45836/ssl-vpn-to-ipsec-vpn
Once configured if it is not working, verify the below
In FortiGate A.
- Route for destination should be towards IPSEC tunnel.
- Policy between SSL VPN and IPSEC VPN.
- Phase 2 subnets allowing both the src and destination subnet accordingly.
Further you can verify it with sniffer output if the traffic is going out with correct output
Diag sniffer packet any 'host 192.168.1.1 and icmp' 4 0 l
An output smiliar to will appear.
2020-10-30 07:09:34.359439 ssl.root in 10.1.1.1 -> 192.168.1.1: icmp: echo request
2020-10-30 07:09:34.359458 ipsec.A out 10.1.1.1 -> 192.168.1.1: icmp: echo request
On FortiGate B.
Verify the same in IPSEC VPN FortiGate.
Where the packet is received but not sent out like below.
2020-10-30 07:09:34.359439 IPSEC.B in 10.1.1.1 -> 192.168.1.1: icmp: echo request
Verify this behavior with below debug
Debug commands.
- Policy from IPSEC interface to destination interface.
- Destination route towards the LAN interface.
- IPSEC Phase 2 parameters.
If the issue persists even after that, open a TAC ticket along with debug logs and config file.
This article describes how to reverse route missing when user is trying to access the destination behind IPSEC VPN from SSL VPN.
Solution
In this scenario, source/user is behind the SSL VPN connected to Fortigate A and destination is behind ISPEC VPN terminated on Fortigate B.
SSL VPN User 10.1.1.1 >>> Fortigate A ---------- Ipsec ------ Fortigate B ---- Destination subnet (192.168.1.0/24)
Related document.
https://docs.fortinet.com/document/fortigate/6.2.0/cookbook/45836/ssl-vpn-to-ipsec-vpn
Once configured if it is not working, verify the below
In FortiGate A.
- Route for destination should be towards IPSEC tunnel.
- Policy between SSL VPN and IPSEC VPN.
- Phase 2 subnets allowing both the src and destination subnet accordingly.
Further you can verify it with sniffer output if the traffic is going out with correct output
Diag sniffer packet any 'host 192.168.1.1 and icmp' 4 0 l
An output smiliar to will appear.
2020-10-30 07:09:34.359439 ssl.root in 10.1.1.1 -> 192.168.1.1: icmp: echo request
2020-10-30 07:09:34.359458 ipsec.A out 10.1.1.1 -> 192.168.1.1: icmp: echo request
On FortiGate B.
Verify the same in IPSEC VPN FortiGate.
Where the packet is received but not sent out like below.
2020-10-30 07:09:34.359439 IPSEC.B in 10.1.1.1 -> 192.168.1.1: icmp: echo request
Verify this behavior with below debug
Debug commands.
# Diag debug resetSimilar output as below will appear.
# Diag debug flow filter saddr 10.1.1.1
# Diag debug flow filter daddr 192.168.1.1
# Diag debug flow filter proto 1
# Diag debug flow trace start 1000
# Diag debug enable
id=20085 trace_id=66 func=print_pkt_detail line=4489 msg="vd-root received a packet(proto=1, 10.1.1.1:1->192.168.1.1:8) from IPSEC.b. code=8, type=0, id=1, seq=1154."Add the route by below commands.
id=20085 trace_id=66 func=init_ip_session_common line=4645 msg="allocate a new session-00007dbc"
id=20085 trace_id=66 func=ip_route_input_slow line=1274 msg="reverse path check fail, drop"
id=20085 trace_id=66 func=ip_session_handle_no_dst line=4712 msg="trace"
id=20085 trace_id=67 func=print_pkt_detail line=4489 msg="vd-root received a packet(proto=1, 10.139.64.100:1->192.168.1.1:8) from IPSEC.b. code=8, type=0, id=1, seq=1155."
# config router staticCommand to verify the routes.
edit 0
set dst 10.1.1.0 255.255.255.0
set device "IPSEC.b"
next
End
# Get router info routing-table details 10.1.1.1Once the route is added, also verify the below:
Routing table for VRF=0
Routing entry for 10.1.1.0/24
Known via "static", distance 10, metric 0, best
* 10.1.1.4, via IPSEC.B
- Policy from IPSEC interface to destination interface.
- Destination route towards the LAN interface.
- IPSEC Phase 2 parameters.
If the issue persists even after that, open a TAC ticket along with debug logs and config file.
Related Articles
Technical Note: How to access remote resource via IPsec for SSL VPN user