The objective

The objective of the setup described in this article is to configure an IPsec tunnel that uses an IPv4 network and encapsulates IPv6 traffic. This would be needed in a scenario where the NetWall firewall at one network site has dual-stack (IPv4/IPv6) provided by the Internet Service Provider (ISP) and the NetWall firewall at other network site is only provided with IPv4 by its ISP.

Note: If no encryption is needed, a cOS Core 6in4 tunnel object could be used to transport IPv6 traffic over IPv4 networks. This article will not discuss the 6in4 option further but more details can be found in the 6in4 section of the cOS Core Administration Guide.

Example topology

The diagram below illustrates the network topology for this example, with two NetWall firewalls, FW1 and FW2, connected to the Internet via two different ISPs. Both firewalls have clients behind them that are using IPv6.

PC1(IPv6) <--> FW1(192.168.122.10) <- IPsec -> (192.168.97.20)FW2 <--> (IPv6) PC2

Configuring the routes

To start with, the routing tables on both firewalls would looks like the following (we have not included the IPv6 routes on the WAN interface in FW1s routing table since they do not matter in this case):

Routing table on FW1:

LAN dead:beef::/64
WAN 192.168.122.0/24
WAN all-nets 192.168.122.1

Routing table on FW2:

LAN 192.168.1.0/24
WAN 192.168.97.0/24
WAN all-nets 192.168.97.1

Since cOS Core is not capable of NAT64, we must configure an internal IPv6 Network on FW2 that PC2 can use to communicate with PC1. This network can be whatever since it’s not routed out on the internet but only internally between the two sites.

After adding an IPv6 network to FW2, its routing table will now look like this:

LAN 192.168.1.0/24
LAN beef:babe::/64
WAN 192.168.97.0/24
WAN all-nets 192.168.97.1

Configuring the IPsec tunnel

The IPsec tunnel will be configured as is normal for an IPv4 scenario. The only difference is that we will use IPv6 networks for the Local and Remote Network properties. We will still use IPv4 IPs as the Remote Endpoint on both sides of the tunnel.

In this scenario we will use the Simplified LAN to LAN VPN object to configure the tunnel in order to keep the amount of work to a minimum (this simplified option is perfectly fine to use in many IPsec tunnel scenarios). To add a LAN to LAN VPN (Simplified) go to Network -> Interfaces and VPN -> IPsec and click Add, as shown below:

Continue configuring the IPsec tunnel, as shown below:

1. Enter a name for the tunnel
2. Add FW2s public IPv4 address
3. Add the Local IPv6 network of FW1
4. Add the local IPv6 network of FW2
5. The option Add route Statically can be left as enabled.
6. In this scenario we will use Pre-shared Key as Authentication Method.
7. Choose a valid PSK object (create a new object if needed)

Perform the same operation on FW2 but use FW1’s Public IPv4 address as the remote endpoint , the local IPv6 network of FW2 as the local network and the local IPv6 network of FW1 as the remote network.

The final routing table contents

The routing tables should now look as following on the two sites.

Routing table on FW1:

LAN dead:beef::/64
Lan_to_Lan_IPv6 beef:babe::/64
WAN 192.168.122.0/24
WAN all-nets 192.168.122.1

Routing table on FW2:

LAN 192.168.1.0/24
LAN beef:babe::/64
Lan_to_Lan_IPv6 dead:beef::/64
WAN 192.168.97.0/24
WAN all-nets 192.168.97.1

Required IP rule set entries

Now we need an IP Policy in the IP rule set that allows traffic over the IPsec tunnel. Here is how that policy should look on the FW1 side:

Note: The above IP rule set entry is an example. To allow traffic both TO and FROM the IPsec tunnel, a second IP rule set entry will be needed that allows traffic from the IPv6_over_IPv4 tunnel interface towards the Lan interface. A similar setup of IP rule set entries will also be needed for FW2.

Related articles