Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    IPSEC VTI with IPv6

    Scheduled Pinned Locked Moved IPsec
    3 Posts 2 Posters 765 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • I
      ink
      last edited by

      Hello all... I am trying to get a VTI tunnel up using IPv6. The entire "stack" is IPv6 end-to-end. The IPSec IKEv2/Phase1 establishment is via IPv6 addresses and the Phase 2 SA is also configured with IPv6 addresses. The far end is a Debian Linux host running StrongSWAN. There is a corresponding IPv4 tunnel to the same host (different IDs, different keys). Both pfSense and the Debain host believe that both the Phase 1 and Phase 2 associations have been established. However on the pfSense side, I never get an IPv6 address assigned to the IPSec VTI interface (in my case ipsec3000. In the web Dashboard it just shows the IP address as "N/A" and looking at the raw interface configuration from CLI, there is just simply no interface assigned.

      Looking in the log (remote syslog), I find the following error:

      daemon.log:Apr 12 23:37:02 XXXXX php-fpm[76150]: /rc.newipsecdns: The command '/sbin/ifconfig 'ipsec3000' inet 'XXXX:XXXX:XXXX:ffff::1/64' 'XXXX:XXXX:XXXX:ffff::2'' returned exit code '1', the output was 'ifconfig: XXXX:XXXX:XXXX:ffff::1/64: bad value (width too large)'

      I've replaced there real IPv6 /48 prefix with Xs but in the log, the addressing is correct. The pfSense side is ::1 and the far end is ::2

      If I ping from other side across the tunnel, I actually can see the packets arrive on the ipsec3000 interface from ::2 to ::1 so IPSec is properly passing the traffic down the tunnel.

      The only other odd thing is the in IPSec status display, for the Subnets on the Phase 2 association, it lists the actual IPs along with the 0/0 entries. The pfSense side is /64 but it lists the far side as /128. I doesn't seem to matter from the IPSec standpoint though.

      Any thoughts?

      1 Reply Last reply Reply Quote 0
      • DerelictD
        Derelict LAYER 8 Netgate
        last edited by

        I think there are problems with IPv6-only VTI interfaces. I would stay away from them for now. Or at least configure a corresponding IPv4 tunnel there even if you never use it. That might be worth a try.

        That said there is no reason to use a /64 there. A /126 or probably /127 would be fine. The addresses on a /127 would be ::0 and ::1 though.

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

        I 1 Reply Last reply Reply Quote 0
        • I
          ink @Derelict
          last edited by

          Yeah, after more playing it doesn't seem that VTI+IPv6 is working right. I tried adding a second SA on the IPv4-based tunnel and it didn't work right at all. I changed it to a GIF over VTI and it came right up with no trouble.

          While it seems a little wasteful, anything less than a /64 causes weird behaviors with IPv6 in certain cases so I've always stuck with that. I know in recent years there have been recommendations on using /127 prefixes on intra-router links (e.g. RFC6164) but this is all interior connections.

          Thanks for the response.

          1 Reply Last reply Reply Quote 0
          • First post
            Last post
          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.