[Solved] IPv6 from 6rd tunnel on LAN

I'm running LEDE Reboot 17.01.0 r3205-59508e3 (release) on Archer C7 v2. My ISP supply IPv6 through 6rd tunnel.

TL;DR: ISP's 6rd IPv6 is assigned to LAN (br-lan), not WAN. There is not NAT with IPv6 and all devices are exposed to the Internet, so you need good IPv6 firewall rules (e.g. block IPv6 traffic originating from WAN going to LAN).

In the past I've tried to configure IPv6 without success and I gave up (everything was reset to DHCP).

Recently I noticed that I was getting an ISP's IPv6 on my router and all networks peripherals. I was expecting my WAN6 or WAN interface to get the ISP's IPv6 address, but it's the LAN interface that gets it. :open_mouth:

Could that expose all my devices directly and insecurely to the Internet through IPv6, including IoT ? Did I seriously messed things up while experimenting back then ? Can someone confirm/explain/point me to the right documentation ?

I'm running SQM with cake/piece_of_cake, and I've created a Guest network for WLAN. When I go to https://www.whatismyip.com/, it shows my IPv6 address and http://test-ipv6.com/ reports that I have a working IPv6 setup using 6rd.

Here is a screenshot of my Luci interfaces:

Here is "ifconfig" for relevant interfaces (note that 6rd-wan_6 is not a creation of mine so I assume it was auto-created):

6rd-wan_6 Link encap:IPv6-in-IPv4
          inet6 addr: ::xxxx:xxxx/96 Scope:Compat
          inet6 addr: 2607:xxxx:xxxx:xxxx::1/45 Scope:Global
          UP RUNNING NOARP  MTU:1280  Metric:1

br-lan    Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:3A
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::xxxx:xxxx:xxxx:xxxx/64 Scope:Link
          inet6 addr: 2607:xxxx:xxxx:xxxx::1/60 Scope:Global
          inet6 addr: fdc3:xxxx:xxxx::1/60 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

(wan)
eth0      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:3E
          inet addr:xxx.xxx.xxx.102  Bcast:xxx.xxx.xxx.255  Mask:255.255.255.0
          inet6 addr: fe80::xxxx:xxxx:xxxx:xxxx/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

(lan)
eth1      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:3A
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

ifb4eth0  Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:73
          inet6 addr: fe80::xx:xxx:xxxx:xxxx/64 Scope:Link
          UP BROADCAST RUNNING NOARP  MTU:1500  Metric:1

Why did you try to get IPv6 on the first place, if you do not want it on your devices?

1 Like

I'm not saying that I don't want it on my devices, just that I want it securely. With IPv4 and NAT, I can be sure to isolate devices from the WAN, but I'm not so sure about IPv6.

I edited my main post to mark that more clearly and shortened it a bit.

This is my starting point for understanding what I'm getting myself into with IPv6...

and

http://www.kloepfer.org/ipv6-homenet.html

If you pretend to use IPv6, forget about using NAT as a security measure... you need to have a properly configured firewall instead.

2 Likes

@eduperez Ok, so in IPv6 each device is directly accessible on the Internet but it's going through LEDE IPv6 firewall (no NATting), which need to be configured properly to at least block all ingress traffic.

But why in LEDE it is LAN (br-lan) that gets assigned the IPv6 and not WAN6 nor WAN ? Is it because it is using a tunnel and not a real IPv6 ? I'm not sure if this effectively bypass LEDE's IPv6 firewall...

Yes, you get IPv6 on the LAN interface and the tunnel interface.

1 Like

I did several tests tonight and to get what I wanted (a stealth IPv6 presence), I had to put a rule in the firewall to drop incoming ipv6-traffic from WAN to destination LAN.

Thank you for your help @eduperez.

The firewall is protecting your IPv4 clients, as it will do with IPv6. No, NAT is not protection, it is a hack.

You can't just drop everything you get from external that is IPv6 and still expect it to work.
For instance, you need to have ICMPv6 to pass (FORWARD) your firewall, or else your client will not know why packages doesn't reach the receiver. Some of those ICMPv6 messages tells your client that it has to send shorter packages, or other similar things.