IPv6 through IPv4 VPN Tunnel with Palo Alto

The most common transition method for IPv6 (that is: how to enable IPv6 on a network that does not have a native IPv6 connection to the Internet) is a “6in4” tunnel. Other tunneling methods such as Teredo or SixXS are found on different literatures as well. However, another method that is not often explained is to tunnel the IPv6 packets through a normal VPN connection. For example, if the main office has a native IPv6 connection to the Internet as well as VPN connections to its remote offices, it is easy to bring IPv6 subnets to these stations. Here comes an example with two Palo Alto firewalls.

This is one of many VPN tutorials on my blog. Please look here to find the appropriate one. Furthermore, this post is very similar to this one in which I covered Juniper ScreenOS firewalls.

I assume that there is already a VPN connection between two Palo Alto firewalls in place. If so, the steps to tunnel IPv6 through this VPN tunnel are quite easy. (Note that this is NOT a 6in4 tunnel! It is simply a forwarding of IPv6 packets through a common IPsec site-to-site VPN.)


I am using two PA-200 firewalls with PAN-OS 7.1.1. One firewall has a static IPv4 address, the other one is dynamic. I am routing a /60 through the tunnel to have a maximum of 16 subnets on the remote site. This is how the lab looks like:

IPv6 through IPv4 VPN Tunnel Palo Alto - Lab

The basic step is to enable IPv6 on the tunnel interfaces and to route the IPv6 traffic appropriately. Of course, all other interface configuration steps such as router advertisements as well as security policies must be configured, too.

Main Site

These are the configuration steps on the main site in order to route the IPv6 subnet through the tunnel. See the screenshot descriptions for more details:

Remote Site

Very similar: the remote site. Note the default IPv6 route through the tunnel:

Latency & Hop Count

After committing everything the traffic log shows some IPv6 connections, either from trust to vpn-s2s (on the remote site), or from vpn-s2s to untrust (on the main site):

It is interesting to see the IPv6 ping times from the remote site compared to the IPv4 ping times. Since the IPv6 connections must travel through the IPv4 VPN tunnel via the Internet before reaching the real destination, the RTT should be much higher than the IPv4 times. However, everything is relative. ;) The ping times (IPv6 and IPv4) on my main site are both around 5-8 ms in the following example:

But since my remote site is a DSL connection with a slower latency at all, the IPv6 burden is not that high, as seen here. Both connections are around 30 ms:


That’s it.

Featured image “Golden Tunnel” by Sam Bald is licensed under CC BY 2.0.

4 thoughts on “IPv6 through IPv4 VPN Tunnel with Palo Alto

  1. Pretty element of content. I simply stumbled upon your blog and in accession capital to say that I acquire actually loved account your
    blog posts. Anyway I’ll be subscribing on your feeds and even I fulfillment you get right of
    entry to constantly rapidly.

  2. Here’s a little config for connecting a Palo Alto Firewall and a linux box using IPSec.

    I used ubuntu because it’s currently my favourite distribution. But I guess you can use almost anything that comes with a recent kernel version.

    Keep in mind Palo Alto IPSec VPNs are always route based. You can define Proxy IDs but you don’t have to.

    After the mandatory “apt install strongswan” I wanted to use the new xfrm interfaces for IPSec:

    cat /etc/systemd/system/ipsec.service.d/xfrm.conf
    ExecStartPre=/usr/sbin/ip link add ipsec0 type xfrm dev if_id 1
    ExecStartPre=/usr/sbin/ip link set ipsec0 up
    ExecStartPre=/usr/sbin/ip -6 route add 200x:yyy:zzz:abcd::/64 dev ipsec0
    ExecStopPost=/usr/sbin/ip link del ipsec0

    Next set up the connection:

    In this case the linux box has a static IPv4 address. The Palo is behind an AVM Fritzbox with a dynamic ip.

    cat /etc/swanctl/conf.d/paloalto.conf
    connections {

    paloalto {
    local_addrs =

    if_id_in = 1
    if_id_out = 1

    local {
    auth = pubkey
    certs = my.pem
    remote {
    auth = pubkey
    id = “C=DE, O=Saftladen, CN=guru.saftladen.”
    children {
    connection1 {
    local_ts = ::/0
    remote_ts = ::/0
    mode = tunnel
    rekey_time = 1h
    esp_proposals = aes256gcm16-ecp384
    #start_action = start
    version = 2
    mobike = no
    reauth_time = 8h
    proposals = aes256-sha384-ecp384

    Hence we cannot start the tunnel right away. The Palo has to initiate the connection because of the dynamic ip.

    Next put the certificates and the private key in:

    I created my ssl certificates on the Palo Firewall.

    Have fun!

Leave a Reply

Your email address will not be published. Required fields are marked *