| View previous topic :: View next topic |
| Author |
Message |
sephora
n00b
Joined: 28 Nov 2022
Posts: 40
|
 Posted: Sat Jun 22, 2024 1:05 pm Post subject: No IP from dhcpd; kernel 6.6.30, nftables and dnsmasq |
 |
|
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 |
|
 |
RumpletonBongworth
Tux's lil' helper
Joined: 17 Jun 2024
Posts: 77
|
| Posted: Sat Jun 22, 2024 2:05 pm Post subject: |
|
|
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 |
|
|
sephora
n00b
Joined: 28 Nov 2022
Posts: 40
|
| Posted: Sun Jun 23, 2024 1:44 pm Post subject: |
|
|
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 |
|
|
RumpletonBongworth
Tux's lil' helper
Joined: 17 Jun 2024
Posts: 77
|
| Posted: Sun Jun 23, 2024 5:05 pm Post subject: |
|
|
| 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 |
|
|
|
|
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
|
|
Networking & Security
