Loopback VIP issue on reverse path check fail, drop

[LVHan]

I did follow the tech doc as below

https://community.fortinet.com/t5/FortiGate/Technical-Note-How-to-configure-a-VIP-using-a-loopback-i...

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

[dingjerry_FTNT]

Hi @LVHan ,

Why is it as follows?

id=65308 trace_id=283 func=print_pkt_detail line=5862 msg="vd-root:0 received a packet(proto=1, 192.168.1.128:1->192.168.1.254:2048) tun_id=103.12.67.82 from S2S-DC. type=8, code=0, id=1, seq=5978."

The 192.168.1.128 is with port2, it was from S2S-DC. of course it is "reverse path check fail, drop", because 192.168.1.128 is supposed to be from port2.

[LVHan]

config firewall policy
edit 202
set name "Test-123"
set srcintf "S2S-DC"
set dstintf "192.168.1.254"
set action accept
set srcaddr "all"
set dstaddr "all"
set schedule "always"
set service "ALL"
set logtraffic all
set nat enable
next
end

Debug flow
id=65308 trace_id=283 func=print_pkt_detail line=5862 msg="vd-root:0 received a packet(proto=1, 192.168.1.128:1->192.168.1.254:2048) tun_id=103.12.67.82 from S2S-DC. type=8, code=0, id=1, seq=5978."
id=65308 trace_id=283 func=init_ip_session_common line=6047 msg="allocate a new session-003a75ef"
id=65308 trace_id=283 func=iprope_dnat_check line=5281 msg="in-[S2S-DC], out-[]"
id=65308 trace_id=283 func=iprope_dnat_tree_check line=824 msg="len=1"
id=65308 trace_id=283 func=__iprope_check_one_dnat_policy line=5146 msg="checking gnum-100000 policy-18"
id=65308 trace_id=283 func=get_new_addr line=1213 msg="find DNAT: IP-10.1.1.1, port-0(fixed port)"
id=65308 trace_id=283 func=__iprope_check_one_dnat_policy line=5236 msg="matched policy-18, act=accept, vip=18, flag=104, sflag=2000008"
id=65308 trace_id=283 func=iprope_dnat_check line=5293 msg="result: skb_flags-02000008, vid-18, ret-matched, act-accept, flag-00000104"
id=65308 trace_id=283 func=iprope_fwd_check line=768 msg="in-[S2S-DC], out-[192.168.1.254], skb_flags-02000008, vid-18, app_id: 0, url_cat_id: 0"
id=65308 trace_id=283 func=__iprope_tree_check line=524 msg="gnum-100004, use int hash, slot=71, len=12"
id=65308 trace_id=283 func=__iprope_check_one_policy line=2033 msg="checked gnum-100004 policy-4294967295, ret-no-match, act-accept"
id=65308 trace_id=283 func=__iprope_check_one_policy line=2033 msg="checked gnum-100004 policy-202, ret-matched, act-accept"
id=65308 trace_id=283 func=__iprope_user_identity_check line=1807 msg="ret-matched"
id=65308 trace_id=283 func=__iprope_check line=2281 msg="gnum-4e20, check-0000000070604c6e"
id=65308 trace_id=283 func=__iprope_check_one_policy line=2033 msg="checked gnum-4e20 policy-6, ret-no-match, act-accept"
id=65308 trace_id=283 func=__iprope_check_one_policy line=2033 msg="checked gnum-4e20 policy-6, ret-no-match, act-accept"
id=65308 trace_id=283 func=__iprope_check_one_policy line=2033 msg="checked gnum-4e20 policy-6, ret-no-match, act-accept"
id=65308 trace_id=283 func=__iprope_check line=2298 msg="gnum-4e20 check result: ret-no-match, act-accept, flag-00000000, flag2-00000000"
id=65308 trace_id=283 func=get_new_addr line=1213 msg="find SNAT: IP-192.168.1.254(from IPPOOL), port-60418"
id=65308 trace_id=283 func=__iprope_check_one_policy line=2251 msg="policy-202 is matched, act-accept"
id=65308 trace_id=283 func=iprope_fwd_check line=805 msg="after iprope_captive_check(): is_captive-0, ret-matched, act-accept, idx-202"
id=65308 trace_id=283 func=iprope_fwd_auth_check line=824 msg="after iprope_captive_check(): is_captive-0, ret-matched, act-accept, idx-202"
id=65308 trace_id=283 func=fw_pre_route_handler line=184 msg="VIP-10.1.1.1:1, outdev-unknown"
id=65308 trace_id=283 func=__ip_session_run_tuple line=3455 msg="DNAT 192.168.1.254:8->10.1.1.1:1"
id=65308 trace_id=283 func=ip_route_input_slow line=1695 msg="reverse path check fail, drop"
id=65308 trace_id=283 func=ip_session_handle_no_dst line=6133 msg="trace"

[funkylicious]

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 ?

[LVHan]

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]

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)

[LVHan]

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]

Hi @LVHan ,

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

[dingjerry_FTNT]

Hi @LVHan ,

Sorry, it seems that you provided the full outputs.  I missed it.

Could you please provide the outputs of the following?

get router info routing-table all

You may just show entries with 192.168.1.128 and 192.168.1.254.

[LVHan]

myself declare bug AWS FG, i retain the bug ipsec profile and create a new one.
the route appear in kernel

https://docs.fortinet.com/document/fortigate/7.6.1/administration-guide/426761/site-to-site-vpn-with...

I tried this approach the return traffic reach to AWS FW and route to correct tunnel interface but AWS FW doesnt perform encap or any action, the tunnel transmit statistic remain unchange.

So buggy for AWS FG 7.2.10