Page 1 of 1

IPsec tunnels and ARP published IPs (9.x)

Posted: 26 Mar 2012, 13:01
by Peter
This How-to applies to:
  • Clavister Security Gateway 8.x, 9.x and 10.x, How-To based on version 9.30.
Problem:

Per default it is not possible to terminate or initiate an IPsec tunnel on any other IP address than the one assigned to an interface. This How-To will describe a way to bypass this problem using Policy based routing, loopback and normal rules.

Important note: In version 10.20.x this issue has been resolved, the new IPsec engine supports terminating IPsec tunnels on ARP published IP's by default.

Topics covered in this How-To:
  • 1. Base network example/setup.
    1.1. Objects.
    2. ARP Publish.
    3. The IPsec tunnel setup.
    4. Creating the first loopback interface.
    4.1. Creating the second loopback interface.
    5. Creating the new routing table.
    5.1. Adding the required routes to the new routing table.
    6. The policy based routing rule.
    7. Creating the rules needed for the address translation and traffic management.
    8. Final word.
    9. Sample flow.
    10. Sample configuration.
    11. Troubleshooting.
    12. Alternative solution using GRE encapsulation.
Important note: This How-To only applies to Lan2Lan tunnels where the remote endpoint is configured with static IP. Roaming tunnels/clients will not work.

1. Base network example/setup:

In order to try keep the example as simple as possible we will use only one IP ARP published IP address and one IPsec tunnel in this example. Once it is setup it can easily be duplicated to use more tunnels and IP addresses.

Code: Select all

SGW-1(192.168.98.14) --- Switch --- SGW-2 (192.168.98.11)
So what we are going to do here is to ARP publish the IP 192.168.98.15 on SGW-1 then use that IP to initiate a tunnel towards SGW-2 and make it work in the reverse order as well, where SGW-2 can initiate towards SGW-1.

1.1. Objects:

Some of the objects that are relevant to the description and are used in the sample configuration (sample configuration can be found further down).
1.png
1.png (18.39 KiB) Viewed 6017 times
  • Ip_if1 = 192.168.98.14
The “external” interface IP of SGW-1
  • ARP_98_15 = 192.168.98.15
The ARP published IP address on SGW-1
  • LoopBackNet = 172.16.0.0/24
The network used the IPsec tunnel(s) to initiate and terminate the tunnel. More on this later.
  • LoopBack_Gateway_1 = 172.16.0.100
The IP address used by the IPsec tunnel as Remote Endpoint. Each tunnel that wants to initiate/terminate on an ARP published IP must have a unique IP address in the “LoopBackNet” IP range.
  • Tunnel-1-Gateway = 192.168.98.11
The “external” IP address used by SGW-2 and to which we will terminate and initiate the tunnel once the setup is complete.

2. ARP Publish.

First we start by adding the IP address we want to use for initiation and termination of our IPsec tunnels. We do that under Interfaces->ARP/Neighbor Discovery.
2.png
2.png (3.82 KiB) Viewed 6017 times
  • Mode=Publish
    Interface=if1
    IP address=ARP_98_15
    MAC=default (00-00-etc)
3. The IPsec tunnel setup.

The only thing we need to take note of when setting up the IPsec tunnel is the Remote Endpoint. The local Network and Remote network does not affect the overall setup in this scenario, we use a /24 network as local and remot network and Tunnel mode as encapsulation. It is of course important to make the remote side’s network match in order for the tunnel to establish, but that is not the goal of this article.

The Remote Endpoint will use the object Loopback_Gateway_1 (172.16.0.100). More on the reason for this later.

4. Creating the first loopback interface

Loopback interfaces always comes in pairs, connected to each other. Basically data that is routed/sent into the first loopback interface comes out on the second loopback interface, and wise versa. More information about the specifics of loopback can be found in the manual section 3.4.6 (9.30.03).
  • Name=Main_VPN
    Loop To=<none>
    IP address=ARP_98_15
    Network=Localhost (127.0.0.1)
The interface must also be a specific member of the <main> routing table, you set this under the Virtual Routing tab.

Since the second loopback interface is not created yet we cannot select anything to “Loop To” at this stage.

4.1. Creating the second loopback interface.
  • Name=VPN_Main
    Loop TO=Main_VPN
    IP address=Localhost(127.0.0.1)
    Network=Localhost(127.0.0.1)
The interface must also be a specific member of the <VPN_ARP> routing table, you set this under the Virtual Routing tab. (This routing table is created in step 5)

Now go back to the Main_VPN loopback interface and change its “Loop To” to be VPN_Main.
3.png
3.png (6.87 KiB) Viewed 6017 times
5. Creating the new routing table.

Now we must create a new routing table that will be used by the second loopback interface and also the external interface in order to terminate/initiate the “ARP” IPsec tunnel.

Go to Routing Tables and create a new routing table, since we use loopback to send traffic to/from the tunnel and also between different routing tables we do not have any need to check the <main> routing table automatically using Default or First ordering.
  • Name=VPN_ARP
    Ordering=Only
5.1. Adding the required routes to the new routing table.

We add the following routes:
  • Route-1 Interface=if1
    Route-1 Network=if1net

    Route-2 Interface=if1
    Route-2 Network=all-nets
    Route-2 Gateway=gw-world

    Route-3 Interface=VPN_Main
    Route-3 Network=ARP_98_15
4.png
4.png (13.74 KiB) Viewed 6017 times
6. The policy based routing rule.

In order to handle incoming IPsec connections we need to create a PBR rule that handles traffic arriving on the external interface and make it use the VPN_ARP routing table. This is required as we have not made the external interface if1 a specific member of any routing tables. We do not want to do that either as everything except this specific traffic to the ARP published IP should behave normally.
  • Name=Incoming_IPsec
    Forward=VPN_ARP
    Return=VPN_ARP
    Service=IPsec-Suite
    Source Interface=if1
    Source Network=all-nets
    Destination Interface=Core
    Destination Network=ARP_98_15
5.png
5.png (10.53 KiB) Viewed 6017 times
This rule’s purpose is to handle incoming IPsec packets to the ARP published IP in the <main> routing table, and then redirect the packets to use the VPN_ARP routing table.

7. Creating the rules needed for the address translation and traffic management.

A total of 3 rules are needed to handle both incoming and outgoing IPsec connections to the ARP published IP.
  • Name=VPN_SAT_RemoteGW
    Action=SAT
    Service=ipsec-suite (standard pre-defined service)
    Source Interface=VPN_Main
    Source Network=all-nets
    Destination Interface=if1
    Destination network=LoopBack_Gateway_1
    Translate Destination IP to New IP address=Tunnel-1-Gateway
The second rule is a copy of the above rule and its action changed from SAT to Allow.

Traffic sent to the first loopback interface (Main_VPN) will automatically arrive on the second loopback interface (VPN_Main), and once it is here we can redirect the IPsec traffic using normal rules.

So what we do with this SAT/Allow rule is to take traffic sent to the “temporary” Remote Endpoint IP address 172.16.0.100 (LoopBack_Gateway_1) and forward it to the REAL Remote Endpoint IP address on the internet.

Note: Don’t get confused by the use of private IP address in this How-To, Tunnel-1-Gateway (192.168.98.11) should be considered a “public” IP address.

Since traffic in this case is initiated from the Core regarding IPsec tunnel(s), then sent to a loopback interface, the source IP address will be the interface address of the first loopback interface (Main_VPN) which is our ARP published IP address. This is the reason why we set the ARP published IP address on the Main_VPN loopback interface in step 4, and why we can use SAT/Allow instead of SAT/NAT.

So now traffic is sent to the remote Endpoint (SGW-2) with the correct source and to the correct destination IP addresses. These two rules handles the traffic when this unit/machine is the initiator of the traffic, now we will need one more rule to handle incoming IPsec traffic as well, where we are not the initiator.
  • Name=VPN_SAT_RemoteGW
    Action=NAT
    Service=ipsec-suite (standard pre-defined service)
    Source Interface=if1
    Source Network=Tunnel-1-Gateway
    Destination Interface=any
    Destination network=ARP_98_15
    Specify sender address=LoopBack_Gateway_1
This rule will trigger when IPsec related traffic are initiated from the public IP address of the remote device towards the ARP published IP (ARP_98_15). Then translate it to the LoopBack_Gateway_1 private address (172.16.0.100) when sending the request to the route matching the destination IP address, which will be the loopback interface called VPN_Main. As the ARP published IP is routed there.

So the IPsec engine will then be able to match the Remote Endpoint 172.16.0.100 (LoopBack_Gateway_1) with the IPsec tunnel in the configuration and it can establish in the incoming direction as well.
6.png
6.png (21.83 KiB) Viewed 6017 times
8. Final word.

If everything is configured correctly you should now be able to initiate and terminate IPsec tunnels towards any other IP address than used by the physical interface. A restriction that has caused problems for users for a long time.

The configuration is very complex and it is highly recommend that you have good knowledge and understanding of Clavister products before you attempt this setup.

Some users may notice that we use ARP Publish in this example instead of Core Routes and ProxyARP, but that is intentionally as the ARP IP address is Core routed automatically when defined on the first Loopback interface.

It will also not work to use ProxyARP, as loopback interfaces does not have a ProxyARP option. An interface Core route will be used before a manually defined one.

So without using a normal ARP publish, the unit would not respond to ARP queries towards the ARP published IP.

The loopback interface and routes are configured in such a way that you can easily add more IPsec tunnels towards the same ARP IP address with very few changes. The only thing you need is to make a copy of the three main rules (SAT, Allow and NAT) and make them match the private IP address chosen for the new tunnel and also for the public remote endpoint on the internet.

Adding more ARP published IP addresses is more work though as you need to setup more Loopback interfaces, networks and routes, but once the base scenario is up and running you should easily be able to replicate it.

9. Sample flow.

In order to get a better view/understanding of what is happening, a description of the traffic flow:

Note: The networks defined in the example configuration will be used.
  • 9.1. A user on the local network if2net (10.10.2.0/24) wants to reach the host 10.10.10.50.
    9.2. A route lookup on 10.10.10.50 will result in a match on the following route:

    Route IPv4 IPsecTunnel-1 10.10.10.0/24

    9.3. IPsecTunnel-1 is an IPsec interface, IPsec tunnel negotiations will be sent to the tunnels Remote Endpoint, the target IP address in this case is LoopBack_Gateway_1 (172.16.0.100)
    9.4. A route lookup on 172.16.0.100 will result in a match on the following route:

    Route IPv4 Main_VPN LoopBackNet (172.16.0.0/24)

    9.5. Main_VPN is the first loopback pair, which has the ARP published IP address (ARP_98_15) defined as it’s IP address.
    9.5.1. Traffic sent to the Main_VPN Loopback interface will automatically arrive on the matching VPN_Main loopback interface, the source IP address will be the ARP published IP (ARP_98_15) as the traffic is initiated from the Core.
    9.6. When traffic arrives on the secondary Loopback interface (VPN_Main), a SAT/Allow rule will trigger and pick up the traffic, then change the destination IP address from LoopBack_Gateway_1 (172.16.0.100) to be Tunnel-1-Gateway (192.168.98.11). Which is the “public” IP address of the remote endpoint on the internet.
    9.7. A route lookup for 192.168.98.11 will result in a match on the following route:

    Route IPv4 if1 if1net(192.168.96.0/20)

    Important note: Normally it would match the all-nets route, but since this is an internal lab setup, it will not.

    9.8. A tunnel negotiation is now sent using the source IP 192.168.98.15 to the destination 192.168.98.11 and the tunnel can be established. The entire return chain will work automatically due to state tracked connections being created in the various steps above.
10. Sample configuration.

The configuration used to describe the setup can be found here:
ARP_Loopback_Final.zip
(6.31 KiB) Downloaded 282 times
11. Troubleshooting.

Troubleshooting this scenario can be tricky as there are many steps and many ways things can go wrong. There are however several CLI commands that are very useful:

11.1. “Routes –lookup=<ip>”

This command will directly tell you where the IP address defined is routed. It is very useful to verify that the correct route is triggering.

11.2. “Rules –v 1-3”

This command is useful to verify that the configured rules are triggering. 1-3 in this case means that we want to look at rule 1 through 3 and –v means verbose. Verbose mode will print out the “usage” of a rule. If you have the scenario setup and when you test have “use : 0”, then you need to try figure out why the rule does not trigger for the intended traffic, perhaps a routing problem or an IP address written incorrectly.

11.3. PCAPDump

This command is extremely useful to verify pretty much all aspects of the traffic being handled. If you for instance want to verify that the sender address is correctly used on a specific interface, simply use the PCAPDump command to capture packets on the defined interface.

If the traffic flow is very low you could make the pcapdump command send the output directly to the screen using the “-out-nocap” flag. Use with caution though as if there is a lot of traffic on the designated interface it will flood the console, adding extra filters in those cases is highly recommended.

And last but not least I would like to thank Roger Forsberg for his insight and knowledge in making this possible.

Re: Initiating/terminating IPsec tunnels on ARP published IP

Posted: 07 Dec 2012, 11:01
by Peter
12. Alternative solution using GRE encapsulation.

Internal lab tests has provided with an alternative solution to this problem that, if works according to specification, is a MUCH easier way to get this scenario to work.

The basic principle is that we encapsulate the IPsec tunnel in a GRE tunnel. Since GRE tunnels can terminate/initiate on an ARP published IP we bypass the ARP problem with IPsec altogether. There will be some extra overhead size on the packets due to double encapsulation so in terms of performance it will be slightly slower.

A simple example:

Site-A
GRE tunnel from 85.85.85.85 to 90.90.90.90, both these IP's are ARP published IP's. On that GRE tunnel we route the network 10.10.10.0/24 and give the GRE tunnel the IP 10.10.10.1

IPsec tunnel is configured with a remote endpoint of 10.10.10.2, the networks inside the IPsec tunnel is not relevant to this example as it will be whatever network the administrator want bridge between Site-A and B.

Site-B
GRE tunnel from 90.90.90.90 to 85.85.85.85 , both these IP's are ARP published IP's. On that GRE tunnel we route the network 10.10.10.0/24 and give the GRE tunnel the IP 10.10.10.2

IPsec tunnel is configured with a remote endpoint of 10.10.10.1, the networks inside the IPsec tunnel is not relevant to this example as it will be whatever network the administrator want bridge between Site-B and A.

This means that whenever the IPsec tunnel needs to establish, it will try find the interface where it's remote network is routed, and since that is a GRE tunnel the GRE tunnel will establish towards the ARP published IP on the remote side and inside the GRE tunnel the IPsec tunnel will establish.

Re: IPsec tunnels and ARP published IPs (9.x)

Posted: 02 Dec 2016, 11:11
by mape
Important note: In version 10.20.x this issue has been resolved, the new IPsec engine supports terminating IPsec tunnels on ARP published IP's by default.