New Member

Question

Loopback VIP issue on reverse path check fail, drop

Forum|Forum|1 year ago
December 9, 2024
4 replies
5297 views

I did follow the tech doc as below

https://community.fortinet.com/t5/FortiGate/Technical-Note-How-to-configure-a-VIP-using-a-loopback-interface/ta-p/194521

but when debug flow, i receive reverse path check fail, drop error when after the DNAT success

FortiGate
1. Loopback IP 192.168.1.254
2. Port 1 (WAN) - 192.168.1.1/28
3. Port 2 (LAN) - 192.168.1.128/28
4. Site to Site VPN (S2S-DC)
Route static
10.1.1.0/24 via port 2
172.16.30.0/24 via S2S-DC

my connection is come from site to site vpn DC 172.16.30.1 --> loopback 192.168.1.254 (DNAT - 10.1.1.1) --> Port 2 --> 10.1.1.1

routing shouldnt be problem but debug flow still receive error reverse path check fail, drop, looking for 192.168.1.254 although is connected.

I perform PCAP on S2S-DC , packet did reach to FW.
PCAP on port 2 no source ip 172.16.30.1 found. the packet been drop in fw and not related to return route

update : i restart router engine still having such issue

sjoshi

Staff

Hi,

Can you share:-

get router info routing-table details 172.16.30.1

If you have found a solution, please like and mark it as solved to make it easily accessible for everyone.

LVHanAuthor

New Member

Without static route
get router info routing-table details 172.16.30.1

Routing table for VRF=0
Routing entry for 0.0.0.0/0
Known via "static", distance 25, metric 0, best
* vrf 0 192.168.1.2, via port1

With static route configure

get router info routing-table details 172.16.30.1

Routing table for VRF=0
Routing entry for 172.16.30.0/24
Known via "static", distance 10, metric 0, best
via S2S-DC tunnel 58.26.10.2 vrf 0, tun_id

Tunnel is enable automatic route add, but it seem not working. Other tunnel automatic route add

match policy no issue, herewith the debug flow, it stopped looking for route
id=65308 trace_id=42 func=__ip_session_run_tuple line=3455 msg="DNAT 192.168.1.254:8->10.1.1.1:1"
id=65308 trace_id=42 func=ip_route_input_slow line=1695 msg="reverse path check fail, drop"

get router info routing-table details 192.168.1.254

Routing table for VRF=0
Routing entry for 192.168.1.254/32
Known via "connected", distance 0, metric 0, best
* is directly connected, 192.168.1.254

sjoshi

Staff

is it working when you add the static route:-

With static route configure

get router info routing-table details 172.16.30.1

Routing table for VRF=0
Routing entry for 172.16.30.0/24
Known via "static", distance 10, metric 0, best
via S2S-DC tunnel 58.26.10.2 vrf 0, tun_id

If you have found a solution, please like and mark it as solved to make it easily accessible for everyone.

dingjerry_FTNT

Staff

Hi @LVHan ,

For the traffic from S2S-DC to VIP, please enable NAT.

Please also share the outputs of debug flow commands.

LVHanAuthor

New Member

config firewall policy
edit 218
set name "Test-321"
set srcintf "loopback"
set dstintf "port2"
set action accept
set srcaddr "all"
set dstaddr "VIP-10.1.1.1"
set schedule "always"
set service "ALL"
set logtraffic all
set nat enable
next
end

still same debug error

DNAT 192.168.1.254:8->10.1.1.1:1
reverse path check fail, drop
trace

dingjerry_FTNT

Staff

Hi @LVHan ,

No, this policy is for traffic from VIP to LAN. I was talking about traffic from S2S-DC to "loopback." You must have a firewall policy to allow this traffic. You need to enable the NAT on that firewall policy.

Anyway, please share the debug flow outputs.

funkylicious

SuperUser

Hi,

Is there a reason why you dont just use the real destination IP and prefer to use DNAT using a Loopback?

Anyways, in your phase-2 selectors, you should have the Loopback in there and a firewall rule from the remote IPsec tunnel interface as the source, to port2 as destination and it should work.

Can you also display the output of the command, show firewall vip VIP-10.1.1.1 ?

"jack of all trades, master of none"

LVHanAuthor

New Member

Reason behind is that some server require to stay on premises and some migrated to AWS, both must remain same IP as some legacy application still hardcode with ip address.

herewith the flow
10.1.1.2 --> FW (policy route) SNAT(192.168.1.128/28) DNAT(192.168.240/28) --> S2S-DC --> AWS FW (DNAT 10.1.1.1) --> AWS Security Policy (Not my control) --> 10.1.1.1

because AWS security policy not within my control, and the default route is toward my AWS FW. to make it simple by perform DNAT at on premises fw. perhaps I should remove the DNAT at on-prem FW

edit "VIP-10.1.1.1"
set extip 192.168.1.254
set mappedip "10.1.1.1"
set extintf "any"
next

pminarik

Staff

Doing this with a loopback is rather pointless, I would say. The loopback interface never actually receives nor transmits any traffic. It's just abstraction. Why bother?

Why not simply do a VIP for the actual interfaces involved?

extintf = <incoming intf of packet sent from client> or ANY

extip = dstip used by client

mappedip = IP of the real destination server

+optional port mapping

firewall policy:

srcintf = real ingress interface

dstintf = real egress interface

srcaddr = <anything that matches the client's IP>

dstaddr = <VIP object>

service = <anything that matches post-DNAT port&protocol)

LVHanAuthor

New Member

Agree, the loopback int was tried to fix the routing issue but seem doesnt work.

DNAT 192.168.1.254:8->10.1.1.1:1
reverse path check fail, drop
trace

the route find not sure is related to 192.168.1.254 or 10.1.1.1

I don think is 10.1.1.1 as on cloud application is working , could be related to 192.168.1.254 which hit to default route.

dingjerry_FTNT

Staff

Hi @LVHan ,

Please provide the full outputs of the debug flow commands. You can mask sensitive info, but, please, provide the full outputs.

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded