Problems with Hurricane Electric IPv6 Tunnel

cprosser · March 7, 2021, 3:25am

Hi folks,

I’m having a confusing problem trying to configure an IPv6 tunnel from hurricane electric. It looks like the syntax has changed from this config example: https://docs.vyos.io/en/latest/configexamples/tunnelbroker-ipv6.html#examples-tunnelbroker-ipv6

I can’t show you what the original text is as I’m a new user and it’s being interpreted as a link.

I translated it to:

But when I do that, I lose ipv4 connectivity.
vyos@vyos# ping google_dns_as_ip
connect: Network is unreachable

I can’t ping through the tunnel either. I have this box set up behind pfSense, and as you’d expect no packets are making it off vyos.

(Sorry about the text as pictures, it was being interpreted as links and I was not allowed to post as a new user)

Thoughts?

thanks,
Chris

firedrow · March 7, 2021, 3:55am

I’m brain fried from Exchange work this week. But I’ll try to setup a test tomorrow or Monday and test this. I’m curious.

Dmitry · March 7, 2021, 7:17am

Hello @cprosser, which VyOS version are you using?
I successfully tested on the latest 1.4 and 1.2.6-S1.

set interfaces tunnel tun0 address '2001:470:xx:xx::2/64'
set interfaces tunnel tun0 description 'HE.NET IPv6 Tunnel'
set interfaces tunnel tun0 encapsulation 'sit'
set interfaces tunnel tun0 multicast 'disable'
set interfaces tunnel tun0 remote '216.66.84.46'
set interfaces tunnel tun0 source-address 'x.x.36.246'
set protocols static route6 ::/0 interface tun0

Checking

vyos@RTR1# run ping google.com count 2
PING google.com(ams16s22-in-x0e.1e100.net (2a00:1450:400e:803::200e)) 56 data bytes
64 bytes from ams16s22-in-x0e.1e100.net (2a00:1450:400e:803::200e): icmp_seq=1 ttl=121 time=3.78 ms
64 bytes from ams16s22-in-x0e.1e100.net (2a00:1450:400e:803::200e): icmp_seq=2 ttl=121 time=3.85 ms

--- google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 2ms
rtt min/avg/max/mdev = 3.776/3.814/3.852/0.038 ms
[edit]

cprosser · March 7, 2021, 4:38pm

Thanks for the quick response. I was hoping to blame the latest rolling release

Version:          VyOS 1.4-rolling-202103040218
Release Train:    sagitta

Built by:         autobuild@vyos.net
Built on:         Thu 04 Mar 2021 02:18 UTC
Build UUID:       eede2569-5089-4177-8cb4-215f7e75f50b
Build Commit ID:  39ab069e421c6e

Architecture:     x86_64
Boot via:         installed image
System type:      Xen HVM guest

Hardware vendor:  Xen
Hardware model:   HVM domU
Hardware S/N:     ba300711-1a78-ee46-2a6b-fc40706d63f8
Hardware UUID:    ba300711-1a78-ee46-2a6b-fc40706d63f8

Copyright:        VyOS maintainers and contributors

So it sounds like I did the syntax translation correctly and there is something else wrong in my set up. I’m coming from a slightly advanced beginner on EdgeOS and I’m doing this whole project to become more proficient with networking’s, specifically IPv6. So no surprise there.

Here’s my basic config before I add the tunnel, it’s incredibly stripped-down. I’m wondering if the lack of configuration of IPv4 on the lan side might be contributing something weird.

set interfaces ethernet eth0 address 'dhcp'
set interfaces ethernet eth0 description 'WAN'
set interfaces ethernet eth0 hw-id 'XX:XX:XX:XX:XX:36'
set interfaces ethernet eth1 address 'xxx.xxx.4.1/24'
set interfaces ethernet eth1 description 'LAN'
set interfaces ethernet eth1 hw-id 'XX:XX:XX:XX:XX:b8'
set interfaces loopback lo
set service ssh port '22'
set system config-management commit-revisions '100'
set system console device ttyS0 speed '115200'
set system host-name xxxxxx
set system login user xxxxxx authentication encrypted-password xxxxxx
set system login user xxxxxx authentication plaintext-password xxxxxx
set system ntp server xxxxx.tld
set system ntp server xxxxx.tld
set system ntp server xxxxx.tld
set system syslog global facility all level 'info'
set system syslog global facility protocols level 'debug'

I’m not going to have much time to look at this until next weekend. So thank you in advance for any suggestions on what I should experiment with.

–chris

Dmitry · March 7, 2021, 7:10pm

Ok, as I understand you have VyOS behind NAT. Which source-address are you trying to use? As I remember HE broker require a static remote IP addresses.

cprosser · March 7, 2021, 11:22pm

Remember correctly that my vyos device is behind my pfSense router. I’m using the WAN ip address from pfSense that is exposed to the world as the local-ip for the tunnel (I figured I wanted it to match what hurricane electric showed on the registry). I also set up an ICMP pass rule to allow hurricane electric to ping my outside router.

I also went back and re-created this situation in
Version: VyOS 1.3.0-rc1
Release Train: equuleus

The behavior I’m getting there is a little different. In this case IPv4 continues to work correctly even though I still can’t send v6 packets.

The box seems to think that the tunnel is up, but I’m not sure I agree with it.

vyos@vyos:~$ show interfaces
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface        IP Address                        S/L  Description
---------        ----------                        ---  -----------
eth0             192.150.23.231/24                 u/u  wan
lo               127.0.0.1/8                       u/u
                 ::1/128
tun0             2001:470:a:454::2/64              u/u  HE.NET IPv6 Tunnel

vyos@vyos:~$ ping6 2a00:1450:400e:803::200e
PING 2a00:1450:400e:803::200e(2a00:1450:400e:803::200e) 56 data bytes
From 2001:470:a:454::2: icmp_seq=1 Destination unreachable: Address unreachable
From 2001:470:a:454::2: icmp_seq=2 Destination unreachable: Address unreachable
From 2001:470:a:454::2: icmp_seq=3 Destination unreachable: Address unreachable
From 2001:470:a:454::2: icmp_seq=4 Destination unreachable: Address unreachable
^C
--- 2a00:1450:400e:803::200e ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 71ms

vyos@vyos:~$ traceroute 2a00:1450:400e:803::200e
traceroute to 2a00:1450:400e:803::200e (2a00:1450:400e:803::200e), 30 hops max, 80 byte packets
 1  2001:470:a:454::2 (2001:470:a:454::2)  0.021 ms !H  0.005 ms !H  0.005 ms !H

The trace route makes it look like vyos is trying to place the packet in the end of the tunnel, but then it’s not going anywhere. Am I reading that right?

Thanks again for all your help,
Chris

firedrow · March 8, 2021, 5:21am

I haven’t lab’d yet, but try forwarding protocol 41 through your pfSense to VyOS. That should allow 6-to-4 traffic, which from my understanding is the sit tunnel.

cprosser · March 13, 2021, 5:18pm

I figured out the key to getting this to work was changing my tunnel local IP address from being the one exposed on the external pfSense firewall to instead the private IPV4 address of the vyos node itself. That allowed vyos to figure out the ipv4 routing off the device for the tunnel.

I also modified pfSense to check “Enable IPv6 over IPv4 tunneling” under System->Advanced->Networking.

Lastly I created a floating rule that was above my traffic shaping rule to pass IPv6 protocol packets (which I believe is how pfSense represents protocol 41 per https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers). I also set “Apply the action immediately on match.” To the rule as it’s not clear to me from documentation I read whether the traffic shaper I’m using would eat the packets.

I’m not 100% sure that I have the pfSense configuration correct yet. But I am successfully pinging and tracerouting from vyos over the tunnel now.

system · March 15, 2021, 5:18pm

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.