[SOLVED] Simple NAT setup issues

[opnhkr]

I'm migrating from a PFsense FW over to OPNsense (24.1. and having issues with inbound NAT on the OPN FW.

Both the PF and OPN FWss are currently set up, each directly connected to my ISP's modem, and each assigned a static, Internet-addressible IP with a /29 mask.

I have a LAN with a private 192.x.x.x/24 client which works fine for outbound if I set the default GW to either FW.

I have a separate Internet-connected client that I'm using to test NAT connectivity.

I've set up NAT rules on both FWs to redirect port 80 to a LAN host. Connectivity works on the PF FW but not on the OPN.

I'll attach logs and NAT rule setups from both systems below. Connection to the OPN FW times out ("ERR_CONNECTION_TIMED_OUT").

Any ideas on where I should look?

OPNsense FW logs:

Code: [Select]

Interface Time Source Destination Proto Label
LAN 2024-06-06T13:02:37-04:00 xx.xx.xx.xx:59221 192.168.100.201:80 tcp let out anything from firewall host itself
WAN 2024-06-06T13:02:37-04:00 xx.xx.xx.xx:59221 192.168.100.201:80 tcp NAT test
WAN 2024-06-06T13:02:37-04:00 xx.xx.xx.xx:59221 yy.yy.yy.yy:80 tcp rdr rule
LAN 2024-06-06T13:02:37-04:00 xx.xx.xx.xx:59218 192.168.100.201:80 tcp let out anything from firewall host itself
WAN 2024-06-06T13:02:37-04:00 xx.xx.xx.xx:59218 192.168.100.201:80 tcp NAT test
WAN 2024-06-06T13:02:37-04:00 xx.xx.xx.xx:59218 yy.yy.yy.yy:80 tcp rdr rule
LAN 2024-06-06T13:02:37-04:00 xx.xx.xx.xx:59219 192.168.100.201:80 tcp let out anything from firewall host itself
WAN 2024-06-06T13:02:37-04:00 xx.xx.xx.xx:59219 192.168.100.201:80 tcp NAT test
WAN 2024-06-06T13:02:37-04:00 xx.xx.xx.xx:59219 yy.yy.yy.yy:80 tcp rdr rule
xx.xx.xx.xx = IP of the remote client
yy.yy.yy.yy = IP of my OPN FW

PFsense logs:

Code: [Select]

Time Interface Source   Destination Protocol
Jun 6 11:38:59 WAN   xx.xx.xx.xx:58057   192.168.100.201:80 TCP:SEC
Jun 6 11:38:59 WAN   xx.xx.xx.xx:58056   192.168.100.201:80 TCP:SEC


OPNsense NAT rule:


PFsense NAT rule:

[Monviech (Cedrik)]

When you are DNATing Port 80, you have to remove it from the OPNsense WebGUI. Same if you DNAT 443.

Go to System - Settings - Administration and Enable the checkbox for HTTP Redirect - Disable web GUI redirect rule.to free port 80.

Or use a different port for NAT tests.

Check with

Code: [Select]

sockstat -l
which ports are bound to the OPNsense.

[opnhkr]

I just tried the same config but to a SMTP server on my LAN.

Code: [Select]

sockstat -l does not report port 25 as being bound on the OPNsense FW.

Attempting to connect to the server from the internet client yields this on the client:

Code: [Select]

Connecting To xx.xx.xx.xx...Could not open connection to the host, on port 25: Connect failed
and the OPN FW logs display:

Code: [Select]

Interface Time Source Destination Proto Label
LAN 2024-06-06T16:26:30-04:00 44.220.3.160:53703 192.168.100.30:25 tcp let out anything from firewall host itself
WAN 2024-06-06T16:26:30-04:00 44.220.3.160:53703 192.168.100.30:25 tcp NAT test to SMTP
I am able to confirm the host is listening from a LAN client.

Code: [Select]

Trying 192.168.100.30...
Connected to xxxxx.local.
Escape character is '^]'.
220 xxxxx.xxxxx.com ESMTP Postfix
^C
quit
Connection closed by foreign host.
Repeating the config on my PFsense FW, I am able to connect from the internet client as well.

Code: [Select]

220 xxxxx.xxxxx.com ESMTP Postfix

[Monviech (Cedrik)]

Does the client you test it with have the right default gateway set for each of these tests?

If you test NAT on pfsense the gateway is the pfsense.
If you test NAT from the OPNsense the gateway is the opnsense.

Best create two seperate networks and dont put both firewalls into the same vlan internally. Create the same parallel infrastructure without overlap (internally). Thats the best way to test things.

[opnhkr]

Thank you, @Monviech

The client I was testing with is not on my local network - it's on a separate internet-connected subnet. However, you're 100% correct that it was a gateway issue.

The server was still set to use the PFsense FW as the gateway. I mistakingly assumed the server's response packets would follow the same path out as they were received (through the OPN FW). But the responses were apparently being routed through the PFsense FW which had no knowledge of the NAT going on.

Thanks again for the helpful response.

[Monviech (Cedrik)]

Glad you could solve it. Have fun with the OPNsense