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.

Clear the browsers cache.

The reason is probably that you try to reach your internal servers by their public host names, which could not work. Cause you've forwarded the public IPs only on the WAN interface, not on the internal ones.

Tow ways to resolve:

Set up an internal DNS (split DNS) if you haven't already one and override the public host names with the internal host IPs.

Use NAT reflection. That "reflects" the forwarding rules to the internal interfaces. NAT reflection can be activated in each particular NAT rule or globally in System > Advanced > Firewall & NAT.
For the global set up, at "NAT Reflection mode for port forwards" select "pure NAT" and check "Enable automatic outbound NAT for Reflection". If you want to use the global settings the "NAT reflection" option in the forwarding rule has to be set to "system defaults", which is the default option.

Nevermind…I solved it.
Forgot to enable NAT Reflection from System > Advanced, Firewall/NAT. Seems stable so far.

Wouldn't you be better doing it over an IPsec Tunnel ?

SNMP isn't NAT friendly :-

https://www.ietf.org/rfc/rfc3027.txt

4.8 SNMP

SNMP is a network management protocol based on UDP.  SNMP payload may
  contain IP addresses or may refer IP addresses through an index into
  a table.  As a result, when devices within a private network are
  managed by an external node, SNMP packets transiting a NAT device may
  contain information that is not relevant in external domain.  In some
  cases, as described in [SNMP-ALG], an SNMP ALG may be used to
  transparently convert realm-specific addresses into globally unique
  addresses.  Such an ALG assumes static address mapping and bi-
  directional NAT.  It can only work for the set of data types (textual
  conventions) understood by the SNMP-ALG implementation and for a
  given set of MIB modules.  Furthermore, replacing IP addresses in the
  SNMP payload may lead to communication failures due to changes in
  message size or changes in the lexicographic ordering.

Making SNMP ALGs completely transparent to all management
  applications is not an achievable task.  The ALGs will run into
  problems with SNMPv3 security features, when authentication (and
  optionally privacy) is enabled, unless the ALG has access to security
  keys.  [NAT-ARCH] also hints at potential issues with SNMP management
  via NAT.

Alternately,  SNMP proxies, as defined in [SNMP-APPL], may be used in
  conjunction with NAT to forward SNMP messages to external SNMP
  engines (and vice versa).  SNMP proxies are tailored to the private
  domain context and can hence operate independent of the specific
  managed object types being accessed.  The proxy solution will require
  the external management application to be aware of the proxy
  forwarder and the individual nodes being managed will need to be
  configured to direct their SNMP traffic (notifications and requests)
  to the proxy forwarder.

Also SNMP data isn't encrypted.

That is not how a normal port forward would work, so you must of setup some sort of source nat.

Post up your forwards..

ah now i see where the complication starts…

i have a dns server on the network, its a web hosting platform for lots of domains and uses IIS which uses port 80 and 443. http://myurl.com is on an apache box.

anyways, since i only need to access http://myurl.com:8080 from the host itself every three months (letencrypt ssl renews every 3 months), i just temporarily pointed port 80 to the this ip, and accessed http://myurl.com instead. Then i  generated the ssl certificates and changed it back again.

its working now but quite weird... now i can access both http://myurl.com:8080 and https://myurl.com:8443 from within the host.

thank you for your time i really appreciated it.