On Sun, Feb 23, 2014 at 7:43 PM, Chuck Anderson <[email protected]> wrote: > On Sun, Feb 23, 2014 at 07:05:25PM -0500, Dave Taht wrote: >> - no bcp38 still (help?) > > Can you explain exactly what you are trying to do with the bcp38 stuff > and what makes it so complicated? I would think you just need to drop > all packets with source addresses that are not contained in locally > configured subnets?
Every time I think I have a day set aside to get it done it gets eaten by something else. Anyway basic proof of concept code for it is at: https://github.com/dtaht/bcp38 and a start of a script in ceropackages-3.10/net/bcp38. I'd started at it before we had source specific routing for ipv6 working, so it's looking like bcp38 for ipv6 is not needed. Yea. Still is a major problem on ipv4. The fw3 code has the ability to create/destroy ipsets, but not a good way to insert firewall rules based on them, and there needs to be a hook (somewhere) to allow (briefly) for dhcp derived ip addresses to be setup and tested for double-nat conditions (and at the very least, double-nat allowed for the first hop off of an interface) 1) What is a locally configured subnet? How do you know it's a locally configured subnet without deriving it from the entire network? You can't. BUT it is this scenario is problematic. Suppose I had a device on 172.30.41.2 (a dns server). Its router goes away. attempts to access it then result in this scenario: (true btw) 172.30.43.1 sends packets in the general direction of 172.30.41.2. But it's router (on 172.30.41.1) has failed. The route no longer exists, so the packet goes to the default gw of 172.30.42.1, get's natted and proceeds merrily on it's way to the next hop(s) outside the gateway, (so I'm sending a src addr of my external gw, to 172.30.41.2) At some point (after I've used up paid for bandwidth), something notices this... which eventually drops the packet, but the notification doesn't necessarily make it back. So what you want is to never double nat your own network when you don't have to. that if you send something to an address inside the bcp38 list, and it gets as far as the nat table, anything with a destination address in the bcp38 and rfc1918 lists should get a host unreachable message. You should drop anything in the bcp38 list. A simpler case is someone pinging the entire 10 net from within your network. your_network -> gw which nats it -> to the universe. (seen this) The exception problem is - is that many devices depend on double nat in order to work right these days. Example: cable modems depend on 192.168.100.1 to be their configuration interface... even if they provide a native ip. ipsets handle adding the dynamic exceptions like that straightforwardly, ipset add bcp38-ipv4 192.168.100.1/32 nomatch And in some hook, somewhere, in the dhcp client script, there could be something that takes the supplied netmask, and adds that network to the list. For example, I typically get a 10 net with a /24 from a netgear router get dhcp addr, it's got a netmask of 255.255.255.0 and a destintation of 10.0.1.1 and is assigned 10.0.1.8, setup ipset add bcp38-ipv4 10.0.1.0/24 nomatch Lastly, on inbound, packets from bcp38 and rfc1918 derived networks should be dropped silently, by basically the same ruleset. (I do prefer a chatty internal network) Like I said, proof of concept code exists, I wanted something that could be on by default, yet readily configurable, and survive firewall reloads as well as dhcp renews. Part of the rule set needs to go in the pre-nat table on inbound, another part before you hit nat out outbound (probly) > _______________________________________________ > Cerowrt-devel mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/cerowrt-devel -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
