7 Replies Latest reply on May 20, 2010 5:25 PM by rcamm

    IPSec: Dealing with conflicting local Subnets

      I did this on our firewall before we upgraded to v4 firmware, but I lost the config during the upgrade, and cannot figure out how to make it work again. Here are the details:

       

      Switch A LAN = 192.168.0.0/24

      Port A2 VLAN = 172.30.139.0/24

      Port B = Internet

       

      IPSec Tunnel #1 connects 192.168.0.0/24 to a site with remote subnet 10.3.0.0/16

      IPSec Tunnel #2 connects 172.30.139.0/24 to a DIFFERENT site with remote subnet 10.3.0.0/16

      There are 6-7 other IPSec tunnels, but they all connect to non-conflicting subnets.

       

      I tried just setting up the two IPSec tunnels with the local and remote subnets properly configured, which is what I did under firmware v3.x, but that doesn't seem to work. The second tunnel brought up does not get past negotiating Phase 2. If I disable Tunnel #1, Tunnel #2 works, and vice-versa.

       

      Also, I have noticed that if I have both tunnels enabled, all tunnels drop, their staus goes to N/A, and then they all bring themselves back up seemingly every time I edit, enable, or disable one of these tunnels. That might be a different problem, though.

       

      How should I be doing this?

       

      Tom

        • 1. Re: IPSec: Dealing with conflicting local Subnets

          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.

          • 2. Re: IPSec: Dealing with conflicting local Subnets

            Thank you for the link, Ross. What has changed since v3.x that this no longer works easily?

             

            Tom

            • 3. Re: IPSec: Dealing with conflicting local Subnets

              nothing has change if I understand your question correctly.

               

              The document was written pre v4

              • 4. Re: IPSec: Dealing with conflicting local Subnets

                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.

                 

                Tom

                • 5. Re: IPSec: Dealing with conflicting local Subnets

                  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.

                  1 of 1 people found this helpful
                  • 6. Re: IPSec: Dealing with conflicting local Subnets

                    Ross,

                     

                    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

                     

                    1. Create an IPSec tunnel between Central Device and Remote Device #1 as you would normally. Nothing special is needed for this tunnel.
                    2. Create an IPSec tunnel between Central Device and Remote Device #2 as you normally would, except:    
                      1. On Central Device, specify the local subnet as 192.168.0.0/24 (actual) remote subnet as 10.33.0.0/16 (dummy).
                      2. 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).
                    3. On Remote Device #2, create a new 'Source NAT' NAT rule under Firewall 'NAT'  with the following properties:
                          
                           Descriptive Name:  Outgoing IPSec NETMAP Translation
                           Enable: checked
                           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").
                           Services: Any
                           Translate packet fields
                            To Source Address:Select 'New' and enter the 10.33.0.0/16 (the dummy network).
                    4. 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
                           Enable:  checked
                           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.

                     

                    Tom

                     

                     

                    Message was edited by: trymes on 5/20/10 1:31:28 PM CDT
                    • 7. Re: IPSec: Dealing with conflicting local Subnets

                      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