Access remote site on IPSec Site-To-Site Dial-Up VPN

[IT_SAG]

Hello

I've a Problem and hope someone can help me.

I created a route-based IPSec Site-to-Site VPN tunnel between our headoffice and one branch office.

The branch office is using a dynamic IP, so I had to create a dial-up VPN.

The Computers on the dial-up site (branch Office) can Access the Systems on the headoffice but the headoffice can't connect to the Systems on the branch office.

In the FortiOS Handbook under "FortiGate dialup-client configurations > Route-based VPN" is written "Because communication cannot be initiated in the opposite direction, there is only one policy."

This works in both directions with policy-based VPN Connections.

Is there really no way that the headoffice can connect to systems at the branch office by using route-based dial-up VPNs?

We're using route-based VPNs because we had some issues with policy-based VPNs using a Hub-and-Spoke configuration.

The Fortinet Support told us to use route-based VPNs instead but now we have this issue...

Any idea how to solve this?

Thank you very much.

Ramon

[IT_SAG]

OK, I guess nobody knows a soloution because there is none.

I try to open a Feature Request. We'll see if this will be possible in the future...

[ede_pfau]

Sorry, your post slipped by...

Why dial-up? Just let the branch office FGT initiate the tunnel. One side is static IP, one side is dynamic IP/DDNS. These days (i.e. in FOS 5.2+) Fortinet offers a free DDNS account for FGT owners.

Using a static IP and a dynamic name, you can even use Main mode.

BTW, even with your setup you should be able to send traffic in both directions. Probably one of the 2 routes necessary is missing, or one of the policies. Check the routing table on both FGTs (Routing > Monitor) if there's a proper route for each private network.

IIRC, the FGT will create a host route for each dial-up client (a /32) dynamically on connect. This would then not work for 2 subnets. You'll see that in the Routing Monitor.

Again, drop the dial-up idea altogether.

[IT_SAG]

Hello ede_pfau

Thank you very much for your Response.

Why dial-up? Because our branch office Firewall is connected through LTE. This means we have a dynamic IP address and our LTE Provider has a NAT router in his infrastructure which prevents our headoffice Firewall from connecting to the branch office IP address.

I'll give the DynDNS Solution a Chance but it doesn't make that much sense. Our branch office Firewall might send the correct IP to the DynDNS Service but our headoffice Firewall will still not be able to connect to the branch office due to the NAT of the LTE Provider. Even if it's not a dial-up our branch office needs to initiate the connection. But if it's such a big deal for the FortiGate wether the remote IP is a DNS Name or a dial-up Connection to work correctly, I'll give it a try.

BTW our branch office Firewall isn't a FortiGate.

I'll Keep you updated.

Once again, thank you very much.

Best Regards

Ramon

[ede_pfau]

This might be interesting for you: https://forum.fortinet.com/tm.aspx?m=140931

As you can see, the injected route is a "/24" so the remote side hosts should be available from the central site.

What does the routing table (Router > Monitor) look like on the central FGT after establishment of a dial-up VPN connection? CLI output preferred (get router info rout all)