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

accessing site to site VPN network while connected with dialup-forticlient

Hello,

 

It's my first time using these forum and i hope i'll be as clear as possible.

 

I have two networks, A and B interconnected with two fortigate 30e with a site to site IPSEC VPN.

When connected directly to the lan of these networks i can access both networks.

 

Now, i have a second VPN on network A which is an IPSEC dialup-forticlient VPN. I need remote customers connecting on network A with their client VPN to access network B servers. The VPN is working fine for network A and they can access everything in there but i don't know how to allow theses interconnected users to be allow to go on network B.

 

Here's a diagram to help :

 

Drix32_0-1660739531666.png

i guess i'm missing a route or policies but i can't quite understand how to set them up.

 

Thank you for your help and time

2 Solutions
sagha
Staff
Staff

Hi Drix32, 

 

I would suggest two basic things: 

 

1. On both FGTs make sure that phase2 selectors are correctly configured. 

2. You will need a policy to allow traffic between dialup vpn and site to site vpn. 

 

This article would help: https://community.fortinet.com/t5/FortiGate/Technical-Tip-Dialup-IPsec-traffic-forwarding-to-site-to...

 

You can also capture traffic on FGT:

 

diag de rest

diag de flow filter addr x.x.x.x

diag de flow filter proto 1

diag de flow trace start 1000

diag de en

 

Replace x.x.x.x with destination server address and start a ping. This would highlight why traffic is not forwarded from remote users

 

Thanks, 

Shahan

View solution in original post

sw2090
Honored Contributor

this is i case I have here at all shop sites.

You will need to use split tunneling on the dial up ipsec because you need to push routes to the remote subnets on FGT on other end of the S2S to your client.

Then FGT on remote end of the dialup needs to know routes to those subnets too plus it has to have policies to allow traffic to flow from dial up over the s2s to the other subnet (and vice versa if needed).

FGT on remote end of the S2S has to know a route back to the dial up vpn and also has to have the accoarding policies from dialup vpn over s2s to remote subnet.

Reverse policies are only needed if you actively want to connect to dial up client(s) from out of the remote subnets.

 

Oh and on your drawing I see that both FGT have the same subnet (i.e. overlapping subnets). if that is not a mistype there that would require additional workarounding. There is some document on that on the knowledge base. I used that once when this hit me at work....

-- 

"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams

View solution in original post

-- "It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
5 REPLIES 5
sagha
Staff
Staff

Hi Drix32, 

 

I would suggest two basic things: 

 

1. On both FGTs make sure that phase2 selectors are correctly configured. 

2. You will need a policy to allow traffic between dialup vpn and site to site vpn. 

 

This article would help: https://community.fortinet.com/t5/FortiGate/Technical-Tip-Dialup-IPsec-traffic-forwarding-to-site-to...

 

You can also capture traffic on FGT:

 

diag de rest

diag de flow filter addr x.x.x.x

diag de flow filter proto 1

diag de flow trace start 1000

diag de en

 

Replace x.x.x.x with destination server address and start a ping. This would highlight why traffic is not forwarded from remote users

 

Thanks, 

Shahan

Drix32
New Contributor II

Hello Sagha,

 

Thank you very much, i'll see what i can do with your tips and your very usefull link link !

 

i'll keep you updated :)

sw2090
Honored Contributor

this is i case I have here at all shop sites.

You will need to use split tunneling on the dial up ipsec because you need to push routes to the remote subnets on FGT on other end of the S2S to your client.

Then FGT on remote end of the dialup needs to know routes to those subnets too plus it has to have policies to allow traffic to flow from dial up over the s2s to the other subnet (and vice versa if needed).

FGT on remote end of the S2S has to know a route back to the dial up vpn and also has to have the accoarding policies from dialup vpn over s2s to remote subnet.

Reverse policies are only needed if you actively want to connect to dial up client(s) from out of the remote subnets.

 

Oh and on your drawing I see that both FGT have the same subnet (i.e. overlapping subnets). if that is not a mistype there that would require additional workarounding. There is some document on that on the knowledge base. I used that once when this hit me at work....

-- 

"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams

-- "It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
Drix32
New Contributor II

Hello,

 

Indeed networks A & B have differents IP pool. That's my mistake. both VPN i set up work (dial-up and S2S). I only need to allow remote users connected to network A to go on network B. 

 

I tried following the documentation but unfortunately i can only access the FGT on their GUI (no command lines) ; So i'm looking in the GUI how to match the command lines with the interface.

 

I did the policies to allow the traffic and i also added the static routes on the remote FGT. I think what i might be missing is the split tunneling part. In the document kindly shared by Sagha i see this part :

 

– When the dialup tunnel split tunnel enable needs to have the routing address in our case it needs to have 10.158.0.0/20 and 10.157.0.0/20

 

I think it's the part i'm missing to make things work. I'm currently trying to find how to set this up on the GUI.

 

Drix32
New Contributor II

Hello,

It's working ! 

dumb dumb me forgot to remove the nat option on the firewall rules between my VPN. I removed them and now i can access both network in remote. A big thank you to you two !

Labels
Top Kudoed Authors