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

Problems with VPN - Routing issue?



we have 2 FG81 in HA (6.4.13) and a VPN to a SonicWall firewall with another company in main mode. So we cant see the config on the SonicWall side, but exchanging the parameters we got the VPN UP quite fast.


Now from our side we cant PING the other network and we need RDP to a server. We checked ping against another router and printer just to be sure that it is not a host problem.


BUT the other side CAN ping us from there and we also see traffic in our incomming policy. In our outgoing policy I dont see traffic from our pings, so we thought it could be a routing issue.


We just have 1 WAN and 1 default route. Trying in Network > Routing Monitor and checking Route Lookup we get this: to our default route (metric 10) and below

192.168.X.0/24 Gateway VPN XX (metric 5)


In all other firewalls checking the route I only get the route with the VPN Gateway. So we tried with a lower metric and also on top a policy route but we still cant ping or get traffic on this VPN policy.


We rebooted the FW to be sure of the right routing table but nothing.


Is this a problem from our side or can it also be another issue on teh SonicWall side, I dont even know if it is polcy based or routing based on the SW side.....but of the VPN goes UP and the other side has access?





Sounds like the opposite side doesn't have a return route


Hi @RolandBaumgaertner72,


Please run the following debug flow commands to find out:

di deb disable
di deb res
diagnose debug flow filter clear
di deb flow filter addr x.x.x.x                      <<<   Replace x.x.x.x with destination IP address. 
diagnose debug flow show function-name enable
di deb flow show iprope en
diagnose debug console timestamp enable
diagnose debug flow trace start 500
diagnose debug enable



New Contributor III



I could solve the problem. Debugging we found Denied by forward policy check.


Than we checked the policy and there was the problem. For testing we had all the LAN but also users and I thought these useres are from the LDAP but they were not. Deleting the users and allowing LAN solved the problem.



Top Kudoed Authors