Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
AG_
New Contributor

FortiGate route lookup for local out traffic

Hi,

 

I've found the following technical tips on how route lookup is handled in FortiGate

AG__0-1721769714946.png

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Routing-in-FortiGate-route-lookup-process/...

 

 

But I don't think this logic applies in my case.

I've an ipsec remote access VPN, the forticlient initiates the communication with the FGT (my VPN gateway), the FGT receives requests from forticlient on port1, but it sends the responses on port2 (because of an SDWAN rule I have), And I never get the response on my forticlient (I get a connection timeout on the FGT). I can't modify my SDWAN rule, so I've tried to twist this behavior by adding a PBR so that packets coming on port1 are always returned from that same port. The PBR I added never matched, that's why i want to know if Fortigate takes into consideration PBR entries when doing a route lookup for local out traffic

 

4 REPLIES 4
amrit
Staff
Staff

 I would recommend using preserve session route on sslvpn interfaces, Please check this article

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Enabling-the-preserve-session-route/ta-p/1...

 

Additionally you can check this forum 

https://community.fortinet.com/t5/Support-Forum/SSL-VPN-dual-interface/td-p/212882

 

Amritpal Singh
orpgile38
New Contributor

when it comes to routing it's already like this. on WAN1 I have iBGP with that learnes default route with admin distance 200. and static default route that points to wan2 has admin distance 210. but pings received on wan2 are not answered by fortigate. I guess (not sure) they are dropped since outgoing interface according to routing table (wan1) does not match interface from which fg is supposed to send icmp reply. so I guess some RPF rule fails. I'm just speculating https://speedtest.vet/ .

ggarg
Staff
Staff

What firmware you are using?

Are you using SAML authentication, as there are known issues where traffic is egressing via wrong interface.

Can you post your routing table and debugs on the thread showing RPF fail?

Also capture a session

di sys session filter dport <port number>

di sys session filter src <Client's public IP>

di sys session list

 

Gautam Garg | TAC Engineer
Fortinet TAC - America East
NSE Certified: 1-4, 7 | CCNP
Office Hours: 8:45-5:45 EST (Mon-Fri)
maulishshah
Staff
Staff

Please run the following debugs to collect the RPF logs. 

 

di de reset

di de flow filter clear

di de flow filter addr x.x.x.x y.y.y.y and                 (x is the source and y is the destination)

di de flow trace start 99999

di de en

 

Also, provide the interface stat

 

fnsysctl ifconfig "interface name"

 

 

Maulish Shah
Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors