KB62424 shows a method of getting this to work without changing one of the subnets.
Ideally you change the subnet to be unique, but an alternative is the method in KB62424
It is complex and confusing,ando future maintence is also a challenge if you go down this path.
Thank you for the link, Ross. What has changed since v3.x that this no longer works easily?
nothing has change if I understand your question correctly.
The document was written pre v4
OK, so after looking at the KB article, it deals with a similar problem, but not the same one, and I don't think that it ought to be necessary to jump through those particular hoops.
1.) Traffic on the 192.168.0.1 Subnet to the 10.3.0.0 subnet should be received on Ports a1,a3, or a4, and be routed via IPsec tunnel #1 to RemoteSite #1
2.) Traffic on the 172.30.130.0 subnet to the 10.3.0.0 subnet should be received on Port A2 and be routed via IPsec tunnel #2 to Remote site #2.
If need be, I can limit each subnet to one and only one port to avoid problems.The different subnets do not and should not have anything to do with each other, including physical ethernet infrastructure.
Since there are two local subnets, and each local subnet only needs to connect to one of the two conflicting sites, shouldn't this just work? In fact, I was doing exactly this on the 3.x firmware, not a week ago, so I know it's possible, I'm just missing something in the setup that has changed, ever so slightly. I think it might the the VLAN setup, but frankly, I am not certain.
1 of 1 people found this helpful
I understand what you are trying to achieve a bit more.
The problem is the internal routing table on the UTM device.
If there are two seperate IPSec tunnels both connecting to 10.3.0.0/24, then there are two routes to this remote network. You can't have 2 routes to the same network of the same weight...it is a 'limitation' of IP routing
Policy based routing won't work around it either.
As such the KB article is the only method I know to work around this.....
Another alternative would be to reduce the size of the subnet/s and as such make them unique. If they only accessing one server the remote subnet could be 10.3.0.x/32, and as long as you don't need to also access this IP over the other tunnel, it will work around the limitations of IP routing.
Thanks for the info. I have implemented a modified solution because my situation is one central unit with two conflicting remote subnets, not conflicting local subnets on two devices connected to each other, like the KB article envisioned. Anyhow, here are instructions for my situation:
Central Device LAN subnet: 192.168.0.0/24
Remote device #1 LAN subnet: 10.3.0.0/16
Remote device #2 LAN subnet: 10.3.0.0/16
- Create an IPSec tunnel between Central Device and Remote Device #1 as you would normally. Nothing special is needed for this tunnel.
- Create an IPSec tunnel between Central Device and Remote Device #2 as you normally would, except:
- On Central Device, specify the local subnet as 192.168.0.0/24 (actual) remote subnet as 10.33.0.0/16 (dummy).
- On Remote Device #2, specify the local subnet as 10.33.0.0/16 (dummy) and the remote subnet as 192.168.0.0/24 (actual).
- On Remote Device #2, create a new 'Source NAT' NAT rule under Firewall 'NAT' with the following properties:
Descriptive Name: Outgoing IPSec NETMAP Translation
Match packet fields
Outgoing Interface: Any VPN interface
Source Address: Select 'New' and enter '10.3.0.0/16' (the actual LAN subnet for "Remote Device #2").
Destination Address: Select 'New' and enter 192.168.0.0/24 (the actual LAN subnet for "Central Device").
Translate packet fields
To Source Address:Select 'New' and enter the 10.33.0.0/16 (the dummy network).
- On Remote Device #2, create a new 'Port Forwarding' NAT rule under Firewall 'Packet Filtering' -> 'Port Forwarding' with the following properties:
Select the 'Advanced' button down the bottom and complete as follows:
Descriptive Name: Incoming IPSec NETMAP Translation
Create Packet Filter Rule: checked
Match packet fields
Incoming Interface: Any VPN Interface
Source Address: Select 'New' and enter 192.168.0.0/24 (actual LAN subnet for "Central Device").
Destination Address: Select 'New' and enter 10.33.0.0/16 (the dummy network).
Protocol: Select 'Show Definitions' and select 'Any'
Translate packet fields
To Destination Address: 10.3.0.0/16 (actual LAN subnet for "Remote Device #2").
Users on both Remote devices' networks still use the actual subnet addresses to communicate with the devices connected to the Central Device. Nothing has changed from their point of view. Users on the Central Device's network use the actual subnet addresses (10.3.x.x) to communicate with hosts connected to Remote Device #1 and use the dummy addresses (10.33.x.x) to communicate with hosts connected to Remote Device #2.
I hope this proves helpful to someone.
thanks for documenting this for others.
the only downside to this type of setup is the dummy networks may require DNS changes if you use DNS internally.
Easy to stick to IP adddress's if possible