Hi
Just to finish this off, I can now access the Orange server from Green.
It has been a while since I looked at this issue I’m sorry I don’t recall what I did to get it working.
I can now ping from Green to Orange.
I can ping from Orange to the Internet.
The only firewall rules I have added are for Blue to Orange access, which doesn’t yet work.
Hi
I have this exact same problem again and I don’t know why or how to fix it.
I have done the following trouble shooting:
From the device in the Orange zone (a Raspberry Pi):
I can ping the internet.
I can ping the orange network interface to ipFire vvv.xxx.yyy.1
The device has a fall back profile in dhcpd.conf that assigns a static ip address in the absence of DHCP. The device has the correct ip address.
From the green zone:
I can ping the Orange interface vvv.xxx.yyy.1
but I can’t ping the device in the Orange zone.
I can use PuTTY to ssh into ipFire CLI.
I can no longer use PuTTY to ssh into the device in the Orange zone (connection times out).
From ipFire:
When I look at the ipFire WUI > Firewall Rules, it says Green to Orange is allowed.
I can ping the Orange interface vvv.xxx.yyy.1
I can ping the device in the Orange zone.
I have installed the “Who Is Online” addon. It shows the device in Orange is connected and active.
I can ssh from ipFire into the device in the Orange zone.
Other
I don’t have an internal firewall.
It was working, then it stopped. It may have coincided with an ipFire update but I am not sure if this was the cause, or just coincidence.
This sound scary (to me!). Please explain in more detail.
The Raspberry Pi should be setup with it own static IP address.
Orange devices should only have Static IP addresses (unless you setup a separate DHCP server in Orange).
See: https://wiki.ipfire.org/configuration/firewall/rules/dmz-setup#notes
This sounds scary also… This is what the IPFire does. Please explain in more detail…
You should see messages in the Firewall Logs.
EDIT: see:
Hi
There is no DHCP service on Orange by design. My Raspi dhcpcd.conf is setup to use dhcp by default. If there is no dhcpd service, it defaults to a static address. That all works. It has the correct ip address.
I don’t have a firewall except ipFire. There is nothing behind ipFire that might block ip traffic. There is no other firewall to interfere.
I will make some fresh attempts to make a connection and see what is in the logs.
dazz, to what address does the Raspi default?
The address I set it to. It is a nice feature of DHCPD that allows a static ip to be setup on Orange. There is no dhcp service by ipFire on Orange. The Raspi has to set a static address. So dhcpd.conf is setup to take a ip lease if there is a dhcpd service, or fallback to set a static ip address.
I have had the network setup for years. I haven’t made any changes that I think could block GREEN->ORANGE traffic.
When I try to make a connection from my PC on Green to the Raspi on Orange.
Direct inspection of the logs (messages) in ipFire. When I attempt to log into the device on Orange with PuTTY, there is nothing in the logs.
This the same PuTTY that I use to log into ipFire to watch the logs.
I am stuck. I don’t know what to look at next???
I tried adding a firewall rule to provide access from my PC on GREEN to the Raspi on ORANGE. I know this should not be necessary but it didn’t work.
Troubleshooting this issue involves determining whether the Raspberry Pi (RPi) is receiving ping requests from the GREEN zone or if there is a breakdown in communication. Here’s a step-by-step guide on how to check this on a standard Linux distribution:
Identify the Network Interface: Begin by identifying the network interface on the RPi that is connected to the ORANGE zone. Use the ip a or ifconfig command to list all network interfaces and their corresponding IP addresses.
Run tcpdump: Next, use tcpdump to monitor ICMP (ping) packets on the relevant interface. The command should look like this:
sudo tcpdump -i [interface] icmp
Replace [interface] with the actual network interface name, such as eth0 or wlan0.
Initiate Ping from GREEN Zone: From a device in the GREEN zone, send a ping to the RPi’s IP address in the ORANGE zone.
Observe tcpdump Output: Watch the output of tcpdump on the RPi. If the RPi is receiving ping requests, you’ll see lines displaying incoming ICMP echo requests. These lines detail the packet’s source IP address, destination IP address, and the ICMP message type.
Example output if the RPi is receiving ping requests:
12:34:56.789012 IP [source_ip] > [rpi_ip]: ICMP echo request, id 1234, seq 1, length 64
This indicates an ICMP echo request from [source_ip] in the GREEN zone reaching the RPi at [rpi_ip].
Note: tcpdump requires administrative privileges and is executed with sudo. If it’s not installed on your RPi, it can typically be installed via the package manager (e.g., sudo apt install tcpdump on Debian-based systems).
If tcpdump confirms the arrival of ICMP requests but pinging the RPi from the GREEN zone is unsuccessful, the issue likely lies either with the RPi’s response mechanism or a routing problem between RPi and IPfire preventing the response from reaching the GREEN zone. Conversely, if the ICMP packets are not reaching the RPi, this suggests a need to investigate potential routing issues within IPFire.
Hi
OK tried all that. The results are in the image.
All of this was done from my PC in the Green zone.
The top terminal is cmd on the PC. It shows an attempt to ping the Pi (172.30.23.40) in the Orange zone. tcpdump does not respond to the pings.
The middle terminal is a PuTTY session running on the PC to ipFire. It shows a ping from ipFire to the Pi. This ping is recorded by tcpdump on the Pi.
The bottom window is an ssh session run from ipFire to the Pi in the Orange zone. I cannot directly ssh from my PC to the Pi. This terminal confirms the ip of the Pi is correctly configured. It has the set static ip address.
This terminal also shows the pings recorded by tcmdump from ipFire to the Pi.
I can ping from the Green PC to ipFire.
I can ping from IpFire to the Orange Pi.
I cannot ping from the Green PC to the Orange Pi.
Note the firewall rule shown in the previous post is enabled. This rule should allow traffic from Green to Orange. I can see the rule in ipFire ipTables listing.
ipFire ipTables List.pdf (96.2 KB)
ipFire should work without this rule. It should also work with the rule.
The evidence points to ipFire blocking traffic from Green to Orange. I don’t believe I have done anything that might cause this problem.
Please let me know if there is anything else I can try.
Hi,
It looks like the Pi in the Orange DMZ is missing a default gateway (along with setting the IP manually you also need to have 172.30.23.1 set as the gw on the Pi).
Access from devices on the GREEN LAN to devices on the ORANGE DMZ work ‘out of the box’ with Green to Orange Allowed. You do not need additional rules, but devices in each segment need to have a default gateway pointing at the directly connected IPFire interface. Usually DHCP sets a gateway automatically.
To test if this is the issue - on the Pi terminal (172.30.23.40) type traceroute 172.30.21.1 if you get a ‘Network is unreachable’ error that indicates no route / gateway set and so the Pi has no idea how to connect beyond its local subnet. In that case the ping from Green is received but the Pi does not know where to reply.
On the Pi terminal route -n should show destination 0.0.0.0 gateway 172.30.23.1.
Comparing the Green device route -n will show destination 0.0.0.0 gateway 172.30.21.1
Hi
You were right. Well spotted. A dumb mistake by me.
Unfortunately nothing else has changed.
When I ping from Green to Orange, the PC reports that the Pi is unreachable.
The Green PC reports:
Windows IP Configuration Ethernet adapter Ethernet: Connection-specific DNS Suffix . : Link-local IPv6 Address . . . . . : fe80::d9e7:515b:af3f:a22c%15 IPv4 Address. . . . . . . . . . . : 172.30.21.11 Subnet Mask . . . . . . . . . . . : 255.255.0.0 Default Gateway . . . . . . . . . : 172.30.21.1
So that looks correctly setup.
when I run traceroute from the Orange pi, it returns:
$ traceroute 172.30.21.11
traceroute to 172.30.21.11 (172.30.21.11), 30 hops max, 60 byte packets
1 172.30.23.1 (172.30.23.1) 0.545 ms 0.556 ms 0.469 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 *^C
so the Orange pi can find the Green PC.
As expected, a ping from Orange does not return anything.
When I run route from the Orange pi:
$ sudo route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.30.23.1 0.0.0.0 UG 202 0 0 eth0
172.30.23.0 0.0.0.0 255.255.255.0 U 202 0 0 eth0
Even with the added and unnecessary route in ipFire, it appears that ipFire is blocking the traffic from Green to Orange.
All of the above was again run from the Green PC by ssh to ipFire, then ssh to the Orange pi.
Strange that is the wrong subnet?
172.30.21.0/24
Should be subnet 255.255.255.0
Yes, the mismatched Subnet Masks (/16 /24) are a problem. Change the Green mask to 255.255.255.0 (/24) to match the Orange. In this typical setup, the IPFire Green and Orange NICS and all your devices should have the /24 mask.
The subnet mask is ‘ANDed’ with the IP address to determine the Network portion of the address. If the two communicating IP addresses are determined to be on the same subnet/network then local delivery is used otherwise routing is used (gateway).
In the current config, the Green device sees the network as 172.30 (matches only the two octets used in the Green mask /16) and therefore the Orange address 172.30.23.40 is thought to be local so traffic from Green to Orange will use ARP/MAC instead of forwarding to the gateway 172.30.21.1.
The Pi in Orange with the /24 mask correctly sees the network as 172.30.23 and when it tries to communicate to Green 172.30.21.x it forwards to its gateway now 172.30.23.1 where IPFire routes the traffic to the other subnet on Green.
Hi
Yes, correcting the mask fixed the problem. Thank you.
I removed the unnecessary route and it still worked.
This network has been running for years, and I don’t remember changing any settings but I must have. I’ll just blame the dog. So hopefully this thread might be helpful for others who have messed up the network config.
@dazz, congratulations on resolving the issue, and a special thanks to @hvacguy and @wiztech for their keen insights and solution.
I’d like to highlight an important aspect of troubleshooting, especially in complex network environments. While you diligently performed various tests, the specific test I had suggested was overlooked. This test was designed to determine if the RPi in the ORANGE zone was receiving pings from the GREEN zone. As it turned out, due to the incorrect netmask, devices in the GREEN zone never directed their pings through the gateway to reach the RPi. Had this test been conducted, it would have immediately pointed towards a routing issue, thereby narrowing down the source of the problem more efficiently.
This scenario serves as an excellent example of how crucial it is to ask the right questions and set up appropriate tests when troubleshooting network issues. Identifying and performing the correct test can significantly speed up the process of isolating and resolving the problem.
Another thought to problems like this.
I think it is necessary to document the settings, for yourself and in the thread of the community.
Answering questions depends on knowledge of the topic and the concrete implementation. Regarding the topic even an experienced user assumes “regular settings”. On the other hand a complete documentation shows errors ( sometimes ).
Regarding the issue “problems with old settings in a new system”.
Errors in software can result in “fault tolerant systems”. A correction of the software bug may lower this “tolerance”.
@cfusco I didn’t ignore your suggestions. It is just that they didn’t apply. You said:
"To test this hypothesis I would connect directly to IPFire green interface one machine and the same to the orange assigned ethernet card so to simplify the system. Also, I would make sure as mentioned by @luxskywalker that is not the routing inside your green machine or orange machine the problem due to a local firewall rule. "
I am running ipFire on a dedicated fanless tiny pc with 4x ethernet ports so unable to move cards. I already had/have the simplest system I could configure with one PC on GREEN trying to connect to one Pi on ORANGE. The only firewall rules I have are on ipFire.
If you go back to my first new post 18 Dec on this problem, I had already done a number of tests to check network connectivity. Almost all of my testing/screen shots were done on the PC. I was able to daisy chain ssh sessions through ipFire to get from GREEN to ORANGE. I was not seeing symptoms that pointed to a problem on the PC.
I wasn’t looking for a problem with masking. I still don’t remember why/how/when the network mask was changed. It can only have been me. I think I would have got to the solution in the end because I fixed the same problem before when I originally started this thread. I suffered a significant brain injury 3 years ago and it has affected my memory.
Thanks for all of your efforts in solving this problem. Hopefully the documented solution will help others.
Hi @dazz, glad you got this working.
Once we saw enough of the settings the problems became apparent.
In this case, it was not an issue with IPFire routing or firewall rules at all, it was local client network configuration issues on both endpoint devices involved (Green PC and Orange Pi).
Misconfigurations can be hidden and hard to detect. So the question to ask upfront is “What are the actual configured settings on the machine(s) involved?”
The terminal and command prompt are your friends for this (using standard commands like ifconfig / ipconfig, ping and traceroute).
You did some good basic troubleshooting which you described;
More complex testing, like using a packet sniffer (something an A.I. might suggest) would probably not give much more insight.
The next connectivity troubleshooting step was to look at the actual local settings of the two devices, removing assumptions. Both endpoints had ‘typos’ ;), one missing a gateway address and the other an incorrect netmask.
The effects of the two typos was critical but subtle and hard to see just from the behavior described or to ferret out by further ‘testing’.
Being able to see detailed settings up front would have made the local misconfigurations immediately visible to other experienced users on the forum.
Most of the settings are detailed in the output of ifconfig and route -n from the IPFire terminal and from the Orange Pi along with ipconfig /all from the command prompt of the Green PC.
For future reference and comparison, it could be handy for you to document your now working system by saving the outputs of the commands mentioned along with screenshots of IPFire SystemHome, Firewall Rules and Groups, and DHCP webpages. Then if the dog walks on your keyboard when you are not looking and things break… you will have a quick way to visually compare working to non-working settings 
Like a picture is worth a thousand words 
so is the wealth of information in the output of ifconfig
As @bbitsch noted, when troubleshooting we need to look at the settings of the devices (not just the behavior / misbehavior). That is an efficient way to discover and solve technical problems.
An experienced tech, ‘having read the manuals’ and using in depth knowledge and experience, can look at the concrete configuration and deduce how the system will function (often without even running a test) - an ‘engineering’ approach.
@dazz 's system was behaving correctly and predictably, as defined by its configuration settings. However, it was not functioning as expected and by looking at the settings right away we could figure out how it would behave and how that differed from the expected results.
For example, given all the settings of Green PC (with /16 netmask) and a ‘vanilla’ IPFire install - it would be expected that:
That is why we ask users what is their setup - a diagram and or the actual settings (sanitized as necessary) shared on the forum is most helpful to quickly troubleshoot issues or answer questions.
For example, sharing the config settings like the sample below gives so much concise info about network connectivity: IP addresses, consistent netmasks, consistent MTUs, no physical transmission errors or dropped packets, data sent and received on all interfaces, etc.
[root@ipfire ~]# ifconfig
green0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.100.1 netmask 255.255.255.0 broadcast 0.0.0.0
ether xx:xx:xx:xx:xx:xx txqueuelen 1000 (Ethernet)
RX packets 171871770 bytes 76033671389 (70.8 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 243103917 bytes 123274901228 (114.8 GiB)
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 13185904 bytes 670156233 (639.1 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 13185904 bytes 670156233 (639.1 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
orange0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.200.1 netmask 255.255.255.0 broadcast 0.0.0.0
ether xx:xx:xx:xx:xx:xx txqueuelen 1000 (Ethernet)
RX packets 2582590 bytes 396472904 (378.1 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1193113 bytes 115655978 (110.2 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
red0: flags=67<UP,BROADCAST,RUNNING> mtu 1500
inet xxx.xxx.xxx.xxx netmask 255.255.255.yyy broadcast 0.0.0.0
ether xx:xx:xx:xx:xx:xx txqueuelen 1000 (Ethernet)
RX packets 1018932245 bytes 170753823783 (159.0 GiB)
RX errors 0 dropped 50 overruns 0 frame 0
TX packets 167200461 bytes 74534966841 (69.4 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[root@ipfire ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 yyy.yyy.yyy.zzz 0.0.0.0 UG 0 0 0 red0
yyy.yyy.yyy.xxx 0.0.0.0 255.255.255.240 U 0 0 0 red0
yyy.yyy.yyy.zzz 0.0.0.0 255.255.255.255 UH 0 0 0 red0
192.168.200.0 0.0.0.0 255.255.255.0 U 0 0 0 orange0
192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 green0
