How to get port forwarding working

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.

Test 1. On T, execute wget http://192.168.1.3. The response is

Connecting to 192.168.1.3:80…

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.

I’m still stumped.

Thanks Trash Trash.

Not really understanding your suggestion, I tried adding a rule as you suggested:

Repeating test 1 gives the same result as before, DNAT and FORWARDFW log entries in the firewall but no connection made.

Any other thoughts?

Maybe your problem here is the in-host firewall of the machine hosting the web server? Can you take a look at the web server’s access-logs?

At this point, it’s hard to make progress without being able to find out where exactly the packets are getting dropped/rejected.

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?

:thinking: :thinking: :thinking: I think so…

In your case, for acces to W (192.168.0.212) from RED network

1.This rule is not needed


I suggest delete it.

  1. The rule below should work

  1. Host W (192.168.0.212) must accept connections from RED subnet.
    (or accept connections from single hosts in RED subnet)

If I am wrong , someone please correct me.

Thanks tphz.

I now have a single rule again as follows:

I still get the same behavior.

For some reason the firewall is rejecting the response from the webserver (see above tcpdump sequences).

Hi @gmac

The RST is IPFire indicating that it found something incorrect in the TCP communication.

Try running the IPFire addon tshark to see if you can get more details on what leads up to IPFire sending an RST.

:thinking: Is it possible that Ipfire “remembered” some blocking rule?

Running tshark on IPFire and tcpdump on webserver simultaneously:

IPFire
140 19.806640457 192.168.1.15 → 192.168.0.212 TCP 74 57272 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=3179574787 TSecr=0 WS=128
151 20.832710390 192.168.1.15 → 192.168.0.212 TCP 74 [TCP Retransmission] 57272 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=3179575818 TSecr=0 WS=128
164 22.848525482 192.168.1.15 → 192.168.0.212 TCP 74 [TCP Retransmission] 57272 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=3179577834 TSecr=0 WS=128

Webserver
7 28.381402 192.168.1.15 → 192.168.0.212 TCP 74 57272 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=3179574787 TSecr=0 WS=128
8 28.381494 192.168.0.212 → 192.168.1.15 TCP 74 80 → 57272 [SYN, ACK] Seq=0 Ack=1 Win=65160 Len=0 MSS=1460 SACK_PERM=1 TSval=35118886 TSecr=3179574787 WS=128
9 28.381767 192.168.1.15 → 192.168.0.212 TCP 60 57272 → 80 [RST] Seq=1 Win=0 Len=0
10 29.407277 192.168.1.15 → 192.168.0.212 TCP 74 [TCP Retransmission] 57272 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=3179575818 TSecr=0 WS=128
11 29.407347 192.168.0.212 → 192.168.1.15 TCP 74 [TCP Previous segment not captured] [TCP Port numbers reused] 80 → 57272 [SYN, ACK] Seq=16028964 Ack=1 Win=65160 Len=0 MSS=1460 SACK_PERM=1 TSval=35119912 TSecr=3179575818 WS=128
12 29.407668 192.168.1.15 → 192.168.0.212 TCP 60 57272 → 80 [RST] Seq=1 Win=0 Len=0
13 31.423050 192.168.1.15 → 192.168.0.212 TCP 74 [TCP Retransmission] 57272 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 SACK_PERM=1 TSval=3179577834 TSecr=0 WS=128
14 31.423108 192.168.0.212 → 192.168.1.15 TCP 74 [TCP Previous segment not captured] [TCP Port numbers reused] 80 → 57272 [SYN, ACK] Seq=47525249 Ack=1 Win=65160 Len=0 MSS=1460 SACK_PERM=1 TSval=35121928 TSecr=3179577834 WS=128
15 31.423369 192.168.1.15 → 192.168.0.212 TCP 60 57272 → 80 [RST] Seq=1 Win=0 Len=0

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).

Doesn’t seem to make sense to me.

Thanks tphz.

I’ve dumped iptables on IPFire but cannot see any “hidden” blocking rule. Doesn’t mean I didn’t miss something though. I’ll have another look.

I’ll have another look.

:thinking: Maybe a reinstall would be faster :face_with_hand_over_mouth: :wink:

Could you show: subnet mask, default gateway, routing table, on W (192.168.0.212)?

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.

:thinking: I think so…

On W (192.168.0.212) default gateway is 192.168.0.1

but for network 192.168.1.0 gateway should be 192.168.0.86

Could you please try add routing on W (192.168.0.212)

for example
ip route add 192.168.1.0/24 via 192.168.0.86 dev eth0

and check access from 192.168.1.15 to W (192.168.0.212) again.

If I am wrong , someone please correct me.

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.

Thanks tphz.

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!

1 Like