RE: [gentoo-user] MAC whitelisting and UDP traffic.
>> >> From: Adam Carter adamcart...@gmail.com<mailto:adamcart...@gmail.com> >> Sent: Tuesday, July 12, 2022 11:13 PM >> To: Gentoo User >> gentoo-user@lists.gentoo.org<mailto:gentoo-user@lists.gentoo.org> >> Subject: Re: [gentoo-user] MAC whitelisting and UDP traffic. >> >> >> On Tue, Jul 12, 2022 at 7:35 AM Laurence Perkins >> lperk...@openeye.net<mailto:lperk...@openeye.net> wrote: >> Ok, I asked a while ago about whitelisting MAC ranges for firewall rules, >> and just so you know, adding 16 million potential MAC addresses to the >> firewall… Doesn’t work well… No matter how you do it. So I had to write a >> daemon to monitor which ones were local and add just those. Whatever. >> >> That brings me to the next problem. The routing and NAT work just fine if >> I’m letting everything through. But if I’m dropping connections that don’t >> come from authorized devices then UDP only works in the outbound direction… >> TCP is fine. >> >> For reference, the rules consist of: >> >> iptables -t nat -I POSTROUTING -o -j MASQUERADE >> iptables -A FORWARD -i -o -m state --state >> RELATED,ESTABLISHED -j ACCEPT >> >> And then the daemon adds a: >> iptables -A FORWARD -i -o -m mac --mac-source > ADDRESS> -j ACCEPT >> >> for each authorized device. >> >> TCP works perfectly. >> UDP based protocols send out just fine, but any replies get blocked if the >> FORWARD chain’s default policy is DROP. >> >> Now… Everything I’m reading says that it’s supposed to be able to associate >> UDP replies based on port number, which indeed it must be doing in order for >> them to get translated correctly and directed to the correct device inside >> the NAT when the default policy is ACCEPT. >> >> So why is that rule to accept related packets not triggering for them? > > I also would have expected the UDP replies to be permitted via -state > RELATED,ESTABLISHED. > > Do they at least get into the state table; > grep udp /proc/net/nf_conntrack > Well, they had been all getting in that list for the outbound packets, but then never noting that replies had come... This morning when I went to pull a few lines for this reply, they're there and marked as ASSURED. And yet, of the four devices attached to the inside for testing purposes, only one of them has established its OpenVPN connection. So I'm going to set up some more detailed tests and some additional hardware arrangements and see if I can get more specific about what does and does not connect properly. LMP
Re: [gentoo-user] MAC whitelisting and UDP traffic.
On Wed, Jul 13, 2022 at 4:13 PM Adam Carter wrote: > > On Tue, Jul 12, 2022 at 7:35 AM Laurence Perkins > wrote: > >> Ok, I asked a while ago about whitelisting MAC ranges for firewall rules, >> and just so you know, adding 16 million potential MAC addresses >> > > Is your INSIDE interface on a 8 bit subnet (255.0.0.0) network? 20 years ago I heard of a /16 network and the arp traffic alone was ~200kps...
Re: [gentoo-user] MAC whitelisting and UDP traffic.
On Tue, Jul 12, 2022 at 7:35 AM Laurence Perkins wrote: > Ok, I asked a while ago about whitelisting MAC ranges for firewall rules, > and just so you know, adding 16 million potential MAC addresses to the > firewall… Doesn’t work well… No matter how you do it. So I had to write > a daemon to monitor which ones were local and add just those. Whatever. > > > > That brings me to the next problem. The routing and NAT work just fine if > I’m letting everything through. But if I’m dropping connections that don’t > come from authorized devices then UDP only works in the outbound > direction… TCP is fine. > > > > For reference, the rules consist of: > > > > iptables -t nat -I POSTROUTING -o -j MASQUERADE > > iptables -A FORWARD -i -o -m state --state > RELATED,ESTABLISHED -j ACCEPT > > > > And then the daemon adds a: > > iptables -A FORWARD -i -o -m mac --mac-source ADDRESS> -j ACCEPT > > > > for each authorized device. > > > > TCP works perfectly. > > UDP based protocols send out just fine, but any replies get blocked if the > FORWARD chain’s default policy is DROP. > > > > Now… Everything I’m reading says that it’s supposed to be able to > associate UDP replies based on port number, which indeed it must be doing > in order for them to get translated correctly and directed to the correct > device inside the NAT when the default policy is ACCEPT. > > > > So why is that rule to accept related packets not triggering for them? > I also would have expected the UDP replies to be permitted via -state RELATED,ESTABLISHED. Do they at least get into the state table; grep udp /proc/net/nf_conntrack
[gentoo-user] MAC whitelisting and UDP traffic.
Ok, I asked a while ago about whitelisting MAC ranges for firewall rules, and just so you know, adding 16 million potential MAC addresses to the firewall... Doesn't work well... No matter how you do it. So I had to write a daemon to monitor which ones were local and add just those. Whatever. That brings me to the next problem. The routing and NAT work just fine if I'm letting everything through. But if I'm dropping connections that don't come from authorized devices then UDP only works in the outbound direction... TCP is fine. For reference, the rules consist of: iptables -t nat -I POSTROUTING -o -j MASQUERADE iptables -A FORWARD -i -o -m state --state RELATED,ESTABLISHED -j ACCEPT And then the daemon adds a: iptables -A FORWARD -i -o -m mac --mac-source -j ACCEPT for each authorized device. TCP works perfectly. UDP based protocols send out just fine, but any replies get blocked if the FORWARD chain's default policy is DROP. Now... Everything I'm reading says that it's supposed to be able to associate UDP replies based on port number, which indeed it must be doing in order for them to get translated correctly and directed to the correct device inside the NAT when the default policy is ACCEPT. So why is that rule to accept related packets not triggering for them? And is there a standard way to do this? Because everything I can dig up on Google is examples just of routing with no NAT involved and nobody reporting this problem anywhere. I'll keep playing with it, but at this point I'm just throwing random stuff against the wall, so any hints would be appreciated. LMP
