[RFC] IPv6 Stateless Firewall on gateways

[spolack]

Currently we are running the gateways as a stateful firewall with state syncronization across all members which does not scale well, is beyond any recommendations and leads to problems like race conditions, where here the state sync to other gateway is slower than the reply-traffic. Also i noticed that flows regular time out on gateways not involved in the data path, which syncronizes the timeout to all other gateways often breaking existing flows or at least interrupting the flow until TCP retry is done.

Proposal would be to drop conntrackd state syncronization and replace it with a standard filter allowing all response traffic by default based on ephemeral/dynamic destination port towards the mesh. A stateful firewall needs to be implemented on the core routers in order to futher restrict traffic coming from internet to the networks handled by the core router, as using a ephemeral port for services is not restricted.

While the port ranges are well standardized, not all operating systems respect those and we have to consider that people are running legacy software

• 49152-65535 (RFC6335, used from Windows Vista, FreeBSD 4.6)
• 32768-60999 (Linux kernel standard)
• 32768-65535 (Solaris OS and AIX OS)
• 1024-65535 (RFC6056)
• 1025-60000 (Windows earlier than Vista)

Based on that table i'd propose to allow TCP/UDP/SCTP Destination Port 1024-65535 to support all variants.

[PolynomialDivision]

That sounds good, but wouldn’t it still leave the system vulnerable to DDoS attacks by flooding the destination ports with enough traffic? So, why not eliminate the firewall at the gateways entirely and rely solely on the firewalls at the core routers? I can see the value in blocking well-defined ports, but I’d like to better understand the full benefits of this approach.

[PolynomialDivision]

I can see the reasoning for blocking traffic at the gateways, especially since scraping tools could generate significant load on the network. Are there more benefits to this approach, or is this traffic truly significant enough to warrant such measures?

[spolack]

I consider that proposed filter to be the bare minimum, at the gateways, as it IMO would be irresponsible to expose hundereds or potentially unpatched devices to the internet.

DoS is out of scope, you cant fix full pipes with firewall filters.

[spolack]

I noticed a possible problem with going 1024-65535. Completely forgot about common listen sockets in the range above 1024. (8080 etc)

But i guess we could also live with a tighter filter like 32768-65535. Older systems likely dont rely on IPv6.

Ubiquity AirOS for example listens on following ports. Other devices to be confirmed..:

spolack@fedora:~$ nmap sama-sued-5ghz.ff -sV -p1-65535
#Starting Nmap 7.92 ( https://nmap.org ) at 2024-12-11 01:17 CET
Stats: 0:00:00 elapsed; 0 hosts completed (0 up), 1 undergoing Ping Scan
Ping Scan Timing: About 100.00% done; ETC: 01:17 (0:00:00 remaining)
Nmap scan report for sama-sued-5ghz.ff (10.31.81.22)
Host is up (0.013s latency).
Not shown: 65531 closed tcp ports (conn-refused)
PORT      STATE SERVICE    VERSION
22/tcp    open  ssh        Dropbear sshd (protocol 2.0)
80/tcp    open  http       lighttpd 1.4.54
443/tcp   open  ssl/http   lighttpd 1.4.54
10001/tcp open  tcpwrapped
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 20.31 seconds
spolack@fedora:~$ nmap sama-sued-60ghz.ff -sV -p1-65535
Starting Nmap 7.92 ( https://nmap.org ) at 2024-12-11 01:18 CET
Nmap scan report for sama-sued-60ghz.ff (10.31.81.26)
Host is up (0.011s latency).
Not shown: 65530 closed tcp ports (conn-refused)
PORT      STATE SERVICE    VERSION
22/tcp    open  ssh        Dropbear sshd 2022.83 (protocol 2.0)
80/tcp    open  http
161/tcp   open  snmp?
443/tcp   open  ssl/https
10001/tcp open  tcpwrapped

[PolynomialDivision]

I noticed a possible problem with going 1024-65535. Completely forgot about common listen sockets in the range above 1024. (8080 etc)

Are you referring to a gateway or core-router firewall? Why would we have a service exposing 8080 to the internet? I understand the reasoning regarding unpatched devices, and I'm fine with this suggestion. It should also be straightforward to add an OpenWrt firewall configuration and remove contractd again.

[PolynomialDivision]

With "I'm fine," I mean I am excited to go for it to achieve a much more stable internet connection. :D

[spolack]

As this is a commonly used port for https i think there is a high chance we'll find devices using that port.

Are you referring to a gateway or core-router firewall.

Gateway. I'm, assuming that not all devices are hidden behind a corerouter firewall, and would like to reduce the chance of unintentional exposing devices to internet due to Disabling firewall on the core router for testing.