Port Forwarding Issues with 4G LTE HAT on DietPi

Hey

I’ve been running DietPi on my Raspberry Pi and had a setup with Docker Compose which was functioning perfectly. Using my router’s port forwarding, I was able to access my web applications securely over HTTPS from any browser. Here’s my initial setup:

DietPi v8.21.1 : 1 APT updates available
─────────────────────────────────────────────────────
- Device model : RPi 4 Model B (aarch64)
- CPU temp : 31 °C / 87 °F : Cool runnings
- LAN IP : 192.168.1.80 (eth0)
- MOTD : Open Beta v8.22 | Please help testing our upcoming release:
         https://github.com/MichaIng/DietPi/issues/6625

However, I recently added a 4G LTE HAT to my Raspberry Pi. Since then, I noticed the LAN IP has changed and seems to be using wwan0 :

DietPi v8.21.1 : 1 APT updates available
─────────────────────────────────────────────────────
- Device model : RPi 4 Model B (aarch64)
- CPU temp : 31 °C / 87 °F : Cool runnings
- LAN IP : 10.29.204.36 (wwan0)
- MOTD : Open Beta v8.22 | Please help testing our upcoming release:
         https://github.com/MichaIng/DietPi/issues/6625

Since adding the HAT, I’ve been unable to access my web applications. I checked the ports 80, 443, 8812, and 9009, and all appear to be closed.

Has anyone experienced similar issues with the integration of a 4G LTE HAT on DietPi? Any pointers or solutions to get the port forwarding working with this setup would be greatly appreciated.

Thanks in advance!

dietpi@DietPi:~$ sudo ifconfig
br-5c971b325129: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.18.0.1  netmask 255.255.0.0  broadcast 172.18.255.255
        inet6 fe80::42:56ff:fe55:33ff  prefixlen 64  scopeid 0x20<link>
        ether 02:42:56:55:33:ff  txqueuelen 0  (Ethernet)
        RX packets 4563  bytes 1915009 (1.8 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5074  bytes 2741537 (2.6 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        ether 02:42:c3:65:cb:86  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.80  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::da3a:ddff:fe48:44e4  prefixlen 64  scopeid 0x20<link>
        inet6 2a01:e0a:173:5530:da3a:ddff:fe48:44e4  prefixlen 64  scopeid 0x0<global>
        ether d8:3a:dd:48:44:e4  txqueuelen 1000  (Ethernet)
        RX packets 9586  bytes 1066652 (1.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5071  bytes 2066153 (1.9 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 6  bytes 1520 (1.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 6  bytes 1520 (1.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

veth3480455: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::30dd:1ff:fe2a:6cf3  prefixlen 64  scopeid 0x20<link>
        ether 32:dd:01:2a:6c:f3  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 25  bytes 1842 (1.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

veth9c2a915: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::7062:f6ff:fe3a:2650  prefixlen 64  scopeid 0x20<link>
        ether 72:62:f6:3a:26:50  txqueuelen 0  (Ethernet)
        RX packets 827  bytes 59961 (58.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1370  bytes 1548547 (1.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vethb036cca: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::415:69ff:fe35:c499  prefixlen 64  scopeid 0x20<link>
        ether 06:15:69:35:c4:99  txqueuelen 0  (Ethernet)
        RX packets 3379  bytes 1869480 (1.7 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3446  bytes 1167854 (1.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vethd887ab3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::e8e2:3eff:fecf:5d04  prefixlen 64  scopeid 0x20<link>
        ether ea:e2:3e:cf:5d:04  txqueuelen 0  (Ethernet)
        RX packets 4791  bytes 2131719 (2.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4741  bytes 2110643 (2.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wwan0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.29.204.36  netmask 255.255.255.248  destination 10.29.204.36
        inet6 fe80::4181:f4a8:b4f1:fd0e  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
        RX packets 2444  bytes 2172770 (2.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2149  bytes 320679 (313.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
dietpi@DietPi:~$ ip r
default via 10.29.204.37 dev wwan0
10.29.204.32/29 dev wwan0 proto kernel scope link src 10.29.204.36
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.18.0.0/16 dev br-5c971b325129 proto kernel scope link src 172.18.0.1
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.80
dietpi@DietPi:~$ ping -I eth0  www.google.com  -c 3
PING www.google.com(par10s41-in-x04.1e100.net (2a00:1450:4007:80d::2004)) from 2a01:e0a:173:5530:da3a:ddff:fe48:44e4 eth0: 56 data bytes
64 bytes from par10s21-in-x04.1e100.net (2a00:1450:4007:80d::2004): icmp_seq=1 ttl=117 time=17.3 ms
64 bytes from par10s21-in-x04.1e100.net (2a00:1450:4007:80d::2004): icmp_seq=2 ttl=117 time=17.7 ms
64 bytes from par10s21-in-x04.1e100.net (2a00:1450:4007:80d::2004): icmp_seq=3 ttl=117 time=17.9 ms
dietpi@DietPi:~$ ping -I wwan0  www.google.com  -c 3
PING  (142.250.201.164) from 10.29.204.36 wwan0: 56(84) bytes of data.
64 bytes from par21s23-in-f4.1e100.net (142.250.201.164): icmp_seq=1 ttl=116 time=140 ms
64 bytes from par21s23-in-f4.1e100.net (142.250.201.164): icmp_seq=2 ttl=116 time=58.6 ms
64 bytes from par21s23-in-f4.1e100.net (142.250.201.164): icmp_seq=3 ttl=116 time=57.3 ms

Which IP address you are using to connect from external? The one from your broadband internet connection or the one from 4G module?

Your default gateway has changed to the LTE, so all replies to incoming connections from the eth0 are routed via wwan0.
Do you need the LTE connection to be primary? If not, disable the default gateway.
Otherwise you’ll need to create policy routing rules for the services which need to be routed via eth0.

1 Like

with standard internet connection.
from the container i have:

coder@881ae469421f:~$ sudo ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.20.0.3  netmask 255.255.0.0  broadcast 172.20.255.255
        ether 02:42:ac:14:00:03  txqueuelen 0  (Ethernet)
        RX packets 316042  bytes 51734048 (49.3 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 359257  bytes 76212834 (72.6 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 1530  bytes 143725 (140.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1530  bytes 143725 (140.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
coder@881ae469421f:~$ sudo route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.20.0.1      0.0.0.0         UG    0      0        0 eth0
172.20.0.0      0.0.0.0         255.255.0.0     U     0      0        0 eth0
coder@881ae469421f:~$ 

Thanks @trendy, i will try.

i am waiting a fixed public ip address SIM card from my provider, then i will use the LTE connection as primary.

The routing from inside the container doesn’t matter much, it is the host routing that matters.
If your LTE has a public IP and the incoming connections come from there, you won’t have issues with the existing setup.

Many thanks for your valuable assistance.

1 Like