RE: [gentoo-user] MAC whitelisting and UDP traffic.

[Laurence Perkins]

>>
>> From: Adam Carter adamcarter3@×××××.com<mailto:adamcarter3@×××××.com>
>> Sent: Tuesday, July 12, 2022 11:13 PM
>> To: Gentoo User gentoo-user@l.g.o<mailto:gentoo-user@l.g.o>
>> Subject: Re: [gentoo-user] MAC whitelisting and UDP traffic.
>>
>>
>> On Tue, Jul 12, 2022 at 7:35 AM Laurence Perkins lperkins@×××××××.net<mailto:lperkins@×××××××.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 <OUTSIDE> -j MASQUERADE
>> iptables -A FORWARD -i  <OUTSIDE> -o <INSIDE> -m state --state RELATED,ESTABLISHED -j ACCEPT
>>
>> And then the daemon adds a:
>> iptables -A FORWARD -i <INSIDE> -o <OUTSIDE> -m mac --mac-source <MAC 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