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

FortiGate as dialup VPN client - reverse path checking problem

Hello all,

I need configure FortiGate as VPN dialup client. I try to setup it in my lab - please see image "FGT_dial_client.jpg".

My goal is to connect firewall "FGT VPN REMOTE" to "FGT VPN SERVER" as dialup client, so PC 192.168.1.10 can reach to network 192.168.20.0/24. I made setting according to "FortiOS Handbook - IPSec VPN", chapter "FortiGate dialup-client configurations". I am able to bring up VPN tunnel, data from 192.168.1.1 reach FGT VPN SERVER, but on FGT VPN SERVER I get error message "reverse path failed".

I investigate route table on FGT VPN SERVER and find that there is no route back to 192.168.1.0. I tried to make static route through VPN tunnel interface, but I cannot - I cannot choose VPN tunnel interface as device when I create static route, VPN tunnel interface is not visible in drop down menu in GUI. I tried it via CLI, but no success.

Please can you help me with how I can set route back to 192.168.1.0 on FGT VPN SERVER? Or is something wrong in my config? Thank you in advance for any help.

Best regards

Lukas Mecir

P.S. - Site-to-site VPN is unfortunately not an option, because in real FGT VPN REMOTE device will be moved between many locations and will get WAN IP address dynamicly.

3 REPLIES 3
ede_pfau
SuperUser
SuperUser

A dial-in VPN has the speciality that the server-FGT creates a host route dynamically after a successful tunnel establishment. That's why you cannot create a static route on a dynamic client phase1 - it just works the other way around.

If you don't see any host route ("/32") in the routing table then your config is not 100% correct and the tunnel is not up fully.

Post what you can see in the rt. table, and the tunnel config from CLI.

Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
lukas_mecir

Hi Ede,

thank you for reply. You inspired me thinking about routing injection and I think i found the problem. It was VPN Phase 2 selectors config - I had this on both FGTs:

 

Local Network - 0.0.0.0/0

Remote Network - 0.0.0.0/0

 

I changed this config to:

 

On SERVER side:

Local Network - 192.168.20.0/24

Remote Network - 192.168.1.0/24

 

On REMOTE side:

Local Network - 192.168.1.0/24

Remote Network - 192.168.20.0/24

 

And now I see route to remote network in route table:

FGT-VPN-SERVER # get router info routing-table all Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP        O - OSPF, IA - OSPF inter area        N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2        E1 - OSPF external type 1, E2 - OSPF external type 2        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area        * - candidate default   S*      0.0.0.0/0 [10/0] via 10.8.15.1, port1 C       10.8.15.0/24 is directly connected, port1 S       192.168.1.0/24 [15/0] is directly connected, Remote-FGT_0 C       192.168.20.0/24 is directly connected, port2

 

I am able to ping from 192.168.1.0/24 to 192.168.20.0/24, everything is working as desired. Thank you very much again for inspiration.

Best regards

Lukas

ede_pfau

Thank you for reporting back - I didn't think of the QM selectors in this context. That FortiOS allows and even defines the wildcard QM '0.0.0.0/0' by default is harmful with Dial-In VPNs. I'd hope FTNT would remove the default altogether - the wildcards do work but not against other brands, it isn't universally applicable.

 

Anyway, I'm glad you solved your problem.

Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
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