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.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
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
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.
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
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
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
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
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.
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
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.
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1633 | |
1063 | |
751 | |
443 | |
210 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.