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

Site to Site IPSEc without direct connected private IP

Dear all

 

this will be my very first post and please go easy on me :) and I hope I get good respond and thanks before!

 

So far, any fortinet literature or cookbook or video only show that site-to-site IPSEc is created between two fortigate (site to site ipsec illustration.png), and the policy and static routing is created based on the two directly connected subnet (to fortigate).  For example, between HQ internal network (assuming 10.10.10.0/24) to Branch internal network (assuming 192.168.10.0/24), the private network is part of directly connected subnet to the fortigate physical interface.

 

 

What happen if private network  is behind another layer 3 device? for example, I want to create a VPN between 10.10."20".0/24 to 192.168."20".0/24. it means, both those .20 network are not directly connected to fortigate broadcast domain / physical interface.

 

If I am configuring HQ FGT, Should I simply state local address as 10.10.20.0/24 and remote address as 192.168.20.0/24 in Phase 2 IPSec custom configuration? After that, the virtual tunnel interface will be created. 

 

I will follow up with adding "static route" to dest 192.168.20.0/24 with gateway 0.0.0.0 with WAN 1 as interface.

after that, create

IPv4 policy: to remote.

incoming interface: virtual tunnel interface created above.

outgoing interface: WAN

 

IPv4 policy: from remote

incoming interface: WAN

outgoing interface: virtual tunnel interface created above

  

 

 

1 Solution
ede_pfau
SuperUser
SuperUser

You are partially right with your assumptions:

- put those 2 networks into the phase2 selectors which will communicate with each other

that is, 10.10.20.0/24 and 192.168.20.0/24

- policies are a bit off: the VPN creates a virtual interface for the traffic coming from or going into the VPN tunnel. You need to allow traffic from this interface to the LAN interface which connects to the local, second router. The WAN interface is never directly used in this scenario, only the tunnel interface and the LAN interface.

- last requirement: routing

In the branch, create a static route to the HQ network (10.10.20.0/24), pointing to the tunnel interface, no gateway needed (this is a FortiOS speciality for VPNs only).

In HQ, create a route to the branch network (192.168.20.0/24), pointing to the tunnel interface. This directs outbound traffic to the branch.

 

Now this would be enough if the two networks in question would be 'directly connected' to each Fortigate respectively. But in your case they are not. So, each FGT needs to know how to reach these subnets.

 

In branch, add another static route to the network behind the 2nd router (say, 192.168.20.0/24), specifying the 2nd router's IP address as gateway (e.g. 192.168.10.y) while the FGT is at 192.168.10.x. The routers' addresses need to be on the same LAN.

Now the FGT knows where to send the traffic. And it will do that not only when you ping there from the FGT's CLI but for traffic coming from the VPN tunnel as well. Plain routing.

 

Similary, in HQ, add a second route to 10.10.20.0/24 with gateway 10.10.10.y when the HQ FGT is at 10.10.10.x.

 

The reason why you have to do some extra work in this situation is that FortiOS automatically adds a route for you if the subnet is directly connected. Other routers don't and require manual routes in all circumstances. But FortiOS can't guess about some remote network, and how to reach it, so you have to add a route to it yourself. Both 'remote' subnets, the one behind the 2nd router on the LAN and the one behind the tunnel, are treated equally.

Ede Kernel panic: Aiee, killing interrupt handler!

View solution in original post

Ede Kernel panic: Aiee, killing interrupt handler!
5 REPLIES 5
ede_pfau
SuperUser
SuperUser

You are partially right with your assumptions:

- put those 2 networks into the phase2 selectors which will communicate with each other

that is, 10.10.20.0/24 and 192.168.20.0/24

- policies are a bit off: the VPN creates a virtual interface for the traffic coming from or going into the VPN tunnel. You need to allow traffic from this interface to the LAN interface which connects to the local, second router. The WAN interface is never directly used in this scenario, only the tunnel interface and the LAN interface.

- last requirement: routing

In the branch, create a static route to the HQ network (10.10.20.0/24), pointing to the tunnel interface, no gateway needed (this is a FortiOS speciality for VPNs only).

In HQ, create a route to the branch network (192.168.20.0/24), pointing to the tunnel interface. This directs outbound traffic to the branch.

 

Now this would be enough if the two networks in question would be 'directly connected' to each Fortigate respectively. But in your case they are not. So, each FGT needs to know how to reach these subnets.

 

In branch, add another static route to the network behind the 2nd router (say, 192.168.20.0/24), specifying the 2nd router's IP address as gateway (e.g. 192.168.10.y) while the FGT is at 192.168.10.x. The routers' addresses need to be on the same LAN.

Now the FGT knows where to send the traffic. And it will do that not only when you ping there from the FGT's CLI but for traffic coming from the VPN tunnel as well. Plain routing.

 

Similary, in HQ, add a second route to 10.10.20.0/24 with gateway 10.10.10.y when the HQ FGT is at 10.10.10.x.

 

The reason why you have to do some extra work in this situation is that FortiOS automatically adds a route for you if the subnet is directly connected. Other routers don't and require manual routes in all circumstances. But FortiOS can't guess about some remote network, and how to reach it, so you have to add a route to it yourself. Both 'remote' subnets, the one behind the 2nd router on the LAN and the one behind the tunnel, are treated equally.

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

Hi Ede

 

Thanks a lot for your detailed explanation. I have several clarification below in italics

 

- policies are a bit off: the VPN creates a virtual interface for the traffic coming from or going into the VPN tunnel. You need to allow traffic from this interface to the LAN interface which connects to the local, second router. The WAN interface is never directly used in this scenario, only the tunnel interface and the LAN interface.

I assume we need to allow policy for both direction: LAN interface --> tunnel interface and Tunnel Interface --> LAN interface, correct?

- last requirement: routing In the branch, create a static route to the HQ network (10.10.20.0/24), pointing to the tunnel interface, no gateway needed (this is a FortiOS speciality for VPNs only).

In HQ, create a route to the branch network (192.168.20.0/24), pointing to the tunnel interface. This directs outbound traffic to the branch.

Understand.

ede_pfau

Yes, correct, if you need to enable that sessions be opened from both sides, you would need policies to/from and from/to remote. Create one and right-click, "clone reverse".

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

Thanks a lot for your help! very appreciate it.

sw2090
SuperUser
SuperUser

Now that is a perect case for tu use FortiManagers VPN Manager. That makes it easier if you want to add more branches later.

 

Create a star topology in VPN manager and add HQ as Hub. Set up psk and proposals etc.

then add branch as spoke. Set protected net to the lan subnet of branch.

Then you just need to add a route to branch subnet at HQ and one to HQ at branch.

Then FMG needs policies to allow the traffic you want. The Interfaces needed for this are then already created by VPN Manager.

 

That to me is the most easy way to set this up.

-- 

"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
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