1

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 command ip -6 route add default dev he-ipv6 for xxxx:yyyy:a:kkkk::2 (default behavior) or ip -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!

Improve this question
3
  • Please show the running configuration of the he-ipv6 interface, i.e. ip a s dev he-ipv6. I suspect a typo somewhere in your configuration, but you have obfuscated all of the relevant bits (we recommend that you do not obfuscate whenever possible).
    – Michael Hampton
    Sep 27, 2020 at 22:15
  • Sorry for the obfuscation, I understand it makes it harder, but these are statically assigned and I don't feel like exposing these on a public forum. I added the output you were looking for, although I think it was already in original message. I added it anyways, this time with some IPv4 information as well. Keep in mind that traffic from local machine, which has a public IPv6 address assigned works fine.
    – Bruno da Costa
    Sep 28, 2020 at 0:43
  • BTW, I just learned about the 2001:db8::/32 IP range, defined in RFC 3849, to be used in documentation. I can use that instead of the way I obfuscated my IP addresses if that helps.
    – Bruno da Costa
    Sep 28, 2020 at 2:41

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .