Fedora 35: share a network connection with NetworkManager & firewalld

Ask Fedora
, ,
1 
[router, connected to WAN]
           |
           |
         [ L1 ]
           .
           .
         [ L2 ]

I want to share an internet connection (via wireless) from L1 with L2. Both L1 & L2 have Fedora 35 installed.

L1 network interfaces are:

  • lan, 192.168.1.33, that is connected to a router via ethernet. It’s NAT’ed.

  • wifi, 10.42.0.1. that is the result of ‘Create New Wi-Fi Network’ dialog from NetworkManger GUI (nm-applet). This is the interface through which L2 connects to L1.

lan is in external firewalld zone, wifi is in nm-shared:

$ sudo firewall-cmd --list-all-zones | awk 'BEGIN {RS=""; ORS="\n\n"} /interfaces: (lan|wifi)/'
nm-shared (active)
  target: ACCEPT
  icmp-block-inversion: no
  interfaces: wifi
  sources:
  services: dhcp dns ssh
  ports:
  protocols: icmp ipv6-icmp
  forward: no
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
        rule priority="32767" reject

external (active)
  target: default
  icmp-block-inversion: no
  interfaces:
  sources:
  services: ssh
  ports:
  protocols:
  forward: no
  masquerade: yes
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

After L2 connects to L1 I expect the former to be under a ‘double NAT’. Unfortunately, while L2 successfully obtains its IP (10.42.0.233) & can ssh to L1, I can’t even ping 1.1.1.1 from L2.

I run wireshark on both L1 network interfaces: lan doesn’t see packets destined for WAN, they all get dropped after arriving to wifi.

I tried:

  • running firewall-cmd --add-forward --zone nm-shared; didn’t help;

  • putting both lan & wifi in ‘trusted’ firewalld zone, then firewall-cmd --add-forward --zone trusted & clicking on ‘masquerade’ for ‘trusted’ zone in firewall-config GUI; didn’t help either.

1 Like
2

I’m unsure, but this might help:

and
in gnome setting => wifi
click on the 3 stacked points (right from on/off) => “… Hotspot …”

3

Collect the following diagnostics and post it to pastebin.com:

# Fedora router
nmcli general status; nmcli connection show; \
sudo firewall-cmd --get-active-zones; \
ip address show; ip route show table all; ip rule show; ip -6 rule show; \
sysctl net 2> /dev/null | grep -e forward; sudo nft list ruleset

# Client behind the router
nslookup discussion.fedoraproject.org; \
tracepath -4 -bm10 discussion.fedoraproject.org; \
tracepath -6 -bm10 discussion.fedoraproject.org
4

https://pastebin.com/BMUF6Des

https://pastebin.com/smDHrXc2

1 Like
5

That’s weird, I see nothing wrong at first glance, except the client cannot traverse the router.
I’ve just tested a similar setup with a couple of Fedora 35 VMs and it works for me.

In any case, you can enable TCP MSS clamping:

# Fedora router
sudo firewall-cmd --permanent --zone=nm-shared \
    --add-rich-rule="rule tcp-mss-clamp value=pmtu"
sudo firewall-cmd --reload

Also try capturing client traffic:

# Fedora router
sudo tcpdump -evni any icmp

# Client behind the router
ping 8.8.8.8
6

Enabling TCP MSS clamping didn’t help.

Client traffic (10.42.0.223 is the client):

$ sudo tcpdump -evni any icmp
tcpdump: data link type LINUX_SLL2
dropped privs to tcpdump
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
14:00:27.458751 wifi  In  ifindex 3 ac:f1:df:04:11:3d ethertype IPv4 (0x0800), length 104: (tos 0x0, ttl 64, id 21070, offset 0, flags [DF], proto ICMP (1), length 84)
    10.42.0.223 > 8.8.8.8: ICMP echo request, id 7, seq 1, length 64
14:00:28.521570 wifi  In  ifindex 3 ac:f1:df:04:11:3d ethertype IPv4 (0x0800), length 104: (tos 0x0, ttl 64, id 21696, offset 0, flags [DF], proto ICMP (1), length 84)
    10.42.0.223 > 8.8.8.8: ICMP echo request, id 7, seq 2, length 64
14:00:29.545557 wifi  In  ifindex 3 ac:f1:df:04:11:3d ethertype IPv4 (0x0800), length 104: (tos 0x0, ttl 64, id 22601, offset 0, flags [DF], proto ICMP (1), length 84)
    10.42.0.223 > 8.8.8.8: ICMP echo request, id 7, seq 3, length 64
14:00:30.569547 wifi  In  ifindex 3 ac:f1:df:04:11:3d ethertype IPv4 (0x0800), length 104: (tos 0x0, ttl 64, id 23223, offset 0, flags [DF], proto ICMP (1), length 84)
    10.42.0.223 > 8.8.8.8: ICMP echo request, id 7, seq 4, length 64
14:00:31.593565 wifi  In  ifindex 3 ac:f1:df:04:11:3d ethertype IPv4 (0x0800), length 104: (tos 0x0, ttl 64, id 23966, offset 0, flags [DF], proto ICMP (1), length 84)
    10.42.0.223 > 8.8.8.8: ICMP echo request, id 7, seq 5, length 64
^C
5 packets captured
5 packets received by filter
0 packets dropped by kernel
1 Like
7

Something strange is going on.

I rebooted & L1 stopped dropping packets; then I rebooted again to check it was not a fluke, but all the previous symptoms returned & I’m back to square one.

Maybe it’s a hardware issue with the wireless chip.

1 Like
8

Possible workarounds for unstable wireless connections: