This is a head scratcher to me.
Set up: Linux (openSUSE 15.1, kernel 4.12.14) run as a gateway on my local network. I have an IPv6 tunnel with Hurricane Electric (HE) that has been working just fine. Recently (for some definition of "recently" -- I don't know exactly when it started happening), outgoing IPv6 traffic originating from the gateway itself doesn't go anywhere. Outgoing IPv6 traffic originating from within my network, going through that same gateway, works just fine.
++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++
| | | |
| local | | linux |
| machine |-----|(eth1) gateway (eth0)|---+------ (Internet)
| (xxxx:yyyy:zzzz:wwww::2) | | | ^
++++++++++++++++++++++++++++ | (he-ipv6)|->-^
| (tunnel ip: xxxx:yyyy:a:kkkk::2) |
| (routable ip: xxxx:yyyy:zzzz:wwww::1) |
+++++++++++++++++++++++++++++++++++++++++
Traffic between local machine
and some arbitrary destination (e.g.: ipv6.google.com) goes through the linux gateway
, back and forth, and everything works just fine. When I try to hit the same destination from linux gateway
, it times out. That happens with TCP traffic (I haven't tried UDP yet). ICMP traffic (pings and traceroute with the -I
option) work just fine from both local machine
and linux gateway
. With all that taken into consideration, I think routing is working fine with regards to my setup with HE.
I then looked at the traffic with tcpdump. I noticed a few things when trying to connect from linux gateway
: checksums were reported as incorrect (I'm thinking this may not be a problem as I have tcp checksum offloading on), the MSS was set to 1420 (compared to 1440 on the connection from local machine
) and the source IP being used was the one set on the tunnel itself, which is an IP address assigned by HE for the local and remote sides. I have a couple of routable IP address segments from HE and since I wasn't sure if the interface IP was routable or not, I decided to configure my default route (through the tunnel) to use one of my routable IP addresses (e.g.: xxxx:yyyy:zzzz:wwww::1). Unfortunately it didn't seem to make a difference.
So, summary:
- Pings from any of my source IPs (xxxx:yyyy:zzzz:wwww::1, xxxx:yyyy:zzzz:wwww::2 or xxxx:yyyy:a:kkkk::2) work just fine. Traceroutes using ICMP (
-I
option) also seem to work. - TCP traffic from
local machine
(xxxx:yyyy:zzzz:wwww::2) work fine. - TCP traffic from
linux gateway
(using default route with source set to either xxxx:yyyy:zzzz:wwww::1 or xxxx:yyyy:a:kkkk::2) does NOT work. The default route was set either with the commandip -6 route add default dev he-ipv6
for xxxx:yyyy:a:kkkk::2 (default behavior) orip -6 route add default dev he-ipv6 src xxxx:yyyy:zzzz:wwww::1
).
I did have some firewall rules but even after flushing all of them, things are still not working. Chains INPUT and OUTPUT are empty with default policy set to ACCEPT everywhere in both the filter and nat tables.
# ip6tables -nvL
Chain INPUT (policy ACCEPT 10 packets, 920 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 6 packets, 840 bytes)
pkts bytes target prot opt in out source destination
# ip6tables -nvL -t nat
Chain PREROUTING (policy ACCEPT 1465 packets, 199K bytes)
pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 196 packets, 39942 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 23681 packets, 2588K bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 24950 packets, 2747K bytes)
pkts bytes target prot opt in out source destination
The IPv6 routing table on linux gateway
looks like this right now:
# ip -6 route
xxxx:yyyy:a:kkkk::/64 dev he-ipv6 proto kernel metric 256 pref medium
xxxx:yyyy:wwww:zzzz::/64 dev eth1 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev eth1 proto kernel metric 256 pref medium
fe80::/64 dev br-48888a1d96fc proto kernel metric 256 pref medium
fe80::/64 dev veth3d7d8bf proto kernel metric 256 pref medium
fe80::/64 dev vethda6ce4c proto kernel metric 256 pref medium
fe80::/64 dev he-ipv6 proto kernel metric 256 pref medium
default dev he-ipv6 metric 1024 pref medium
Link information for the various interfaces on linux gateway
:
# ip -6 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 fe80::20c:29ff:fe46:a11a/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 xxxx:yyyy:zzzz:wwww::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::20c:29ff:fe46:a124/64 scope link
valid_lft forever preferred_lft forever
6: br-48888a1d96fc: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP
inet6 fe80::42:28ff:fe32:fc18/64 scope link
valid_lft forever preferred_lft forever
9: veth3d7d8bf@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP
inet6 fe80::4c54:d8ff:fe36:6b86/64 scope link
valid_lft forever preferred_lft forever
11: vethda6ce4c@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP
inet6 fe80::b0a7:74ff:fed6:755f/64 scope link
valid_lft forever preferred_lft forever
13: he-ipv6@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1480 state UNKNOWN qlen 1000
inet6 xxxx:yyyy:a:kkkk::2/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::327d:f340/64 scope link
valid_lft forever preferred_lft forever
Specific configuration for the IPv6 tunnel:
# ip addr show dev he-ipv6
13: he-ipv6@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1480 qdisc noqueue state UNKNOWN group default qlen 1000
link/sit a.b.c.d peer 216.218.226.238
inet6 xxxx:yyyy:a:kkkk::2/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::327d:f340/64 scope link
valid_lft forever preferred_lft forever
# ip addr show dev sit0
4: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
link/sit 0.0.0.0 brd 0.0.0.0
IP address a.b.c.d is a static IPv4 address associated with eth0.
I'm sure I'm missing something obvious, but I can't see it. What am I missing?
Thanks!