You are not logged in.
I configured hostapd and systemd-networkd years ago. It worked flawlessly until my recent system upgrade (I do this weekly). Wi-Fi works, all devices connect successfully. Local network over Wi-Fi works fine. I have internet access on the host, but no internet on the connected Wi-Fi devices.
I tried some things from this topic, but no luck.
[Match]
Name=enp7s0
[Network]
DHCP=ipv4
# IPv4Forwarding=yes # <-- tried, no effect[Match]
Name=wlo1
[Network]
Address=192.168.12.1/24
DHCPServer=true
IPMasquerade=true
IPForward=true
# IPMasquerade=ipv4 # <-- tried, no effect
# IPv4Forwarding=yes # <-- tried, no effect
[DHCPServer]
PoolOffset=10
PoolSize=10
EmitDNS=yes
DNS=9.9.9.9Offline
* IPForward= setting in .network file is deprecated and replaced with
IPv4Forwarding= and IPv6Forwarding= settings. These new settings are
supported both in .network file and networkd.conf. If specified in a
.network file, they control corresponding per-link settings. If
specified in networkd.conf, they control corresponding global
settings. Note, previously IPv6SendRA= and IPMasquerade= implied
IPForward=, but now they imply the new per-link settings. One of the
simplest ways to migrate configurations, that worked as a router with
the previous version, is enabling both IPv4Forwarding= and
IPv6Forwarding= in networkd.conf. See systemd.network(5) and
networkd.conf(5) for more details.
Edit:
You'll probably need to set this globally to work or on each interface separately.
Last edited by just4arch (2024-07-01 17:27:39)
Offline
I wouldn't want to do this globally. I have other eth interfaces that should not connect to the internet.
Offline
So what happens if you set IPv4Forwarding=yes in both, wifi and lan .network files?
Offline
Nothing. No any effect. (Yes, I restarted systemd-networkd)
Offline
Sanity check
grep . /proc/sys/net/ipv4/conf/*/forwardingHave you tried enabling it globally in networkd.conf and disabling it for the interfaces you don't want it? (just as a test)
Offline
Okay, try it now. IPv4Forwarding=
wlo no, eth yes, glob no
wlo yes, eth no, glob no
wlo yes, eth yes, glob no
wlo no, eth no, glob no
wlo no, eth no, glob yes
No effect in each case.
grep . /proc/sys/net/ipv4/conf/*/forwardingAlways 1 in each case
/proc/sys/net/ipv4/conf/enp7s0/forwarding:1
/proc/sys/net/ipv4/conf/wlo1/forwarding:1Offline
wlo no, eth yes, glob no
wlo yes, eth no, glob no
wlo yes, eth yes, glob no
wlo no, eth no, glob no
wlo no, eth no, glob yes
Not exactly what I had in mind, more like:
global yes
wlo1 yes/default
enp7s0 yes/default
IFs you don't want to forward no
Always 1 in each case
So at least the kernel seems to have the correct settings.
Try starting networkd with "Environment=SYSTEMD_LOG_LEVEL=debug" and post the (sanitized) log.
Just to be clear, did this start with the systemd update or was something else updated when it started to fail?
Networkd might be a red herring, so back to basics.
Wifi clients can access the router and it's just the forwarding that fails?
Routes are still in place? (router and clients)
No firewall shenanigans?
DNS working on wifi?
What's the error when you ping / trace in either direction? (wifi <=> router, wifi => inet)
Does forwarding work between the "other" interfaces?
If you use wireshark / tcpdump on enp7s0 and wlo1 do you see packets being forwarded at all between the interfaces?
Offline
Sorry, I meant "no" as in "not specified", the setting has been removed from the file. systemd has been updated to the version with the IPForward settings changes.
Wifi clients can access the router and it's just the forwarding that fails?
Yes.
Routes are still in place? (router and clients)
How can I test it?
DNS working on wifi?
I don't think so. Ping 8.8.8.8 or 9.9.9.9 failed.
ping / trace in either direction
wifi <=> router: successful ping any address on the local network in any direction. wifi => inet: ping any ip address fails, ping any domain name cannot be resolved.
Does forwarding work between the "other" interfaces?
I think so. All local network services can be accessed from any device.
If you use wireshark
How can I filter it?
The real reason is docker.
Forwarding works correctly right after boot until docker starts. It creates virtual interfaces and some iptables rules. Forwarding just stop working. And I have no idea how to fix it.
docker run -d --restart unless-stopped --env-file ### --add-host=host.docker.internal:host-gateway -p 51300:51300 ###9: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:c1:b5:58:e6 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
inet6 fe80::42:c1ff:feb5:58e6/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
11: veth62a251c@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
link/ether 7a:2f:f5:81:e7:da brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet6 fe80::782f:f5ff:fe81:e7da/64 scope link proto kernel_ll
valid_lft forever preferred_lft foreversudo iptables -S
-P INPUT ACCEPT
-P FORWARD DROP
-P OUTPUT ACCEPT
-N DOCKER
-N DOCKER-ISOLATION-STAGE-1
-N DOCKER-ISOLATION-STAGE-2
-N DOCKER-USER
-A INPUT -i enp7s0 -p tcp -m tcp --dport 8123 -j DROP
-A FORWARD -j DOCKER-USER
-A FORWARD -j DOCKER-ISOLATION-STAGE-1
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A DOCKER -d 172.17.0.2/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 51300 -j ACCEPT
-A DOCKER-ISOLATION-STAGE-1 -i docker0 ! -o docker0 -j DOCKER-ISOLATION-STAGE-2
-A DOCKER-ISOLATION-STAGE-1 -j RETURN
-A DOCKER-ISOLATION-STAGE-2 -o docker0 -j DROP
-A DOCKER-ISOLATION-STAGE-2 -j RETURN
-A DOCKER-USER -j RETURNOffline
sudo iptables -P FORWARD ACCEPTFixed the problem. But I have 2 questions:
1. Is it secure for my setup?
2. How can I force docker not to add this rule?
Offline
I hadn't updated anything on my home server for a couple of weeks and just did a full 'pacman -Syu' today to catch up. Now I'm having a similar problem to what's described in this thread.
Potentially useful background about my LAN and internet connection:
My server has one network port connected to the modem, and one of the other ports on the modem's mini-switch goes over to my 8-port switch. There's a VLAN setup on the modem so that only appropriately-tagged traffic from the server's port can go through to the WAN port and talk to my ISP, and untagged traffic is part of the LAN. The main interface is named 'enp5s0' and the VLAN interface is named 'internetz' (lists as 'internetz@enp5s0' when running commands like `ip a l`). This setup was working for several years on my old server. I switched to systemd-networkd when I did a clean OS install on the new hardware, and it's been working fine for the 5-6 months prior to today's update.
I have 'IPMasquerade=ipv4' and 'IPv6SendRA=yes' in the networkd config file for enp5s0, so both flavours of forwarding should be on by default anyway, but I have updated explicit 'IPv4Forwarding=yes' and 'IPv6Forwarding=yes' and they've made no difference. I can that only enp5s0 has forwarding enabled when I 'grep . /proc/sys/net/ipv?/conf/*/forwarding'.
When I run `tcpdump -i any host 4.2.2.1` on the server and then ping 4.2.2.1 from my desktop, I see echo requests from $desktop_internal to 4.2.2.1 as an inbound on the LAN interface, but no matching echo request from $server_public to 4.2.2.1 outound on the internet connection interface. The server can ping things just fine.
Eventually I remembered I can use 'ssh -D' to jury-rig a SOCKS-proxy and get my browser working, and that got me as far as this thread. I have just now tried disabling docker and rebooting, and now a ping from my desktop shows
17:39:44.227690 enp5s0 In IP $desktop_private > 4.2.2.1: ICMP echo request, id 1, seq 416, length 40
17:39:44.227719 internetz Out IP $server_public > 4.2.2.1: ICMP echo request, id 1, seq 416, length 40
17:39:44.227722 enp5s0 Out IP $server_public > 4.2.2.1: ICMP echo request, id 1, seq 416, length 40
17:39:44.329611 enp5s0 In IP 4.2.2.1 > $server_public: ICMP echo reply, id 1, seq 416, length 40
17:39:44.329611 internetz In IP 4.2.2.1 > $server_public: ICMP echo reply, id 1, seq 416, length 40but the final step that should look like 'enp5s0 Out IP 4.2.2.1 > $desktop_private' is still not happening. It seems that the NAT setup isn't fixing the destination on the replies and I'm not sure where to look next.
I'll leave docker disabled for now and fiddle with that later when I have normal NAT and forwarding back. I'm sure it's going to be extra-horrible because I was silly enough to install 'iptables-nft' to let docker keep running iptables commands instead of digging into how to configure docker to just use nftables directly.
Offline
When I read back over my post to double-check I hadn't mucked up any details I realised that not having forwarding enabled on internetz is probably why traffic coming back in wasn't forwarding to the desktop. I just wrote a 1 to /proc/sys/net/ipv4/conf/internetz/forwarding and now I can ping things and browse without the SOCKS proxy.
I still don't seem to have forwarding in either direction for IPv6 traffic so there's more tinkering to be done, but having v4 back is a very good start because it should mean my family can get back on their games and TV-streaming while I figure it out.
<edit>
I enabled both flavours of forwarding in /etc/systemd/networkd.conf instead of on individual interfaces. Now it's enabled in /proc/sys/net/ipv{4,6}/conf/all/forwarding as well as all the individual interfaces, and I get ping responses from IPv6 addresses and get full marks from ipv6-test.com.
Last edited by Teaspoon (2024-07-07 08:49:38)
Offline