Tunneling IPv6 over IPv4 networks using cOS Core IPsec

Last modified on 15 Mar, 2023. Revision 24
This article will describe how to tunnel IPv6 traffic over an IPv4 network using IPsec in cOS Core. This is where IPv6 traffic is flowing inside the IPsec tunnel but the tunnel itself is established using IPv4.
Up to date for
cOS Core 14.00.09
Supported since
cOS Core 12.00.xx
Status OK
Anton Hagström & Peter Nilsson

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( <- IPsec -> ( <--> (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 all-nets

Routing table on FW2:

WAN all-nets

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 beef:babe::/64
WAN all-nets

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 all-nets

Routing table on FW2:

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

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

Configuring L2TP/IPsec Server using PSK
11 Jan, 2023 ipsec core vpn
Setup of a Layer-3 bridge over IPsec in cOS Core
12 Apr, 2023 core proxyarp arp ipsec routing
Configuring public certificates in NetWall firewalls
18 Mar, 2024 core certificate oneconnect ipsec vpn
cOS Core L2TP server setup with Windows Server CA certificates
21 Feb, 2023 ipsec certificate windows ca core
Problem with auto-created Core routes
22 Mar, 2021 core ipsec routing
Certificate update in InControl global domain on certificate that is used on firewall(s)
18 Mar, 2024 core incontrol certificate oneconnect ipsec vpn
Setting up OSPF with IPsec in cOS Core
16 Apr, 2024 core routing ospf ipsec
cOS Core IPsec IKEv1 "No_Proposal_Chosen" error in 14.00.10
4 Aug, 2023 core ipsec troubleshoot ike
IPsec license usage calculation
14 Apr, 2021 core license ipsec
Does IPsecBeforeRules trigger before Access rules?
8 Sep, 2020 core ipsec rules access
Split tunneling in cOS Core with Windows L2TP/IPsec clients
29 Mar, 2023 ipsec core windows vpn l2tp
Troubleshooting IPsec tunnels (IKEv1)
7 Dec, 2022 ipsec ike troubleshoot core
cOS Core IKEv2 tunnel setup with certificates for iOS clients
5 Apr, 2023 core nps ipsec radius legacy
Freeing up more memory in the Firewall
23 Aug, 2022 core connections ipsec memory
Route failover with IPsec tunnels in cOS Core
13 Feb, 2023 ipsec core routing failover