Messages

• 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

• 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

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

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"

Your easy test is to access the web GUI from WAN by redirecting to an internal proxy that pointed back at the web GUI on LAN?
I'm not really sure what you were testing but that seems convoluted.

A simple FW rule was sufficient in my case, as expected.

Testing NAT by using NAT to access the gui on wan

Really not that complicated a concept

The proxy those other 4 ports go yo is an nginx proxy for internal lan services. It has nothing at all to do with the web gui aside from using 80 and 443, which seem to have been part of the automagical mess.

Like i said turning off the wan listener, the redirects, and antilockout rule has NAT behaving like it should be now

33400 wouldnt work with just a fw allow on wan

33400 wouldnt work with nat + add associated rule

33400 would work with only nat pass. The same was true of 80 and 443. No work with associated rule, work with pass. Thats when I made this thread and the other guy tried to teach me how to make some rules ...

I have 4 other ports I am NATing to a proxy 80 443 5334 and 5335

The web gui was just my canary in the coal mine, and easy test.

Im my home virtual instance I just shut off the listener for the webgui on wan, and the webgui redirect rules, and disabled the antilockout rules and the nat + create associated rule function seems to work now. I think it was just making a speghetti mess with all the ports I was trying to use because they are all assosciated with webgui redirect and lockout things.... just automagically populated stuff in the way looking like a bug

The anti-lockout setting creates a FW rule (allowing 22, 80, 443 on self) AND a NAT port forward rule preventing redirection of these ports.
Only on one interface though, LAN or opt1 (or WAN as fallback if no other interface exists).
The easiest way to find which interface is used is to look at FW > NAT > Port Forward.

The ports are adjusted when the web GUI is moved to an alternate port.

I've played with SSH port forward recently (backup install) and since I like to doublecheck with the logs, I enabled FW rule creation (not pass) and logging.
Everything worked as intended, even with the anti-lockout rules which didn't get in the way because they are on LAN.

You're doing HTTPS port forwarding on WAN?

I'll have to double check when I get back into the office tomorrow, it's got to be some kind of tangledness going on with these 22 80 and 443 ports

The way I am accessing the GUI from wan is basically forwarding 33400 wan to 33400 lan with nat set to pass

It's not on the real internet though, it's just in its own VLAN while I'm provisioning it

Move the UI from port 443 to something different and disable the HTTP --> HTTPS redirection for the UI. These are mandatory if you want any public services on HTTP/HTTPS. Also - not entirely sure but I have it that way on all of my systems - disable the global "anti-lockout" function.

The admin guu is living on 33400. But there are automagical redirects and such related to http and https that may be interfering

I will try shutting off the redirects and disable the antilockout rules tommorrow and see if that's whats creating the difference in functionality we're seeing

It does work without "pass". I have it alive and kicking right here. No bug.

Why with a firewall rule for allow port to translated destination can i flip it back and forth between pass and unassociated/associated and watch it break and unbreak?

The only other thing I can think that would be breaking this would be some automagical stuff happening with ports 80 and 443 related to the web GUI, where my NATed traffic destined for lan network ips is essentially getting hijacked

It works with pass, it doesnt work without

If you set the NAT rule to "pass" that overrides any firewall rule you might have. NAT before firewall ...

So change that to associated or not associated firewall rule (or "none", this is all just about single step creation of rules) and then create a rule like I outlined.

I honestly just learned a couple of weeks ago. This is not broken but a real POLA violation - to that I agree.

That's where I started. That doesn't work. The only way to make it work is to use pass. Im not asking for help in making firewall rules or nat rules, im trying to report a bug.

Yeah I had pretty much intuited that the NAT rules and firewall rules are two seperate rules tables with the translation happening "pre-ingestion"

But I can still set my NAT to pass, and my firewall to block, and it passes the traffic, which tells me it's just bypassing the firewall part.

NAT doesn't seem to care at all about the firewall rules, even when it makes them. It also wont pass the traffic at all until I set the nat rule to pass.

The association seems broken

I could not get NAT to work.

I did eventually get it to work by selecting 'pass' in the NAT rule for the traffic.

The 'add associated firewall rule' and 'none' + manually creating the firewall rule never worked in any of the config permutations I tried. 

What is concerning to me is that when I tell NAT to pass, and firewall to explicitly block, it passes the traffic. Things that are added as 'pass' in NAT rules are not visible in the firewall rules. It seems like there are two seperate firewalls (one not visible in the gui), and they dont care about each other. 

TLDR port forwarding nat does not seem to care AT ALL about what is in the firewall rules table, even if it is the thing that made the rules. Only implicit pass with NAT seems to work.

I tried this on current on both business and community and it's the same behavior

OPNsense 24.7.11_2-amd64
OPNsense 24.10.1-amd64