RFC1918 traffic to wan

Installing and Using OpenWrt
1

To my surprise I found that OpenWrt in its default configuration does not block traffic from address ranges defined in RFC1918 from being forwarded to wan. I know that there isn’t an RFC that says “MUST not be forwarded”, but nevertheless the RFC leaves the impression that leaking RFC1918 traffic is a misconfiguration.

PfSense has a rule that prevents outgoing traffic on the WAN interface by default.

So I’ve added the rule using /etc/firewall.user:

#!/bin/sh
. /lib/functions/network.sh

network_get_device wan_dev wan

nft add chain inet fw4 rfc1918_wan_guard '{ type filter hook postrouting priority raw; policy accept; }'
nft add rule inet fw4 rfc1918_wan_guard oifname $wan_dev ip daddr '{ 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 }' \
	counter drop comment \"Prevent rfc1918 traffic to wan\"

Is there a simpler way to achieve this?

2

Set black hole routes for rfc1918 and other bogus networks.

There is also the package bcp38 which does it

3 Likes
3

Try this .... Bogons/cgnat are we able to remove it? - #34 by brada4

Linux netfilter puts NAT and all other packet translations under big forwarding hat. masquerade checkbox does the fixup part. Your counter shall be zero at all times.

You could also explore nftables "fib" to emulate martian/rpf sysctl.

2 Likes
4

@brada4: The counter isn’t zero (I’ve checked). NAT only replaces the source address, it doesn’t change the destination address. So yes, the packet on the wan interface comes from the router’s wan (public) address, but it still goes to e.g. 192.168.180.1.

5

Because you have a default route. Add black hole routes.

6

The hook is before NAT, set priority to +1000 and all packets will be NAT-ed.

7

Show the FreeBSD rule in question, ill try to work out equivalent. If you want to look at raw wire packets you need ingress/egress hook attached to the interface.

8

Yes, “black hole” routes are an alternative that I had considered. However, I found them less intuitive than having an explicit filter.

9

At least that has same semantics as FreeBSD ....

10

To be totally correct, RFC1918 - Title "Address Allocation for Private Internets".
Public routers (ie those routing public ip addresses) would not be expected to forward to private addresses, but even if they did, there would be no valid or unique destination.

This is true.

I don't think that it does.

Since the early days of IP networking, the likes of multi site corporate networks have used leased lines etc. with routers "routing" private addresses from one site to another, not a public address to be found. Even today this is very common, maybe using VPN instead of leased lines, but this is effectively the same thing.

There is no need for a default firewall block. Remember the default config for OpenWrt is with masquerade aka NAT enabled, so "leaking" is already effectively blocked. Without NAT and a WAN connection to the Internet, your router will not get you anywhere.

Yes, do nothing.

2 Likes
11

Why so?

Just because you have a default route. That's the main issue.

Internet was build with the idea of interconnecting networks. And just by 1994? there was rfc1918 and because of that bcp38 with states a router should black hole. Back in the day it would have been far to heavy to filter that traffic. Because black hole these routes is pretty cheap.

So to safe compute I would still recommend black hole routes or null routes on Cisco speak.

12

That is true, but those packets are unlikely to get past the next router upstream.
But if you are forcing a destination address (eg by pinging 192.168.180.1) when that subnet is not in your private lan, then it is a pointless exercise.
To block your own mistake, it could be regarded as good practice to add your rules....

13

Take a look at the bcp38 package or luci-app-bcp38 package if using LuCI (WebUI for OpenWrt)

14

This was already mentioned in the 2nd post...

15

Sorry, missed that.

16

Such default would break IPv4 traffic for various ISPs (sadly).

17

Wait, there's something fishy here.

Presumably the addresses OP is talking about are on-link for the LAN side of the router. So, why would a default route matter? The IP stack should consult the interface configuration, see that the address fits into the requisite netmask, and from there: if ARP can locate the host, great, send it, if not, Host Unreachable. That's all before routing proper even comes into play? Or?

18

Rfc1918 is more then 192.168.0.0/24

Arp has nothing to do here.

If a network is not present on an interface, and you have a default route, then this network will be reached over that default route.
And if these are private addresses then you send them via wan. Nothing unusual. That's why there is bcp38 which describes how to deal with that.

2 Likes
19

@mnlipp
Yes, many ISPs (particularly mobile 4g/5g cellular network providers) use RFC1918 addresses for the first part (ie closest to the customer) of their upstream network, before routing into their CGNAT address space.
Any block in the local router will make the upstream ipv4 connection fail.

1 Like
20

Just for the record.
OpenWrt can not assume any default on this case.

The user has to ensure it.
But any sane ISP will filter these addresses anyway or black hole them in the real world this is not an issue at all.
And if someone what's to cosplay as an ISP and did not get the memo about MANRS then they should stop their Wannabe business asap.

2 Likes