I’d like the ability for the Peplink Balance firmware to generate ICMP unreachable replies. The use I have in mind is specifically to prevent packets for not-already-routed RFC1918 addresses from leaking out the WAN ports, but I can envision some other scenarios where this would be handy.
On a regular Linux box, I would write something like:
iptables -A FORWARD -o wan -d 10.0.0.0/8 -j REJECT --reject-with icmp-net-unreachable
iptables -A FORWARD -o wan -d 172.16.0.0/12 -j REJECT --reject-with icmp-net-unreachable
iptables -A FORWARD -o wan -d 192.168.0.0/16 -j REJECT --reject-with icmp-net-unreachable
Or:
ip route add unreachable 10.0.0.0/8 metric 250
ip route add unreachable 172.16.0.0/12 metric 250
ip route add unreachable 192.168.0.0/16 metric 250
I like the second option a little less – network unreachable seems more appropriate than host unreachable here – but it’s safer in the case where one of the WAN connections is itself in RFC1918 space.
The Balance firmware lets me add static routes, but only unicast routes, not unreachable routes. It also lets me configure “deny” firewall rules, but these seem to simply discard traffic, while I want to notify the sender that the packet could not be forwarded.
Hi willglynn,
Currently we are taking a more conservative approach that no ICMP is replied for rejected/denied traffic. So far our customers do not have much comment on it. I’d like hear from you more about the importance of sending ICMP reply for rejected traffic.
Regards,
Michael
Sure. I’m usually on board with firewalls silently dropping packets that came in from the Internet, but for internal clients, I’d much rather notify them of rejection instead of making connections time out – it’s a better user experience and it makes troubleshooting faster. I generally do this with -j REJECT --reject-with icmp-admin-prohibited. It’d be nice for the Peplink firewall to support this too, and that would let me synthesize a solution (especially given a reject-with dropdown), but it’s not quite what I’m asking.
My request here has more to do with using a Peplink Balance at the public/private border. If an internal client is trying to send a packet to a private address that doesn’t match any static routes, I would rather bounce the packet back as network unreachable from the border instead of a) forwarding it upstream or b) dropping it silently. Since Peplink Balance devices are generally deployed between an internal network and the Internet, it’s reasonable to expect that there is a default route pointed its way, so it will eventually receive such packets.
Additionally, I think that adding high-metric unreachable routes for private address spaces might even be a sensible default setting. They won’t conflict with any customer-added static routes, IPsec VPNs, or private-address-space ISPs, but they will stop packets to unroutable private IPs from reaching the outside. From RFC1918 section 5:
It is strongly recommended that routers which connect enterprises to
external networks are set up with appropriate packet and routing
filters at both ends of the link in order to prevent packet and
routing information leakage.
The NAT rules already in place very likely stop packets from the outside directed at internal addresses, though come to think of it, that’s not something I’ve tested. Regardless, there’s no such protection going out, except by a) adding custom firewall rules to discard traffic or b) static routing all RFC1918 space to another router that generates unreachables.