I am trying to set up ipfire for the first time and cannot get port forwarding to work. I’m using the i586 version 2.27 core 159. It’s on a bare metal machine with two NICs, red (192.168.1.3) and green (192.168.0.86). I have a separate test machine, call it T (192.168.1.15). I also have a web server, call it W (192.168.0.212).
I have a single firewall rule: source is ANY, Destination NAT with Firewall interface automatic, destination 192.168.0.212, Protocol TCP and Destination port 80. I have added the rule and applied changes.
indefinitely. The firewall log shows a DNAT and several FORWARDFW entries to the correct address at 192.168.0.212.
Test 2. On the ipfire machine, from the console, execute wget http://192.168.0.212. The response, as expected, is
Connecting to 192.168.0.212:80…connected.
HTTP request sent, awaiting response… 403 Forbidden
It seems like the forwarding part works based on the FORWARDFW entries, but any response appears to get lost. I suppose I could run tcpdump on the webserver to see if any traffic arrives there.
I’m sure I’m being dumb but having tried again and again, even reinstalling ipfire, I still can’t get it to work. What am I doing wrong, please?
Have you also tested the connections by ping?
Can other computers on the 192.168.0.0 network, connect to 192.168.0.212?
Have you looked for information on the “403 Forbidden” error?
It’s normal for the IPFire machine to be able to access 192.168.0.212:80 without any problem because the IPFire machine exists in the same subnet as the web server (192.168.0.86 - green).
I have a single firewall rule: source is ANY, Destination NAT with Firewall interface automatic, destination 192.168.0.212, Protocol TCP and Destination port 80. I have added the rule and applied changes.
My understanding is that you did make a firewall rule to allow any packets towards 192.168.0.212:80 through the firewall BUT you did not make a forwarding rule to forward packets received by 192.168.1.3:80 towards → 192.168.0.212:80.
I haven’t touched the firewall interface of IPFire for a while so I can’t quite remember how to set this up but yeah, I think that’s the main thing that you’re missing here.
Forward packets received from 192.168.1.3:80 to 192.168.0.212:80
Actually, I think your setup should’ve still worked by configuring a custom network route where packets whose destination is “192.168.0.212” have 192.168.1.3 (your IPFire) as the gateway - this will have to be configured from your 192.168 subnet’s default gateway device. However, this would require additional configuration if you’re looking to be able to access 192.168.0.212:80 from the public internet.
You need to allow the communication between IPFire and the server, so IPFire can itself download from server … I have same but on orange, to download IP blocklists and URL-Filter blocklists .
BR
Trash
Thanks tphz.
Yes, other computers on the 192.168.0 subnet can all connect to 192.168.0.212.
When connecting to the webserver from the firewall computer, the 403 forbidden error is as expected, it confirms that the connection has been made, which is what I want. The problem is that when connecting through the firewall, even though I see DNAT and FORWARDFW log entries, I don’t get the 403 forbidden message, nor the connected message.
Thanks Spherical Umbra.
Without much hope, I added a rule as you suggest: Source 192.168.1.3, Destination NAT, destination 192.168.0.212, protocol TCP and destination port 80. Applied changes. Repeated test 1. Still no connection made, but still the DNAT and FORWARDFW log messages.
Further testing by running tcpdump on the webserver.
When running test 2 (from the ipfire console execute wget http://192.168.0.212)
I see in the tcpdump on the webserver a sequence like this:
firewall → webserver SYN
webserver → firewall SYN-ACK
firewall → webserver ACK
webserver → firewall PUSH
etc.
This is as expected.
When running test 1, (connect through the firewall from T by executing wget http://192.168.1.3)
I see this sequence on the webserver:
firewall → webserver SYN
webserver → firewall SYN-ACK
firewall - > webserver RST
(short delay of 3 seconds, then repeat of above)
Why is the firewall rejecting the webserver response?
So, if I’m interpreting this correctly:
SYN is sent by IPFire and received by webserver;
webserver responds with SYN-ACK
IPFire does not see SYN-ACK, responds with RST (seen on webserver but not on IPFire).
I’ve tried a reinstall - made no difference, so no hidden blocking rules.
On W (192.168.0.212):
dockerhost:/home/gmac # ip route
default via 192.168.0.1 dev eth0 proto dhcp
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
172.20.0.0/16 dev br-eb1275eb7b11 proto kernel scope link src 172.20.0.1 linkdown
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.212
192.168.224.0/20 dev br-2440d7e91cbd proto kernel scope link src 192.168.224.1 linkdown
dockerhost:/home/gmac # ip addr
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: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether a2:23:a1:24:cf:37 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.212/24 brd 192.168.0.255 scope global eth0
valid_lft forever preferred_lft forever
plus a load of virtual interfaces.
The webserver is actually a docker container. I have tried this same setup with a dedicated apache webserver on another machine with the same results, so I don’t think it’s docker related.
Maybe try tshark with the verbose setting turned on to see if that shows anything that currently seems to be missing in the tshark output, ie the actual sending of the RST status.
You were right with your diagnosis of the routing table. The default gateway is 192.168.0.1 but for network 192.168.1.0 the gateway should be 192.168.0.86. Adding the route solved the problem.
Thank you to all for your patience, perseverance and assistance - great help!
Maybe a reinstall would be faster 
