IPFire not forwarding GREEN

Apparently without any change (I left a working system and went to bed) IPFire stopped forwarding GREEN requests.
Symptom was I tried to resume a paused YouTube video it started ok, but when cached data exhausted…

My GREEN is 192.168.7.12/24
I cannot access my modem at 192.168.1.1
I cannot access my webserver at 192.168.9.8 (ORANGE)
But I can access my webserver from the internet (through IPFire)

Fortunately I have two independent Internet connections, so I can leave the main one connected to IPFire and use the “spare” (directly connected on GREEN as 192.168.7.1) to access the Internet and write this.

  • I already tried to reset IPFire.
  • I can see log for Internet redirection when I access webserver from the Internet
  • I do not see any log when trying to access webserver on ORANGE (but that should be normal)
  • current status is:

  • also network looks good to me:
    [root@ipfire ~]# ip a show
    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
        link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
        inet 127.0.0.1/8 scope host lo
           valid_lft forever preferred_lft forever
    2: green0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc cake state UP group default qlen 1000
        link/ether 00:16:3e:9e:f9:83 brd ff:ff:ff:ff:ff:ff
        inet 192.168.7.9/24 scope global green0
           valid_lft forever preferred_lft forever
    3: red0: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc cake state UP group default qlen 1000
        link/ether 00:16:3e:73:3b:3e brd ff:ff:ff:ff:ff:ff
        inet 192.168.1.9/24 scope global red0
           valid_lft forever preferred_lft forever
    4: orange0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc cake state UP group default qlen 1000
        link/ether 00:16:3e:42:f1:ff brd ff:ff:ff:ff:ff:ff
        inet 192.168.9.9/24 scope global orange0
           valid_lft forever preferred_lft forever
    [root@ipfire ~]# ip r show
    default via 192.168.1.1 dev red0 
    192.168.1.0/24 dev red0 proto kernel scope link src 192.168.1.9 
    192.168.1.1 dev red0 scope link 
    192.168.7.0/24 dev green0 proto kernel scope link src 192.168.7.9 
    192.168.9.0/24 dev orange0 proto kernel scope link src 192.168.9.9 
    [root@ipfire ~]# 
    

What should I check?
Many Thanks in advance

Update:
I enabled Masquerading on GREEN and ORANGE, rebooted and I got back connection to Modem (192.168.1.1) but still no connection to webserver (192.168.9.8) :frowning:

Of course from IPFire I can access both webserver and modem.

I am pretty desperate now :scream:
TiA!

But the pinhole is only required for the orange to green access.

@mc5686 is having problems accessing the server in orange from green. Also that access worked yesterday but now it seems that accessing anything from green has become a problem.

Here you said that green was 192.168.7.12 but from the ip command you have green with 192.168.7.9

Which one is supposed to be your IPFire green IP address. If 192.168.7.12 then it means that some action re-did the IP address settings on your IPFire.

If it is supposed to be 192.168.7.9 then presumably the first reference to green being 192.168.7.12 was a typo.

Thanks @bbitsch,
can you be a bit more explicit, please?

Pointed page (seems to me to) state clearly:
GreenOrange Open

If I read that page correctly (which is far from being sure) from GREEN I should
be able to access almost everything; reverse is not true, of course.

I am not trying to access GREEN from ORANGE.

Please correct me

Sorry, my fault. Didnt read thoroughly. :frowning:
I’ve deleted my post.

Sorry for the confusion.

IPFire NIC on GREEN is inet 192.168.7.9/24 scope global green0

Workstation I’m working on (on GREEN, of course) has address 192.198.7.12.

I am trying to access 192.168.9.8 (on ORANGE), so route should be:

(cinderella) 192.68.7.12 -- 192.168.7.9 (IPFire) 192.168.9.9 -- 192.168.9.8 (webserver)

So what happens if, from your workstation in green (192.168.7.12), you run
ping -c4 192.168.9.8
and the same command when run from your IPFire terminal?

Further Update:
I was able to open a “DMZ pinhole” from green as:

Notice this did not work without DNAT
and did not work with "Firewall Interface: - Automatic -

I m beginning to suspect kernel refuses to route “private” (i.e.: non-routable) addresses,
but that doesn’t make sense to me :frowning: (in this context).

mcon@cinderella:~$ ping -c4 192.168.9.8
PING 192.168.9.8 (192.168.9.8) 56(84) bytes of data.

--- 192.168.9.8 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3068ms

mcon@cinderella:~$ ssh root@ipfire -- ping -c4 192.168.9.8
PING 192.168.9.8 (192.168.9.8) 56(84) bytes of data.
64 bytes from 192.168.9.8: icmp_seq=1 ttl=64 time=0.775 ms
64 bytes from 192.168.9.8: icmp_seq=2 ttl=64 time=1.16 ms
64 bytes from 192.168.9.8: icmp_seq=3 ttl=64 time=1.01 ms
64 bytes from 192.168.9.8: icmp_seq=4 ttl=64 time=1.01 ms

--- 192.168.9.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 0.775/0.990/1.163/0.138 ms
mcon@cinderella:~$ ssh root@192.168.7.9 -- ping -c4 192.168.9.8
PING 192.168.9.8 (192.168.9.8) 56(84) bytes of data.
64 bytes from 192.168.9.8: icmp_seq=1 ttl=64 time=0.866 ms
64 bytes from 192.168.9.8: icmp_seq=2 ttl=64 time=1.24 ms
64 bytes from 192.168.9.8: icmp_seq=3 ttl=64 time=1.10 ms
64 bytes from 192.168.9.8: icmp_seq=4 ttl=64 time=1.08 ms

--- 192.168.9.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 0.866/1.073/1.243/0.134 ms
mcon@cinderella:~$ 
```

So 100% packet loss when trying to go to the server in orange.

What happens with
ping -c4 192.168.9.9
and
ping -c4 192.168.7.9

mcon@cinderella:~$ ping -c4 192.168.9.9
PING 192.168.9.9 (192.168.9.9) 56(84) bytes of data.

--- 192.168.9.9 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3057ms

mcon@cinderella:~$ ping -c4 192.168.7.9
PING 192.168.7.9 (192.168.7.9) 56(84) bytes of data.
64 bytes from 192.168.7.9: icmp_seq=1 ttl=64 time=1.39 ms
64 bytes from 192.168.7.9: icmp_seq=2 ttl=64 time=1.48 ms
64 bytes from 192.168.7.9: icmp_seq=3 ttl=64 time=1.22 ms
64 bytes from 192.168.7.9: icmp_seq=4 ttl=64 time=1.20 ms

--- 192.168.7.9 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 1.199/1.323/1.481/0.118 ms
mcon@cinderella:~$ 

It seems IPFire refuses to forward packets between its own interfaces (without any logs),
but I cannot understand why (in this specific case)

Full dump of tables follows (but I’m out of my depth here):

[root@ipfire ~]# iptables-save
# Generated by iptables-save v1.8.9 on Wed Jun 28 13:56:54 2023
*raw
:PREROUTING ACCEPT [126206:94135447]
:OUTPUT ACCEPT [41025:7028674]
COMMIT
# Completed on Wed Jun 28 13:56:54 2023
# Generated by iptables-save v1.8.9 on Wed Jun 28 13:56:54 2023
*mangle
:PREROUTING ACCEPT [7921:1308260]
:INPUT ACCEPT [7175:1167334]
:FORWARD ACCEPT [746:140926]
:OUTPUT ACCEPT [6827:1260869]
:POSTROUTING ACCEPT [7563:1401120]
:NAT_DESTINATION - [0:0]
-A PREROUTING -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff
-A PREROUTING -j NAT_DESTINATION
COMMIT
# Completed on Wed Jun 28 13:56:54 2023
# Generated by iptables-save v1.8.9 on Wed Jun 28 13:56:54 2023
*nat
:PREROUTING ACCEPT [2495:173595]
:INPUT ACCEPT [2325:164638]
:OUTPUT ACCEPT [1001:78177]
:POSTROUTING ACCEPT [22:1144]
:CAPTIVE_PORTAL - [0:0]
:CUSTOMPOSTROUTING - [0:0]
:CUSTOMPREROUTING - [0:0]
:IPSECNAT - [0:0]
:NAT_DESTINATION - [0:0]
:NAT_DESTINATION_FIX - [0:0]
:NAT_SOURCE - [0:0]
:OVPNNAT - [0:0]
:REDNAT - [0:0]
:SQUID - [0:0]
-A PREROUTING -j CUSTOMPREROUTING
-A PREROUTING -j CAPTIVE_PORTAL
-A PREROUTING -j SQUID
-A PREROUTING -j NAT_DESTINATION
-A OUTPUT -j NAT_DESTINATION
-A POSTROUTING -j CUSTOMPOSTROUTING
-A POSTROUTING -j OVPNNAT
-A POSTROUTING -j IPSECNAT
-A POSTROUTING -j NAT_SOURCE
-A POSTROUTING -j NAT_DESTINATION_FIX
-A POSTROUTING -j REDNAT
-A NAT_DESTINATION -d 192.168.1.9/32 -p tcp -m tcp --dport 443 -m limit --limit 10/sec --limit-burst 20 -j LOG --log-prefix "DNAT "
-A NAT_DESTINATION -d 192.168.1.9/32 -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.9.8
-A NAT_DESTINATION -d 192.168.1.9/32 -p tcp -m tcp --dport 80 -m limit --limit 10/sec --limit-burst 20 -j LOG --log-prefix "DNAT "
-A NAT_DESTINATION -d 192.168.1.9/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.9.8
-A NAT_DESTINATION -s 192.168.7.0/24 -d 192.168.7.9/32 -p tcp -m tcp --dport 4000 -m limit --limit 10/sec --limit-burst 20 -j LOG --log-prefix "DNAT "
-A NAT_DESTINATION -s 192.168.7.0/24 -d 192.168.7.9/32 -p tcp -m tcp --dport 4000 -j DNAT --to-destination 192.168.9.8
-A NAT_DESTINATION_FIX -m mark --mark 0x1000000/0xf000000 -j SNAT --to-source 192.168.7.9
-A NAT_DESTINATION_FIX -m mark --mark 0x4000000/0xf000000 -j SNAT --to-source 192.168.9.9
-A REDNAT -o red0 -m policy --dir out --pol ipsec -j RETURN
-A REDNAT -o red0 -j MASQUERADE
COMMIT
# Completed on Wed Jun 28 13:56:54 2023
# Generated by iptables-save v1.8.9 on Wed Jun 28 13:56:54 2023
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:BADTCP - [0:0]
:BLOCKLISTIN - [0:0]
:BLOCKLISTOUT - [0:0]
:CAPTIVE_PORTAL - [0:0]
:CAPTIVE_PORTAL_CLIENTS - [0:0]
:CONNTRACK - [0:0]
:CTINVALID - [0:0]
:CUSTOMFORWARD - [0:0]
:CUSTOMINPUT - [0:0]
:CUSTOMOUTPUT - [0:0]
:DHCPBLUEINPUT - [0:0]
:DHCPBLUEOUTPUT - [0:0]
:DHCPGREENINPUT - [0:0]
:DHCPGREENOUTPUT - [0:0]
:DHCPINPUT - [0:0]
:DHCPOUTPUT - [0:0]
:FORWARDFW - [0:0]
:GUARDIAN - [0:0]
:GUIINPUT - [0:0]
:HOSTILE - [0:0]
:HOSTILE_DROP - [0:0]
:ICMPINPUT - [0:0]
:INPUTFW - [0:0]
:IPSBYPASS - [0:0]
:IPSECBLOCK - [0:0]
:IPSECFORWARD - [0:0]
:IPSECINPUT - [0:0]
:IPSECOUTPUT - [0:0]
:IPS_FORWARD - [0:0]
:IPS_INPUT - [0:0]
:IPS_OUTPUT - [0:0]
:IPTVFORWARD - [0:0]
:IPTVINPUT - [0:0]
:LOCATIONBLOCK - [0:0]
:LOG_DROP - [0:0]
:LOG_REJECT - [0:0]
:LOOPBACK - [0:0]
:NEWNOTSYN - [0:0]
:OUTGOINGFW - [0:0]
:OVPNBLOCK - [0:0]
:OVPNINPUT - [0:0]
:POLICYFWD - [0:0]
:POLICYIN - [0:0]
:POLICYOUT - [0:0]
:PSCAN - [0:0]
:REDFORWARD - [0:0]
:REDINPUT - [0:0]
:SPOOFED_MARTIAN - [0:0]
:TOR_INPUT - [0:0]
:TOR_OUTPUT - [0:0]
:WIRELESSFORWARD - [0:0]
:WIRELESSINPUT - [0:0]
-A INPUT -m mark --mark 0xc0000000/0xc0000000 -j IPSBYPASS
-A INPUT -p tcp -j BADTCP
-A INPUT -j CUSTOMINPUT
-A INPUT -j HOSTILE
-A INPUT ! -p icmp -j BLOCKLISTIN
-A INPUT -j GUARDIAN
-A INPUT -i tun+ -j OVPNBLOCK
-A INPUT -m mark --mark 0x0/0xc0000000 -j IPS_INPUT
-A INPUT -j IPTVINPUT
-A INPUT -j ICMPINPUT
-A INPUT -j LOOPBACK
-A INPUT -j CAPTIVE_PORTAL
-A INPUT -j CONNTRACK
-A INPUT -i green0 -j DHCPGREENINPUT
-A INPUT -j TOR_INPUT
-A INPUT -j LOCATIONBLOCK
-A INPUT -j IPSECINPUT
-A INPUT -j GUIINPUT
-A INPUT -m conntrack --ctstate NEW -j WIRELESSINPUT
-A INPUT -j OVPNINPUT
-A INPUT -j INPUTFW
-A INPUT -j REDINPUT
-A INPUT -j POLICYIN
-A FORWARD -m mark --mark 0xc0000000/0xc0000000 -j IPSBYPASS
-A FORWARD -p tcp -j BADTCP
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
-A FORWARD -j CUSTOMFORWARD
-A FORWARD -j HOSTILE
-A FORWARD ! -p icmp -j BLOCKLISTIN
-A FORWARD ! -p icmp -j BLOCKLISTOUT
-A FORWARD -j GUARDIAN
-A FORWARD -m policy --dir out --pol none -j IPSECBLOCK
-A FORWARD -i tun+ -j OVPNBLOCK
-A FORWARD -o tun+ -j OVPNBLOCK
-A FORWARD -m mark --mark 0x0/0xc0000000 -j IPS_FORWARD
-A FORWARD -j IPTVFORWARD
-A FORWARD -j LOOPBACK
-A FORWARD -j CAPTIVE_PORTAL
-A FORWARD -j CONNTRACK
-A FORWARD -j LOCATIONBLOCK
-A FORWARD -j IPSECFORWARD
-A FORWARD -m conntrack --ctstate NEW -j WIRELESSFORWARD
-A FORWARD -j FORWARDFW
-A FORWARD -j REDFORWARD
-A FORWARD -j POLICYFWD
-A OUTPUT -m mark --mark 0xc0000000/0xc0000000 -j IPSBYPASS
-A OUTPUT -j CUSTOMOUTPUT
-A OUTPUT -j HOSTILE
-A OUTPUT ! -p icmp -j BLOCKLISTOUT
-A OUTPUT -m policy --dir out --pol none -j IPSECBLOCK
-A OUTPUT -m mark --mark 0x0/0xc0000000 -j IPS_OUTPUT
-A OUTPUT -j LOOPBACK
-A OUTPUT -j CONNTRACK
-A OUTPUT -o green0 -j DHCPGREENOUTPUT
-A OUTPUT -j IPSECOUTPUT
-A OUTPUT -j TOR_OUTPUT
-A OUTPUT -j OUTGOINGFW
-A OUTPUT -j POLICYOUT
-A BADTCP -i lo -j RETURN
-A BADTCP -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,PSH,URG -j PSCAN
-A BADTCP -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,ACK,URG -j PSCAN
-A BADTCP -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN,SYN,RST,PSH,ACK,URG -j PSCAN
-A BADTCP -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG FIN -j PSCAN
-A BADTCP -p tcp -m tcp --tcp-flags SYN,RST SYN,RST -j PSCAN
-A BADTCP -p tcp -m tcp --tcp-flags FIN,SYN FIN,SYN -j PSCAN
-A BADTCP -p tcp -m tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j PSCAN
-A BADTCP -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j NEWNOTSYN
-A CAPTIVE_PORTAL_CLIENTS -p udp -m udp --dport 53 -m hashlimit --hashlimit-upto 3kb/s --hashlimit-burst 1mb --hashlimit-mode srcip --hashlimit-name dns-filter -j RETURN
-A CAPTIVE_PORTAL_CLIENTS -p tcp -m tcp --dport 53 -m hashlimit --hashlimit-upto 3kb/s --hashlimit-burst 1mb --hashlimit-mode srcip --hashlimit-name dns-filter -j RETURN
-A CAPTIVE_PORTAL_CLIENTS -j DROP
-A CONNTRACK -m conntrack --ctstate ESTABLISHED -j ACCEPT
-A CONNTRACK -m conntrack --ctstate INVALID -j CTINVALID
-A CONNTRACK -p icmp -m conntrack --ctstate RELATED -j ACCEPT
-A CTINVALID -m limit --limit 10/sec -j LOG --log-prefix "DROP_CTINVALID "
-A CTINVALID -m comment --comment DROP_CTINVALID -j DROP
-A DHCPGREENINPUT -i green0 -j DHCPINPUT
-A DHCPGREENOUTPUT -o green0 -j DHCPOUTPUT
-A DHCPINPUT -p udp -m udp --sport 68 --dport 67 -j ACCEPT
-A DHCPINPUT -p tcp -m tcp --sport 68 --dport 67 -j ACCEPT
-A DHCPOUTPUT -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A DHCPOUTPUT -p tcp -m tcp --sport 67 --dport 68 -j ACCEPT
-A FORWARDFW -d 192.168.9.8/32 -i red0 -p tcp -m tcp --dport 443 -m limit --limit 10/sec --limit-burst 20 -j LOG --log-prefix "FORWARDFW "
-A FORWARDFW -d 192.168.9.8/32 -i red0 -p tcp -m tcp --dport 443 -j ACCEPT
-A FORWARDFW -d 192.168.9.8/32 -i red0 -p tcp -m tcp --dport 80 -m limit --limit 10/sec --limit-burst 20 -j LOG --log-prefix "FORWARDFW "
-A FORWARDFW -d 192.168.9.8/32 -i red0 -p tcp -m tcp --dport 80 -j ACCEPT
-A FORWARDFW -s 192.168.7.0/24 -d 192.168.9.8/32 -i green0 -p tcp -m tcp --dport 4000 -m limit --limit 10/sec --limit-burst 20 -j LOG --log-prefix "FORWARDFW "
-A FORWARDFW -s 192.168.7.0/24 -d 192.168.9.8/32 -i green0 -p tcp -m tcp --dport 4000 -j ACCEPT
-A GUIINPUT -i green0 -p tcp -m tcp --dport 444 -j ACCEPT
-A HOSTILE -i red0 -m set --match-set XD src -j HOSTILE_DROP
-A HOSTILE -o red0 -m set --match-set XD dst -j HOSTILE_DROP
-A HOSTILE_DROP -m limit --limit 10/sec -j LOG --log-prefix "DROP_HOSTILE "
-A HOSTILE_DROP -m comment --comment DROP_HOSTILE -j DROP
-A ICMPINPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A IPSBYPASS -j CONNMARK --save-mark --nfmask 0x7fffffff --ctmask 0x7fffffff
-A LOG_DROP -m limit --limit 10/sec -j LOG
-A LOG_DROP -j DROP
-A LOG_REJECT -m limit --limit 10/sec -j LOG
-A LOG_REJECT -j REJECT --reject-with icmp-port-unreachable
-A LOOPBACK -i lo -j ACCEPT
-A LOOPBACK -o lo -j ACCEPT
-A LOOPBACK -s 127.0.0.0/8 -j SPOOFED_MARTIAN
-A LOOPBACK -d 127.0.0.0/8 -j SPOOFED_MARTIAN
-A NEWNOTSYN -m limit --limit 10/sec -j LOG --log-prefix "DROP_NEWNOTSYN "
-A NEWNOTSYN -m comment --comment DROP_NEWNOTSYN -j DROP
-A OVPNBLOCK -p icmp -m conntrack --ctstate RELATED -j RETURN
-A POLICYFWD -s 192.168.7.0/24 -i green0 -j ACCEPT
-A POLICYFWD -m policy --dir in --pol ipsec -j ACCEPT
-A POLICYFWD -i tun+ -j ACCEPT
-A POLICYFWD -s 192.168.9.0/24 -i orange0 -o red0 -j ACCEPT
-A POLICYFWD -m limit --limit 10/sec -j LOG --log-prefix "DROP_FORWARD "
-A POLICYFWD -m comment --comment DROP_FORWARD -j DROP
-A POLICYIN -p udp -m udp --dport 514 -j DROP
-A POLICYIN -i green0 -j ACCEPT
-A POLICYIN -m policy --dir in --pol ipsec -j ACCEPT
-A POLICYIN -i tun+ -j ACCEPT
-A POLICYIN -m limit --limit 10/sec -j LOG --log-prefix "DROP_INPUT "
-A POLICYIN -m comment --comment DROP_INPUT -j DROP
-A POLICYOUT -j ACCEPT
-A POLICYOUT -m comment --comment DROP_OUTPUT -j DROP
-A PSCAN -p tcp -m limit --limit 10/sec -m comment --comment "DROP_TCP PScan" -j LOG --log-prefix "DROP_TCP Scan "
-A PSCAN -p udp -m limit --limit 10/sec -m comment --comment "DROP_UDP PScan" -j LOG --log-prefix "DROP_UDP Scan "
-A PSCAN -p icmp -m limit --limit 10/sec -m comment --comment "DROP_ICMP PScan" -j LOG --log-prefix "DROP_ICMP Scan "
-A PSCAN -f -m limit --limit 10/sec -m comment --comment "DROP_FRAG PScan" -j LOG --log-prefix "DROP_FRAG Scan "
-A PSCAN -m comment --comment DROP_PScan -j DROP
-A REDINPUT -s 192.168.1.9/32 -i red0 -j SPOOFED_MARTIAN
-A SPOOFED_MARTIAN -m limit --limit 10/sec -j LOG --log-prefix "DROP_SPOOFED_MARTIAN "
-A SPOOFED_MARTIAN -m comment --comment DROP_SPOOFED_MARTIAN -j DROP
COMMIT
# Completed on Wed Jun 28 13:56:54 2023
[root@ipfire ~]# 

I can’t judge anything from the firewall rules. Anyway, you would really need to have a delta between what it was yesterday and what it is today because yesterday it worked.

Do you have any other machine on the green network or do you have a laptop that can connect to green so that the same last two tests can be done to see if it is specific to the 192.168.7.12 IP or to the whole of the green subnet.

The only change I am aware from yesterday (besides tests to understand what went wrong) is
I reactivated DHCP server on modem/router (192.168.1.1) to allow direct connection to WiFi.

I do have several machines on GREEN.
Testing with them I found problem:
I still had my default route pointing to “auxiliary modem” and not to IPFire.

So “cure” was to re-enable Masquerading for GREEN and ORANGE.
I don’t understand it tough, that setting is there since days (at least), what may have
happened this night?

1 Like