I think I have discovered a bug with NAT and firewall

[cookiemonster]

So you come calling a bug a misconfiguration based on not knowing how the product works; starting the thread without sings of courtesy (not even a Hello), not thanking anyone but finding a way to have a side dig at someone who took time out to try to help you (one of the most knowledgeable networking gurus out there).
Nice.

[chall88]

So you come calling a bug a misconfiguration based on not knowing how the product works; starting the thread without sings of courtesy (not even a Hello), not thanking anyone but finding a way to have a side dig at someone who took time out to try to help you (one of the most knowledgeable networking gurus out there).
Nice.

One must undo several pre-configurations to NAT http and https without using the firewall bypass mode "pass"

[EricPerl]

You tinkered until you got it working but we still don't really know what went wrong initially.

You probably didn't have to stop listening on WAN. Port forward will have taken precedence (I have ssh on all interfaces).
If you want to port forward 80 and 443 on WAN, it's indeed wise to move the web GUI off of these (At least for SSH, it is unnecessary).
I have no clue how anti-lockout (likely on LAN) could get in the way of WAN port forwards. (here again, I had this in place for my ssh tests).

[chall88]

You tinkered until you got it working but we still don't really know what went wrong initially.

You probably didn't have to stop listening on WAN. Port forward will have taken precedence (I have ssh on all interfaces).
If you want to port forward 80 and 443 on WAN, it's indeed wise to move the web GUI off of these (At least for SSH, it is unnecessary).
I have no clue how anti-lockout (likely on LAN) could get in the way of WAN port forwards. (here again, I had this in place for my ssh tests).

That success also didnt carry over when I replicated those steps at work. I factory reset it and went through the fairly minimal set of steps involved in creating a port forward and it just behaves the same each time. Works with pass, doesn't without

I even had my boss who has been using opnsense since it forked from pfsense attempt it and he couldn't get it to work either. We did manage to load a  config from a different firewall and edit preexisting entries/linked rules and see it work but creating new ones doesn't, so we know the hardware is good. This appears to be some issue with the generation and linking of these things

I found this searching for similar experiences and found this in a bug report thread about opnsense not generating reflective snat/dnat rules properly, which mirrors my experience exactly.

I don't know what to say, I've spent about 10 hours banging my head against the wall on making a portforward that doesn't involve 'pass'. It's really not that complicated or difficult a task, and I feel this is a genuine bug.



https://imgur.com/a/6zghwJK

[Patrick M. Hausen]

Then please provide the exact steps on how to reproduce the bug. Best in an issue on Github. Thanks!

[chall88]

• Factory Reset
• Software Version is Business 24.10.1
  
• Assign WAN to 1 interface DHCP
• Assign Lan to 1 interface static
• Physically connect device with nginx listening port 80 to lan and verify it can ping the gateway
• Move gui to 33400, disable http --> https redirect
• NAT rule WAN 33400 to lan 33400, use pass so it works and you can work from the wider network
• NAT rule TCP in on WAN Address port 9999, out on the ip of the physically connected nginx instance on 80. Use associated rule
• test it by going to http://wanip:9999
• No work
• Delete rule
• Recreate rule using pass
• Works

I dug deeper into this yesterday on the firewall log

For associated rule I see
ingest on wan
Ingest translated on wan
outgest on lan

For pass I see
 ingest on wan
outgest on lan

For state tracking using pfctl -s state
I see SYN:ESTABLISHED on associtated
I see ESTABLISHED:ESTABLISHED on pass

On wireshark, I see no acks for my syns on the tcp handshake. So I think something is off with the reverse flow back out of translation


I've got to run, I can be more thorough with details later on

[Patrick M. Hausen]

• NAT rule WAN 33400 to lan 33400, use pass so it works and you can work from the wider network

Why would you do that instead of creating a firewall rule from:*/* to:WAN address/33400, allow?

• NAT rule TCP in on WAN Address port 9999, out on the ip of the physically connected nginx instance on 80. Use associated rule

I expect this to work with an associated rule and I will take the time to recreate that setup. Tomorrow, probably.

[chall88]

• NAT rule WAN 33400 to lan 33400, use pass so it works and you can work from the wider network

Why would you do that instead of creating a firewall rule from:*/* to:WAN address/33400, allow?

• NAT rule TCP in on WAN Address port 9999, out on the ip of the physically connected nginx instance on 80. Use associated rule

I expect this to work with an associated rule and I will take the time to recreate that setup. Tomorrow, probably.

I got in that habit because i was originally using the webgui as the test for this and moved to an actual external device to rule out any sort of weirdness with local interfaces.

also I forgot to put in the directions, you need to turn off the blocks for private networks on wan