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

Traffic from IPSec tunnel to a VLAN

I have a Fire Dept station 1 that is connected to our city hall (CH) office via Ubiquity wireless dishes on a VLAN setup in a 100E at CH.  The FD has a remote location, station 2, connected to CH via an IPSec persistent VPN tunnel. There are cameras at FD station 2 that I need to give them access to at station 1.  I have played with routing and policies but I cannot seem to make this work.  I am attaching a diagram of the layout with subnets and hardware models.  You will also notice PW on there but if I can get FD working I can use the same logic to get PW working.

 

Thanks in advance. 

11 REPLIES 11
sw2090
SuperUser
SuperUser

hm that's basically the same what we do bettween HQ and Shops.

At a Shop there is various vlans for different usages (including wifi) and we need to access all those from HQ.

Between HQ und Shop there is S2S IPsec like in your case between FD1 and FD2.

All that is needed to make this work is this (I apply this to your case for you here).

 

1.Routing:

FGT at FD1 needs to know a route to the Subnet(s) at FD2 via the IPSec Tunnel (static route with interface and no gateway needed)

FGT at FD2 needs to know a route to the Subnet(s) at FD1 (static with interface and no gw) to be able to send packets back to FD1

 

2. Policies

FGT at FD1 must have a policy that allows traffic from FD1 subnet(s) to FD2 subnet(s). Source interface is the interface(s) the subnet(s) on FD1 are connected to, destination interface is the ipsec tunnel interface to FD2.

 

FGT at FD2 must have a policy that allows traffic from FD1 subnet(s) to FD2 subnet(s). Source interface is the IPSec tunne interface to FD1. Destination interface is the interface(s) the subnet(s) on FD2 are connected to.

 

You do not need reverse Policies unless you want to actively establisch a connection from the opposite site too.

 

diag debug flow filter / trace  pn FGT cli can show you if packets reach the other side and what happens to them afterwards.

-- 

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

Thanks for the reply.  There is not a FGT at FD1 only a switch.  FD1 is connected to CH via point to point wireless Ubiquity dishes and the FGT at CH is FD1's router.  CH router has a VLAN set for FD1 and issues IP addresses to that location from CH.  I need FD1's VLAN to talk to FD2's VPN connection that are both in the CH router. I have put policies that allow FD1's VLAN to talk to FD2's VPN and have tried static routes in the CH router and the FD2 router, but a tracert from either location gets no further than their respective routers.

sw2090

hm. Don't see the problem.

 

A Client at FD1 is in 192.168.6.0/24 

as you say the FGT at CH is FD1's router so that to me means that a client at FD1 in 192.168.6.0/24 will have the FGT as default gw (respective its ip on the vlan interface that connects FD1). 

So all traffic that goes to a destination outside 192.168.6.0/24 will hit the FGT anyways (due to the client's default route). That's the rudimentary basic routing principle in ipv4.

So the FGT will have to know where to route traffic that should go to FD2 subnet and the FGT at FD2 must know how to route packets back to FD1 subnet. 

And both need policies to allow the traffic to flow.

 

I have this here too:

 

Wifi with Unify APs (each SSID has own vlan) => switches => FGT => IPSec => FGT at HQ.

Just has ipsec s2s tunnel, routes and policies.

-- 

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

Btw if possibe please change the subnet at PW since it is the same as FD1. If you want to connect from FD1 to PW or vice versa that would result in overlapping subnets. Overlapping subnets is a bad thing and I do not recommend that. There is some workaround for that available 'though but it is easier to change the subnets if possible.

 

-- 

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

I have a policy that says the following:

 

Incoming interface: FD1-VLAN

Outgoing Interface: FD2 to CH VPN Tunnel

Source: 192.168.6.0/24

Destination: 192.168.1.0/24

 

we have tried this with NAT on and off.

So far this does not work.

 

 

And PW's subnet is 192.168.7.0/24

sw2090

ok I read a 7  for a 1 in your drawing. Sorry for that then forget the overlapping subnets ;)

 

Where do you have this policy? It has to beo on FGT at CH.

FGT at FD2 hass to have that policy too. It also has to allow this traffic to flow.

 

Do you also have the static routes on both fgt?

-- 

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

Yes, that policy is in the CH router.  I added the following policy in FD2's router's policies.

 

Incoming Interface: LAN

Outgoing Interface: CH VPN Tunnel

Source Address: 192.168.1.0/24

Destination Address: 192.168.6.0/24

 

I also tried reversing the above incoming and outgoing and the addresses.

sw2090

CH Router (FGT100E) has to have:

 

Policy: source interface: where FD1 Subnet is connected

          destination interface: ipsec to FD2

          source address: FD1 subnet

          destination address: FD2 subnet

 

static route to FD2 Subnet via Ipsec to FD2

 

FD2 FGT has to have:

 

Policy: source interface: ipsec to FD1

           destination interface: where FD2 subnet is connected

           source address: FD1 subnet

           destination address: FD2 subnet

 

static route to FD1 subnet via Ipsec to FD1

 

the static routes do not have to have any gw set just the tunnel interface as interface.

 

you must also make sure that the policy on both FGT always sits in front of any other policy for internet traffic. That is because policies on a FGT are exempt top down and usually policies for internet traffic have destination address  "any". So that would catch the packets and the other policy won't be hit if it comes first because exempt stops once there is a match.

 

you could use policy lookup in gui to check this on a fgt. That will show you which policy is matched.

 

the only case in which this wouldn't work is if you do active vlan tagging on your clients whis is very seldom as it rather difficult to set up and in windows that also depends on if the drivers support it. So I suppose devices are connected to a switch that does the tagging from there or directly to the FGT so vlan tagged traffic is only between switch and FGTs. That's also what I do here.

-- 

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

Sorry it took so long to get back on this.

 

Everything in your last post make sense except the reference to the IPSec to FD1.  FD1 has no router, therefore there is no tunnel to FD1.  There is however at tunnel from FD2 to the CH router that router also has a VLAN to FD1.  

 

I tried the following but it did not work:

Policy: source interface: ipsec to CH            destination interface: VLAN to FD1            source address: FD1 subnet            destination address: FD2 subnet

 

I also tried to create another IPSec tunnel from FD2 to CH using the two FD's subnets, but I would not create because there already a tunnel from FD2 to CH.

If I do a tracert on either end the respective routers respond but it goes no further.  This is with everything you described in you last reply excpt with the IPSec to CH not FD1.

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