OPNsense Forum
Archive => 21.7 Legacy Series => Topic started by: swILeZBa on September 25, 2021, 11:19:39 pm
-
Hello,
I think there may be sth wrong with the filter rule association option in Port Forward.
I have a reverse proxy VM that is connected to my intranet through OPNSense. The intranet houses a test web server. If you select add associated filter rule or add unassociated rule when doing a port forward of port 80, it creates a visible uneditable rule in WAN. When I try to test it I can't access the web server. If I create the same port forward as pass then I can. Shouldn't the generated FW rule have the same effect in all 3 cases (unassociated, associated and pass)?
On another note when using add unassociated rule, it creates the rule, but it is not possible to edit it. This seems wrong but would like someone more experienced to verify it.
Thanks.
-
Continuing the conversation from reddit…
Associated filter rules do work - I have several on my WAN - so there is something about your setup that is creating an issue. You probably need to give details of your network config (interfaces, subnets, VLANs) and firewall rules to enable troubleshooting
-
Sure thing Greelan. BTW which version are you using?
My setup (Plan is to have a dual firewall with a DMZ subnet between them that will house the reverse proxy and a mail server)
WAN: 192.168.1.x/24
LAN: 192.168.2.x/24
Nginx Reverse proxy host: 192.168.1.2
OPNSense WAN address: 192.168.1.3
OPNSense LAN address: 192.168.2.2
Web server host: 192.168.2.3 (hosts https://github.com/ondras/my-mind just for testing)
OPNSense settings
System -> Settings -> Administration -> Web GUI
TCP port 4443 (Not a typo, intentionally changed so that there is no clash)
Firewall -> Settings -> Advanced -> Network Address Translation
Reflection for port forwards: Unchecked
Reflection for 1:1: Unchecked
Automatic outbound NAT for reflection: Unchecked
Port forward settings:
Disabled: Unchecked
No RDR (NOT): Unchecked
Interface: WAN
TCP/IP Version: IPv4
Protocol: TCP
Source: Single host or Network, 192.168.1.2/32 Port Range: any
Destination: Single host or Network, 192.168.1.3/32 Port Range: HTTP
Redirect target IP: Single host or Network, 192.168.2.3/32
Pool options: Default
Log enabled
NAT reflection: Use system default (See above)
Now 3 scenarios for Filter rule association
--------------------------------------------------------------------------
Scenario 1a) Add unassociated filter rule
Result: Trying to access 192.168.1.3 from Nginx reverse proxy host. Times out
Scenario 1b) Add associated filter rule
Result: Trying to access 192.168.1.3 from Nginx reverse proxy host. Times out
Scenario 2) Filter rule association: Pass
Result: Trying to access 192.168.1.3 from Nginx reverse proxy host. Can access the mind-map
NB: The reason I use the Nginx rp host is because it is the only host on the 192.168.1.x/24 subnet
--------------------------------------------------------------------------
Thanks for any help
-
Does it make any difference if you specify “WAN address” as the destination in the port forward?
Are you testing from a browser outside the LAN network?
I assume the web server is only listening on port 80.
-
Neither WAN address, neither This Firewall makes any difference.
I am testing from a browser in the WAN network.
Port 80 yes.
I thought that it could be possible that NAT might contribute because it maybe translates between the private networks but again it wouldn't work with Pass then.
Thanks for the interest.
Edit: With my limited understanding I think I have found the solution (https://forum.opnsense.org/index.php?topic=6320.msg26844#msg26844).
To recap there are 2 avenues by which it works for me.
1. Use pass in Filter rule association
2. Use associated/unassociated but you would have to also tick "Disable reply-to on WAN rules" in Firewall -> Settings -> Advanced
Now I don't understand why this makes it work and if someone has a better understanding and wants to fill in the gaps be my guest.
-
Do you have multi WAN?
-
No I do not. Why are you asking?
-
Because the reply to behaviour is most commonly an issue in that setup
-
From the OPNSense documentation: https://docs.opnsense.org/manual/firewall_settings.html#disable-reply-to
What I understand is that if there is Multi-WAN you want this enabled because if a packet comes from WAN1 you want the reply to go to WAN1 instead of WAN2 (at least in the normal case).
Now I do not understand the bridging interface point. Do you? Since the VM's are on Proxmox and I don't have a good grasp of the bridging there too, my use case may be relevant to this point but I don't understand enough to say for sure.