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

VPN to remote site with dedicated local interface port - FortiGate 40F to FortiGate 40F

I am a newbie and please forgive what is likely a silly question.

My office has an Fortigate F40 as our router and DHCP server.

I have a customer site where we have installed an F40 and use FortiClient to access their network. This all works great.

 

All I want to do is assign our local port 3 as a connection to our client's network on a full-time basis. I will be connecting equipment for testing purposes and have no need nor desire to access this equipment locally through the network. I ran through the steps from the cookbook, but somehow, I ended up exposing IP addresses at both sites to each other and caused some real mayhem. (Somehow added a 1-to-1 NAT within our local DHCP range, that was fun!)

 

Could I get some advice?

rvirgin_0-1672762716605.png

 

Footnote; I will be exploring options for additional education on this product to avoid dumb questions in the future.

 

Any help will truly be appreciated.

 

7 REPLIES 7
gfleming
Staff
Staff

Sounds like you want to use a site-to-site IPSec VPN between the Office and Customer site? This would provide an always-on tunnel without requiring FortiClient VPN to connect. Is that right?

 

I'm unsure what your plans are with port3? You want any devices connected to port3 to have access to customer site over the site-to-site VPN?

 

The simplest thing to do would be to create the tunnel and use Firewall Polices to restrict/allow who gets access to what from the Office to the Customer site.

 

Only issue right now I see is you have some overlapping IP address space. The Customer site 192.168.0.0/20 subnet overlaps with the office 192.168.1.0/24 subnet.

 

You will need to use NAT configuration to overcome this or, ideally use a new IP subnet at the Office site that does not overlap.

Cheers,
Graham
rvirgin
New Contributor

Graham,

Port 3 plan is as you say, any hardware connected to it would be as if it was on site at the customer end.  I was hoping I could isolate port 3 from my local LAN completely and avoid the subnet overlap outright.  Maybe I could add a VLAN?

gfleming

OK that is good news. So just assign a non-overlapping subnet to port3. You can use FW policies to restrict access to/from this interface and the VPN tunnel.

 

Then create an IPsec tunnel between the two FortiGate units over the WAN interfaces. Use the subnet of port3 and the remote 192.168.0.0/20 subnet as your phase2  selectors ((local/remote subnets)) and you should be good to go.

 

https://docs.fortinet.com/document/fortigate/7.0.9/administration-guide/913287/basic-site-to-site-vp...

Cheers,
Graham
rvirgin

Graham,

I set up the tunnel and it comes up, but I cannot ping from my local "port 3" to the client site.  Wonder though if I have my interface setup correctly;

rvirgin_0-1672839548022.pngrvirgin_1-1672839569961.png

This may be beyond simple advice and fall into paid support, which I can entertain.

gfleming

Yes your port3 is still overlapping with the remote end. 192.168.0.0/20 goes all the way to 192.168.15.255.

Cheers,
Graham
gfleming

You also want to ensure that devices connected to port3 can ping port3 interface IP (they have IP connectivity)

 

Then you want to make sure you have a policy allowing the traffic flow (source int port 3 / dest int IPSec Tunnel Int). 

 

You also want to make sure traffic is routed appropriately (should be automatically if you are using the IPSec tunnel wizard). 

 

On the remote end you just need to ensure routing is good and that their is a policy allowing from IPSEc to the internal interface.

Cheers,
Graham
sw2090
Honored Contributor

yes do not use overlapping subnets. That causes too much trouble and obfuscating. 

Build the Site2Site as said. Create the policies on both sides to allow traffic to flow (ipsec will not come up without policy anyhow) and also make sure that both side have route to the opposite subnet that should be reachable.

 

you could always run a flow trace on cli on either FGT to see what happens to your traffic:

 

diag debug enable

diag debug flow filter clear

diag debug flow filter <filter> (without paramters it will show all current filters or "?" to show parameters) 

probably set a source and/or destination address to filter (because without you will get tons of traced traffic)

diag debug flow trace start <numberofpacketstotrace>

 

then to some ping from some client to some device that uses the vpn and see what the trace says

-- 

"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
Top Kudoed Authors