FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
ereddy
Staff
Staff
Article Id 195442
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.
# Diag debug reset
# 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
Similar output as below will appear.
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."
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."
Add the route by below commands.
# config router static
    edit 0
        set dst 10.1.1.0 255.255.255.0
        set device "IPSEC.b"
    next
End
Command to verify the routes.
# Get router info routing-table details 10.1.1.1
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
Once the route is added, also verify the below:

- 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

Contributors