From my AT&T fiber gateway, I’m seeing occasional messages in its firewall logs where it’s dropping leaked rfc1918 traffic from my subnets. As an example:
It seems that the final FIN or RST after a connection tears down is not being natted, since the connection is no longer being tracked, but then it leaks out my WAN interface. Not a huge deal, but I’d like to block it anyway. What are my options here?
While the default firewall drops invalid on input if something goes awry during the TCP connection, invalid packets can still escape. Not sure above will catch it, but it if it does that be a clue.
Well, it is a decades long standing bug in the Linux kernel.
Probably the maintainers argue it is not a bug but a fact of life, or they want to optimize for performance rather than for such things.
Fact of the matter is that tracking entries for closed connections are deleted too soon.
After a FIN has received and a reply FIN has been sent (or an RST when you live in Redmond), the tracking entry still has to remain for a “2MSL” time to conform to the TCP RFC. This is the time you see connections spend in TIME_WAIT state in netstat.
Linux does not do that.
The only solution I could ever find was to use bridge filter to drop packets escaping via WAN with any unexpected source address, but that is only possible for WANs using L2 interfaces (“IP over Ethernet” ones), not for PPP-based ones as those cannot be bridged.
So what would that look like? A little more background here, I have an rb5009 in a “router on a stick” config, my public internet is on a vlan interface, and that vlan interface is attached to the bridge, as is my sfp interface. No PPP involved. I see in bridge filtering you can select a bridge interface, but nothing more specific than that.
So one other thought, my fiber gateway is plugged into a crs309 as an untagged port for the public internet vlan, and my router is plugged into that same switch as a trunked port. Could I do firewall filtering on the crs309 using hardware offload? I’ve not really looked into what is possible there, I understand the cpu is pretty constrained but in some cases some things can be offloaded.
So for now I am able to come up with switch port rules on the crs309 that block rfc1918 traffic on the public internet vlan. That at least ticks the box, but I can’t help but think there is a more elegant solution.
Well.. more elegant… Using switch chip rules for the purpose means not adding any load to the CPU, so the only better solution would be to apply the switch chip rules directly on the 5009 rather than on the 309. But I don’t have one handy, so you have to check on your own whether the switch chip used in the 5009 can match on vlan ID and source IP address simultaneously. And you would have to apply the rules on the CPU port since they are used on ingress, so be careful and test with a single source IP address and a VLAN ID that is not essential, otherwise you can easily lock yourself out. Or find a USB-to-serial converter and configure serial console before adding any switch chip rules. Removing an interface from a bridge and using it as a backup management interface is not enough, as the traffic of all ports always flows through the switch chip.
For the unlikely case that you wanted to use bridge filter rules - the last time I tried that with late 6.48 or early 6.49, it was not possible to match on VLAN ID and IP address simultaneously, but maybe 7.x has improved in that regard. There also used to be an issue with endianness of the ethertype (mac-protocol) value on some architectures. So it would require quite a lot of testing if you wanted to go that way, but the switch chip rules on the 5009 seem the best by far to me. The workaround to matching on IP address and VLAN ID at the same time is to use an auxiliary bridge, but I would not call that “elegant”.
I had the exact same thought, and I tried applying the same basic rules that work on the crs309 to the switch chip on the rb5009 and they seemed to have no effect, whether using the cpu interface or the sfp interface. I might have been doing something else wrong though, not sure.
Actually, that reminds me that whilst in ROS 6, the USB-to-serial converter was the only way and you had to configure it in advance, in ROS 7, I could dig my way back to a CRS310 using a USB-to-Ethernet converter (it just requires that the acccess using mac-telnet or mac-winbox is not restricted). I wouldn’t have minded resetting it back to factory defaults back then but I was too lazy to remove it from the rack to get access to the label with the default password - only later have I found that another sticker with the password was available also on the leaflet in the cardboard box So on a 5009, this should work as well.
As for the switch chip rules, I hazily remember (from hAP ac², so a different switch chip), that in order that the rule would match, mac-protocol had to be specified as ip, not as vlan, although vlan-id was specified. So you have to be slightly creative to find the correct setting.
sounds like there is a bug in the rb5009 where the switch1-cpu port filtering isn’t working right now. hopefully that gets fixed, but for now, I guess I can live with filtering on my crs309 go back to not thinking about leakage.
