If you set the port range from HTTP to HTTPS, it means all port from 80 to 443. In this case you have to set the redirect target port to HTTP. But that would not be what you intend. For your purpose you should add an port alias for HTTP and HTTPS and use this one in the rule. Firewall > Aliases > Ports Give it a name like "HTTP_HTTPS" and add the ports 80 and 443. Then you can use this alias name as custom option at Destination port and Redirect target port.

[Solved] I installed pfsense version 2.3.4 and restore config. Its working

Hi there, Here I am again, one of my remote site with the same scenario. It can ping the WAN but it cannot access the web gui. All are solve but this remote site still cannot acess.

I have never seen nat not update the firewall rules  or reload the filters.. You can look in the log and see the filter reload.

Issue was resolved, the NAT rule was not being created.

That wouldn't be 1:1, just plain outbound NAT (Firewall > NAT, Outbound tab) Switch to hybrid outbound NAT and add rules to do just what you state, for example: Interface: WAN Protocol: Any Source: Network, 192.168.2.0/24 Destination: Any Translation Address: 1.0.0.2 And then repeat that, changing the source network and translation address. You'll need one rule for each pairing.

If the upstream device is just forwarding everything to you then, yes, you can only have one thing on port 80 listening or being forwarded. As far as the pfSense webgui is concerned, you can disable it on port 80 and change the port to whatever you want.

Screenshots

Sorry, this Post can be closed, it was an Pebkac…. I have an backup firewall and I forgot to disable the WAN Interface on this machine after the last update, so the Backup machine grabbed the VirtualIP first.... The gateway is on the production machine and so the firewall blocked the traffic.... Thanks Wolfgang

Circling back to this topic… I appear to have solved it. In case any google-fu gets people here in the future, I won't leave you hanging... The culprit seems to have been my privacy VPN client. I use a paid VPN service and rule based routing to protect every appropriate device inside the network. The PS4 had already been routed through my primary WAN gateway bypassing the VPN client, but apparently that was not enough. My VPN service was inserting a 0.0.0.0/0 default route ahead of the pfSense default route (Diagnostics->Route). The solution was to enable "Don't pull routes" which did not meaningfully impact my rules (all clients were already covered by rule based routing). I didn't spend a ton of time tracking down what part of the party chat / voice chat setup process was getting caught by the inserted default route, but clearly something was. Just make sure your statically assigned PS4 client has a rule to route it through the WAN above whatever privacy VPN rule based default route you have on your LAN connection and you should be good to go.

The VPN provider has to forward a port to the VPN address. You can forward a port to another address on that host (like its address on LAN) but otherwise what you are trying to do is sort of nonsensical. Maybe instead of asking how to forward a port you describe what you want to do instead. There might be another way.

Thought I had tried that but cannot get it to work. Is there an idiots step by step guide to this anywhere? Thanks Stephen

"Normally, I'm NOT using the RDP access, because I use the VPN capabilities of pfSense." So why do you want rdp access?  I hope your restricting it to limited source IPs atleast.. Opening up rdp to the public internet is not something I would suggest from a security point of view.

You'll also need routes to get it work. As you want to see the origin IPs (not NAT) there are routes necessary to direct the packets to the right device. Assuming pfSense is the default gateway for the networks behind it and the firewall in front (10.10.10.2) is the default gateway in 192.168.1.0/24 and on pfSense, you need to add static routes for the network behind pfSense to the front firewall pointing to 10.10.10.1.

It happens automatically as long as the traffic on the target side is matched by the rules on the assigned interface tab and NOT by the rules on the OpenVPN group tab.