Tried to access web GUI from WAN, finally got it working, don't understand why!

[comet]

Today I installed OPNsense and had a weird thing happen that I do not understand.  I currently have a home network that looks like this:

Cable Modem === Asus Router === devices and switches of various types.

In order to configure the device that I installed OPNsense on, I put it behind the Asus Router.  So during install it looked like this:

Cable Modem === Asus Router === OPNsense device === Computer 1.

From Computer 1 I could do the setup, access the web GUI, and basically configure anything.  But what I wanted to do TEMPORARILY was access the OPNsense device from a computer on the WAN side, in other words a computer (Computer 2) also connected to the Asus router.

Cable Modem === Asus Router === OPNsense device
                                         |=== Computer 2

Now on the Asus router there is a checkbox you can use to enable or disable access to its web GUI from the WAN side, but there is no such thing in OPNsense (not that I could find, anyway).  So I tried creating a rule under Firewall: NAT: Port Forward that looked like this:

Disabled   UNCHECKED
No RDR (NOT)   UNCHECKED
Interface   WAN 
TCP/IP Version   IPv4 
Protocol   TCP
Destination / Invert   UNCHECKED
Destination   WAN address
Destination port range   from:   HTTPS    to:    HTTPS
Redirect target IP   Single host or Network   192.168.10.1   (the LAN address of the OPNsense device)
Redirect target port   HTTPS
Pool Options:   Default
Description   (left blank)
Set local tag   (left blank)
Match local tag   (left blank)
No XMLRPC Sync   UNCHECKED
NAT reflection   Use system default
Filter rule association      Add associated filter rule

I clicked SAVE and then applied the changes and it created the rule and also a rule under the Firewall: Rules (WAN tab).  However it did not work; I could not get to the web GUI from Computer 2.  I tried various changes but nothing worked until I changed the very last dropdown, Filter rule association, from Add associated filter rule to Pass.  Then it started working, but I am totally mystified as to why, because doing that completely removed the rule from under the Firewall: Rules (WAN tab).  It also changed the dropdown so that the Add associated filter rule and Add unassociated filter rule options are no longer shown - the only options shown now for Filter rule association are Pass and None.

Now if I go to the Firewall: Rules (WAN tab), no rules are shown.  All it says is, "No interfaces rules are currently defined. All incoming connections on this interface will be blocked until you add a pass rule."  And yet obviously it is allowing incoming connections to the web GUI.  But I don't understand why, and I would really like to understand this because before I put OPNsense in service I'm going to need to create some rules to forward ports to specific devices on the LAN, and if I have to use the Pass option I just want to be sure I'm not creating a security hole (at least not one greater than the normal risk associated with opening a port).  I'm just trying to understand why and how the "Pass" option worked, especially considering that it deleted the associated firewall rule.

EDIT:  Forgot to mention, prior to doing this I had already gone into the WAN settings and unchecked the boxes for "Block private networks" and "Block bogon networks".

Can anyone explain why I had to use the Pass option, and why that worked?  Is there a different way I should have done this?

[franco]

If you choose a pass NAT, traffic is bypassing the filter. If you choose association, the pass rule will be created later, but since your WAN is a private network and block private networks is enabled on WAN only the former works.


Cheers,
Franco

[comet]

Thanks for the response.  So when you say "traffic is bypassing the filter", would that have any unanticipated security issues?  Later on, when I connect the OPNsense device directly to the cable modem, and I need to open ports to an XBOX, would there be any security-related reason I'd want to use something other than pass in that situation?

By the way, under the WAN settings I had previously unchecked "Block private networks" and "Block bogon networks", so I would have thought that would have removed the block on private networks, yet it still wouldn't work until I used pass as the associated filter rule.  I do intend to re-enable those before connecting OPNsense directly to the cable modem.

[comet]

Just an observation:

There are no pages that I can find on Port Forwarding on the OPNsense wiki.

In OPNsense itself, under Firewall: NAT: Port Forward, when you go to add a rule and turn on full help, under "Filter rule association" the only thing it says is this:

NOTE: The "pass" selection does not work properly with Multi-WAN. It will only work on an interface containing the default gateway.

But it does not explain the four options in any way.  Is there anyplace that explains these in some detail?

• None  (I get that this means no filter rule association, but not sure why you'd use it)
• Add associated filter rule
• Add unassociated filter rule  (What is the difference between an associated and an unassociated rule?)
• Pass  (Traffic is bypassing the filter, but are there any security implications in using this?)

EDIT: After posting this I Found this on a pfSense page, don't know if it's the same in OPNsense:

Filter rule association: Choose one of Add an associated filter rule gets updated when the port forward is updated, or Add an unassociated filter rule, or pass which passes all traffic that matches the entry without having a firewall rule at all.

[franco]

Yes, it's the same. If association did not work with block private removed the issue was auto-reply-to to your upstream gateway and your upstream router does not send your reply back internally. For some this works normally even so, for some it doesn't. Disable reply-to from advanced section of manual firewall rule or from the advanced firewall settings altogether.


Cheers,
Franco

[franco]

PS: A Port forward by definition is a tolerated security issue. The default is to go through the additional filter to associated rule, but if you don't want that or something is wrong with this a simple pass is ok too. Not passing the traffic is a POLA violation. We do all we can in the defaults, but it is an uphill battle in terms of security and no easy answer as you can see.  :)


Cheers,
Franco

[comet]

Yes, it's the same. If association did not work with block private removed the issue was auto-reply-to to your upstream gateway and your upstream router does not send your reply back internally. For some this works normally even so, for some it doesn't. Disable reply-to from advanced section of manual firewall rule or from the advanced firewall settings altogether.

Thanks for the replies.  Am I understanding you correctly that part of the issue may be that my WAN is connected to another local network (which will only be the case during configuration) and that this probably would have worked without using PASS if the WAN port was connected directly to the cable modem and I was trying to access the GUI from the Internet?  Not that I would do that; before I connect the WAN port directly to the cable modem I'll be deleting that rule so that the Web GUI can't be accessed from the WAN side at all.

The main reason I'm trying to understand that is that I will be needing to forward some ports from the WAN to a specific device (after the WAN port is connected directly to the cable modem), and if it turns out that using Pass makes those work as they should, I just want to know that it's not a security hole (any more so than forwarding ports in general).  But I won't be able to test to see what works (if anything) and what doesn't in that regard until probably sometime this weekend.

[comet]

PS: A Port forward by definition is a tolerated security issue. The default is to go through the additional filter to associated rule, but if you don't want that or something is wrong with this a simple pass is ok too. Not passing the traffic is a POLA violation. We do all we can in the defaults, but it is an uphill battle in terms of security and no easy answer as you can see.  :)

Thanks again but you've kind of lost me here.  You said, "The default is to go through the additional filter to associated rule", but I'm not sure what you mean by "the additional filter".  Also you totally lost me at "Not passing the traffic is a POLA violation", in part because I have no idea what POLA means.  There is a lot about this stuff that I simply don't get.

[franco]

POLA means principle of least astonishment, commonly used by authors to describe behaviour of user facing interaction.

If one wants to open a port forward and pf Firewall requires two rules (one redirect + one pass) it will fail POLA test if only one of two things is done.

So for that reason the order for using port forwards is:

Default redirect and associated pass rule with additional filtering like bogons and private ranges.

On the other hand, the options for direct pass rule or no automatic passing are given as well.

Default gives you better security, but blocks more for the sake of security like your testing. In real world scenarios this does not matter as previously discussed.

The direct pass gives you normal security in the scope of a port forward.

No association with a manual rule gives you "open" security, the security is as good as you define it. Mistakes in setup are bad obviously, but if you set a good rule and restrict IP ranges of your forwards your security is best.

It really depends.... and btw IDS/IPS will always work despite your choice.


Cheers,
Franco

[comet]

Thank you franco, that makes a lot more sense to me now!  Much appreciated.