Hi,
I would be very happy if you could help me regarding the - hopefully tiny - final step towards completing the setup of an IPv6-tunnel via tunnelbroker. I run this tunnel since the year 2009 using various opensource routing platforms in the past. Currently it’s established via *Sense, a platform which I would like to replace against vyos, as soon as the tunnelbroker connection works.
I use vyos 1.5-nightly. These are the current settings:
#Tunnel settings:
#----------------
vyos@vyos# show interfaces tunnel
tunnel tun0 {
address 2001:470:____:____::2/64
description "HE.NET IPv6 Tunnel"
encapsulation sit
remote 216.66.xx.xx
source-address 0.0.0.0
}
#Routing settings:
#-----------------
vyos@vyos# sho protocols static route6 ::/0
next-hop 2001:470:____:____::1 {
interface tun0
}
[edit]
#Firewall settings:
#------------------
vyos@vyos# show firewall ipv4
Configuration under specified path is empty
vyos@vyos# show firewall ipv6
Configuration under specified path is empty
vyos@vyos# show firewall global-options
all-ping enable
broadcast-ping disable
ipv6-receive-redirects disable
ipv6-src-route disable
ip-src-route disable
log-martians enable
receive-redirects disable
send-redirects disable
source-validation disable
syn-cookies enable
twa-hazards-protection disable
With these settings the tunnel seems to be established fine, but ping6-ing works only partially:
-
Pinging inside->out (LAN to IPv6-internet):
1.1. ping6 from vyos to TB server IPv6 addr (2001:470:____:____::1/64) works fine.
1.2. ping6 from clients to TB server IPv6 addr (2001:470:____:____::1/64) works fine, too.
1.3. ping6 from vyos or clients to anywhere else (eg.2001:470:20:1) doesn’t work. -
Pinging outside->in (IPv6-internet to LAN)
2.1. ping6 from internet to the TB client IPv6 addr (2001:470:____:____::2/64) doesn’t work.
2.1. ping6 from internet to internal addresses doesn’t work.
Some remarks regarding 2. (outside->in):
Using tcpdump on ppp0 and tun0 I can see the pings from outside arriving at pppoe0 and tun0:
Here is the output of ping and tcpdump (pppoe0 and tun0) while ping6ing from 2001:470:____:____::00c0:ffee to the TB client IPv6 addr (2001:470:____:____::2/64):
user@host:~$ ping 2001:470:____:____::2
PING 2001:470:____:____::2 (2001:470:____:____::2) 56 data bytes
^C
--- 2001:470:____:____::2 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 4075ms
tcpdump shows, that the ping at least arrives on pppoe0 …
vyos@vyos:~$ tcpdump -ni pppoe0 host 216.66.xx.xx
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on pppoe0, link-type LINUX_SLL (Linux cooked v1), snapshot length 262144 bytes
14:42:34.229947 IP 216.66.xx.xx > 62.xx.xx.228: IP6 2001:470:____:____::00c0:ffee > 2001:470:____:____::2: ICMP6, echo request, id 4937, seq 1, length 64
14:42:35.233426 IP 216.66.xx.xx > 62.xx.xx.228: IP6 2001:470:____:____::00c0:ffee > 2001:470:____:____::2: ICMP6, echo request, id 4937, seq 2, length 64
14:42:36.257615 IP 216.66.xx.xx > 62.xx.xx.228: IP6 2001:470:____:____::00c0:ffee > 2001:470:____:____::2: ICMP6, echo request, id 4937, seq 3, length 64
14:42:38.305652 IP 216.66.xx.xx > 62.xx.xx.228: IP6 2001:470:____:____::00c0:ffee > 2001:470:____:____::2: ICMP6, echo request, id 4937, seq 5, length 64
… as well as on tun0:
vyos@vyos:~$ tcpdump -ni tun0
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
14:42:34.229947 IP6 2001:470:____:____::00c0:ffee > 2001:470:____:____::2: ICMP6, echo request, id 4937, seq 1, length 64
14:42:35.233426 IP6 2001:470:____:____::00c0:ffee > 2001:470:____:____::2: ICMP6, echo request, id 4937, seq 2, length 64
14:42:36.257615 IP6 2001:470:____:____::00c0:ffee > 2001:470:____:____::2: ICMP6, echo request, id 4937, seq 3, length 64
14:42:38.305652 IP6 2001:470:____:____::00c0:ffee > 2001:470:____:____::2: ICMP6, echo request, id 4937, seq 5, length 64
I can’t find the configuration error, and even worse I’m out of ideas - probably because I ran out of c0ffee and the delivery of new capsules/pakets is currently blocked. 
Ohh no, there’s one last thing/idea:
During my investigations I stumbled over ip addr show’s output. It looks strange to me especially the interface sit0, which is DOWN.
Why is it down? Could this be the cause for the problems? Could it be an MTU issue? Questions over question … The most important for me is: How can I further debug the problem using vyos?
12: pppoe0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc fq_codel state UNKNOWN group default qlen 3
link/ppp
inet 62.____:____.228 peer 62.____:____.245/32 scope global pppoe0
valid_lft forever preferred_lft forever
inet6 fe80::f531:____:____:cc1c/64 scope link
valid_lft forever preferred_lft forever
inet6 fe80::a1f1:____:____:b6af peer fe80::c203:____:____:83fe/128 scope link
valid_lft forever preferred_lft forever
13: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
link/sit 0.0.0.0 brd 0.0.0.0
14: tun0@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1476 qdisc noqueue state UNKNOWN group default qlen 1000
link/sit 0.0.0.0 peer 216.66.xx.xx
inet6 2001:470:____:____::2/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::f0c7:____:____:1f71/64 scope link
valid_lft forever preferred_lft forever
Thank you very much for your assistance!
Best regards,
vyozzy
- but only for a relatively short period of time: After some seconds/minutes the IPv6 default route is pointing to pppoe0 again.