Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
No IP from dhcpd; kernel 6.6.30, nftables and dnsmasq
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
sephora
n00b
n00b


Joined: 28 Nov 2022
Posts: 40

PostPosted: Sat Jun 22, 2024 1:05 pm    Post subject: No IP from dhcpd; kernel 6.6.30, nftables and dnsmasq Reply with quote

Hi everyone,

if got a strange problem which is puzzling me for a while now.
Ever since I switched from kernel on my router from 6.6.21 to 6.6.30 (gentoo-sources) I can't get an IP-address by dhcp for any device in my LAN; Wifi works still fine thought.

My router is running hostapd, dnsmasq and nftables.
If I switch back to 6.6.21 everything works fine and I get my IP.
And while running 6.6.30 I can only get an IP via Wifi. For LAN I have to switch of nftables.
Which seems very odd since I did not change anything considering the firewall script.

Here's my nftables script:
Code:
#!/sbin/nft -f

define dev_wan = enpWAN
define dev_lan = br0
define dev_wifi = wlpWIFI

define net_lan = 192.168.a.0/24
define net_wifi = 192.168.b.0/24

define port_ext_ssh = xxxx
define port_ext_vpn = yyyy

# Clean out the current ruleset
flush ruleset

table firewall {

   set blacklist {
      type ipv4_addr
   }

   set tcp_open_ports {
      type inet_service

      elements = { $port_ext_ssh }
   }

   set udp_open_ports {
      type inet_service

      elements = { $port_ext_vpn }
   }

   chain inbound_world {
      # allow open tcp ports
      tcp dport @tcp_open_ports accept

      # allow open udp ports
      udp dport @udp_open_ports accept

      # drop everything else
      iifname $dev_wan drop comment "drop wan"

      reject
   }

   chain inbound_private {
      # accepting ping (icmp-echo-request) for diagnostic purposes.
      icmp type echo-request limit rate 5/second accept

      # allow DHCP, DNS and SSH from the private network
      ip protocol . th dport vmap {
         tcp . 22            : accept, #ssh
         udp . 53            : accept, #dns
         tcp . 53            : accept, #dns
         udp . 67            : accept, #dhcp
         udp . $port_ext_vpn : accept, #vpn
         udp . 9987          : accept, #teamspeak
         tcp . 30033         : accept, #teamspeak
         tcp . 143           : accept, #imap
         tcp . 873           : accept  #rsync
       }
   }

   chain incoming {
      type filter hook input priority 0; policy drop;

      # established/related connections
      ct state vmap {
         established : accept,
         related     : accept,
         invalid     : drop
      }

      # bad tcp -> avoid network scanning:
      tcp flags & (fin|syn) == (fin|syn) drop
      tcp flags & (syn|rst) == (syn|rst) drop
      tcp flags & (fin|syn|rst|psh|ack|urg) < (fin) drop
      tcp flags & (fin|syn|rst|psh|ack|urg) == (fin|psh|urg) drop

      # no ping floods:
      iifname $dev_wan ip protocol icmp counter drop
          ip protocol icmp limit rate 10/second accept
          ip protocol icmp drop

      # drop connections from blacklisted addresses
      ip saddr @blacklist drop

      # loopback
      iifname != lo ip saddr 127.0.0.1/8 counter drop comment "drop connections to loopback not coming from loopback"

      # avoid brute force on ssh:
      tcp dport ssh limit rate 15/minute accept

      # accept input from loopback and internal interfaces
      iifname vmap {
         lo       : accept,
         $dev_wan : jump inbound_world,
         $dev_lan : jump inbound_private,
         $dev_wifi : jump inbound_private
      }

      reject
   }

   chain forwarding {
      type filter hook forward priority 0; policy drop;

      # Allow traffic from established and related packets, drop invalid
      ct state vmap {
         established : accept,
         related     : accept,
         invalid     : drop
      }

      # connections from the internal net to the internet or to other
      # internal nets are allowed
        iifname { lo, $dev_lan, $dev_wifi }  accept

      # the rest is dropped by the above policy
   }

   chain outgoing {
      type filter hook output priority 0
   }

   chain prerouting {
      type nat hook prerouting priority 0

      tcp dport $port_ext_ssh redirect to :22
   }

   chain postrouting {
       type nat hook postrouting priority 100; policy accept;

      # masquerade private IP addresses
      ip saddr { $net_lan, $net_wifi } oifname $dev_wan masquerade
   }
}


Maybe someone has an idea what's going on or can give me a hint? :)


Last edited by sephora on Sun Jun 23, 2024 1:45 pm; edited 1 time in total
Back to top
View user's profile Send private message
RumpletonBongworth
n00b
n00b


Joined: 17 Jun 2024
Posts: 59

PostPosted: Sat Jun 22, 2024 2:05 pm    Post subject: Reply with quote

If the kernel version be the only variable in all of this then it is a peculiar matter indeed. I think that you might be better off directing the matter to the netfilter-user mailing list or even filing it as a bug to elicit some input from the Netfilter developers. I wouldn't expect anything to have meaningfully changed on the kernel side. Still, regressions can - and often do - occur, even within the scope of the long term branches.

Though unrelated to your issue, I have some observations to make concerning your ruleset.

The conntrack subsystem implements a generic check for invalid TCP flag combinations before conducting even more rigorous checks at the behest of its state machine. Therefore, you do not need to check for bad TCP flags. Offending packets will simply be classified with a ctstate of "invalid". The behaviour of the state machine can be hardened further with:

Code:

# Require new TCP flows to begin with SYN. Useful in cases where there is no
# need to pick up existing connections e.g. for firewall failover scenarios.

sysctl -w net.netfilter.nf_conntrack_tcp_loose=0


Other than for the lo interface, packets arriving from 127.0.0.0/8 will already be considered as martian packets unless you enable the "net.ipv4.conf.all.route_localnet" or the similarly-named option for the applicable interface. Assuming that you don't, your "not coming from loopback" rule isn't required.
Back to top
View user's profile Send private message
sephora
n00b
n00b


Joined: 28 Nov 2022
Posts: 40

PostPosted: Sun Jun 23, 2024 1:44 pm    Post subject: Reply with quote

Thank you for responding!

And thank very much you for your input. I going to improve my firewall based on your comment. :)

As for the dhcp issue, I did try the kernel from the testing branch, 6.9.6. But the result is the same.
And I also rebuild my kernel, playing with the settings in .config that are new in 6.6.30. But no luck so far.

I'm going check with tcpdump. Maybe I can see something.
Either way I probably going to post on the netfilter-user list. Tanks for the hint!

I wish I had more time debugging this. But my schedule is fully packed right now. :(
Back to top
View user's profile Send private message
RumpletonBongworth
n00b
n00b


Joined: 17 Jun 2024
Posts: 59

PostPosted: Sun Jun 23, 2024 5:05 pm    Post subject: Reply with quote

sephora wrote:
I'm going check with tcpdump. Maybe I can see something.

You might also benefit from tracing the flow of relevant packets through your ruleset. For example:

Code:

table raw {
   chain PREROUTING {
      # Packets arriving
      type filter hook prerouting priority raw; policy accept;
      iifname != "lo" meta l4proto udp meta nftrace set 1
   }
   chain OUTPUT {
      # Packets generated by this host
      type filter hook output priority raw; policy accept;
      oifname != "lo" meta l4proto udp meta nftrace set 1
   }
}

Simply run "nft monitor trace" and you'll be able to follow the packets marked for tracing through to their eventual conclusion. Of course, this is just an example that traces UDP packets. You may apply whatever filtering criteria seems relevant to the problem, thereby avoiding being potentially overwhelmed by noise while monitoring.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum