Additional Wi-Fi Subnet (in orange) is not accessible from green Clients

Network Routing
1

Hi everyone, I’m really struggling with a Problem right now - everything was working fine until about six months ago. I can’t tell if it stopped working after an IPFire update or a Debian update from bookworm to trixie ^^

networksetup
networksetup971×701 42.9 KB

I cannot access the additional 192.168.254.0/24 (IoT) Network, which is connected to the orange network, from any Green client.

However, from the green network, I can ping 192.168.254.1 - but I can’t reach any other IP addresses in the .254 subnet

ipfirestaticroute
ipfirestaticroute1163×298 14.1 KB

[root@LUXfire ~]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         gateway         0.0.0.0         UG    0      0        0 ppp0
10.0.0.0        0.0.0.0         255.255.255.252 U     0      0        0 red0
10.10.10.0      0.0.0.0         255.255.255.0   U     0      0        0 wg0
10.10.11.0      0.0.0.0         255.255.255.0   U     0      0        0 tun0
gateway         0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
192.168.11.0    0.0.0.0         255.255.255.0   U     0      0        0 green0
192.168.12.0    0.0.0.0         255.255.255.0   U     0      0        0 orange0
192.168.13.0    0.0.0.0         255.255.255.0   U     0      0        0 blue0
[root@LUXfire ~]#

no route entry after adding Static Route via WebGUI?

Ping from green Client 192.168.11.2/24 to the intern WiFi Card 192.168.254.1/24 on APU orange Network 192.168.12.230/24 works

PS C:\Users\Lux> ping 192.168.254.1

Ping wird ausgeführt für 192.168.254.1 mit 32 Bytes Daten:
Antwort von 192.168.254.1: Bytes=32 Zeit=1ms TTL=63
Antwort von 192.168.254.1: Bytes=32 Zeit=1ms TTL=63
Antwort von 192.168.254.1: Bytes=32 Zeit=1ms TTL=63
Antwort von 192.168.254.1: Bytes=32 Zeit=1ms TTL=63

Ping-Statistik für 192.168.254.1:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 1ms, Maximum = 1ms, Mittelwert = 1ms
PS C:\Users\Lux>

if i remove the static Route from IPFire i can’t access 192.168.254.1 from green Client anymore - so i assume the Static Route on IPFire is working ^^

route from APU Smarthome

[09:27:31] root@apu:~# route
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
default         192.168.12.1    0.0.0.0         UG    0      0        0 br0
192.168.12.0    0.0.0.0         255.255.255.0   U     0      0        0 br0
192.168.254.0   0.0.0.0         255.255.255.0   U     0      0        0 wlp4s0
[11:26:10] root@apu:~#

/etc/network/interfaces from APU

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

allow-hotplug enp1s0
iface enp1s0 inet manual

allow-hotplug enp2s0
iface enp2s0 inet manual

allow-hotplug enp3s0
iface enp3s0 inet manual

# Bridge setup
auto br0
iface br0 inet static
  address 192.168.12.230/24
  broadcast 192.168.12.255
  gateway 192.168.12.1
  bridge_ports enp1s0 enp2s0 enp3s0
#  bridge_stp off                                                # disable Spanning Tree Protocol
#  bridge_waitport 0                                             # no delay before a port becomes available
#  bridge_fd 0                                                   # no forwarding delay

# WLAN IoT setup
auto wlp4s0
iface wlp4s0 inet static
  address 192.168.254.1/24
  broadcast 192.168.254.255
#  gateway 192.168.12.1

Otherwise, everything works - my OpenHAB at 192.168.12.230 can reach the IoT devices on 192.168.254.0/24, and the IoT devices register properly in OpenHAB

I just can’t reach the IoT network from the green side - every Device in IoT has an WebGUI

Right now, I’m pretty unsure whether my problem lies on the IPFire side or the Debian APU side…

Since my Network Printer only supports 2.4GHz Wi-Fi, I can only connect it via the IoT network, so I really need to regain access ^^

if any additional Information needed let me know pls :smiling_face_with_sunglasses:

Due to the physical Layout, it’s difficult for me to make any changes to the Setup - but since it used to work before, I’m pretty sure I’m missing either a Route or a NAT rule…

IPFire 2.29 (x86_64) - Core-Update 202 running

2

IPFire has access from Green to Orange available by default (unless you have changed the Outgoing and/or Forward options to Blocked) so you should be able to access the APU SmartHome system via its 192.168.12.230 IP.

If you can do that then the problem is in your APU SmartHome system. Effectively you have a double NAT type of situation here as you have a subnet change from green to orange and then again from orange to the other side of the APU SmartHome.

If you can’t access the APU SmartHome system from Green then you need to check your IPFire logs to see why the traffic is being blocked.

3

sorry for beeing unclear ^^

the access to orange Network works without issues from green

but i can’t access the IoT 192.168.254.0/24 Network from my green Clients - except the WiFi Card with 192.168.254.1, so i assume general access is possible

no logging in the Firewall Logs visible ^^

so i am lost a bit atm

actually i don’t know it’s a re-route Issue from my Debian APU System or a NAT Issue from IPFire side ^^

i have tried so many different NAT/MASQUERADE Rules & additional route Settings both on IPFire and Debian APU Side…

4

Then the problem has to be in the APU not allowing your traffic to be routed to the other subnet.

5

Okay, any tips or suggestions are welcome

i am working on this since Weeks without success

to be clear: ‘the APU Smarthome’ is basically a APU2C4 with Debian 13.5 ‘trixie’ installed

6

So there must be a rule in the APU allowing your traffic to get to 192.168.254.1.
In that case you could change that rule to allow all traffic from the IPFire Orange IP to be forwarded to the 192.168.254.0/24 subnet.

7

but you must have, at least some basic routing set up on that system as it has three nics, each with a different subnet. There has to be something set up on that system to route the traffic from 192.168.12.0/24 subnet to the subnet 192.168.12.0/24 or subnet 192.168.254.0/24

8

It looks like there is a firewall running on the 192.168.12.230 device that is blocking communication to the 192.168.254.0/24 network.

I would check if NAT is enabled on 192.168.12.230 for 192.168.254.0/24. If so, you need to disable it.

9 
[18:21:26] root@apu:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

18:21:33] root@apu:~# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
[18:21:37] root@apu:~#

no FW or NAT Rule enabled on APU - Debian trixie minimal Setup

10

another maybe strange question, whether hosts in the 192.168.254.0/24 network have the default gw set to 192.168.254.1

11

okay, i got it!

sysctl net.ipv4.ip_forward=1

must be set on APU - for any reason this has to be changed/overwritten on APU with Debian trixie upgrade ^^

for surviving a reboot create a .conf File (in my case ‘12-ipv4forward.conf’) under ‘/etc/sysctl.d/’ with the following Content:

#enable forward ipv4
net.ipv4.ip_forward=1

so not an IPFire issue - Sorry for the noise!

12

as you can reach 192.168.254.1 but not any other device in 192.168.254.0/24, the static route on IPFire is probably working. The problem is more likely on the Debian APU. Check that IP forwarding is enabled (net.ipv4.ip_forward=1) and that there aren’t any nftables/iptables rules blocking traffic between br0 and wlp4s0. Also make sure the IoT devices use 192.168.254.1 as their default gateway; otherwise they won’t know how to return traffic to the Green network. I’d also verify that no recent Debian firewall or routing changes were introduced during the Bookworm → Trixie upgrade.

13

i’ve posted the Solution 30 Days ago ^^

and believe me, i have it working before upgrading bookworm to trixie

anything has changed in my Setup while upgrading and it messed up my forwarding because it was not existent anymore afterwards