Even if I do go to manual outbound NAT which really was not my intention and go back to Automatic Outbound NAT they are still listed.

When you switch back to Automatic then automatic does what it is supposed to do - it automatically puts these NAT rules in place. That does not create any security hole - they re just helper rules for client app. That is not where the pass/block decision is made.
If, for example, you do not want to allow clients to do anything to port 500 then you can use a firewall rule block that on LAN interfaces.

On pfSense WAN you just need to setup an OpenVPN Remote Access server (probably want (SSL/TLS + User Auth)) with local port 44444.
Add a firewall rule on WAN to pass any traffic to port 44444 - you can limit the source IP addresses if you have any idea what public IP address/es the incoming connects wil come from.
If the public IP that is forwarded in to pfSense WAN is dynamic then you need to use a dynamic DNS provider and set that up also in pfSense so that it keeps a public name pointing at your current public IP address.
Then install OpenVPN client on the remote PC…

Yes it's kind of hard to allow access without the proper firewall rule on the correct interface.  Glad to hear you got it working.

Your problem is probably that 10.0.0.0/8 and 10.71.73.0/24 are conflicting networks.

Nothing special needs to be done to SIP over OpenVPN.  There's usually no NAT so it's easy.

I've just solved a similar issue with 2.2. I use the pfSense facility to restrict access to UPnP by ip, only allowing devices that need it access. A device on my LAN that was configured to use UPnP, but not authorised in pfSense, went into a loop sending request after request until the pfSense state table filled up. At that point the Alix succumbed.

In my case it was a QNAP NAS and the answer was to turn off UPnP on it (I wasn't using it anyway).

But I know for sure this scenario was not an issue in 2.1, so something in 2.2 has changed behaviour. As jimp says, miniupnpd in 2.2 is not necessarily at fault, changes to make it "more correct" may be exposing hidden issues in the QNAP implementation.

Another way to find the offending device is to look in your state tables, you'll soon spot it.

I don't believe I am double NAT. My pfsense is connected to a verizon router that is placed in bridge mode with everything else disabled.

Also, I have enabled remote access, and every time I test it Plex says it can't connect as well as trying from outside my network.

EDIT

I think  I know what the problem is. I have a netgear router that is my PIA VPN router, and the media server is directed at that. Going to try some things and check back.

Thank you

@pernils:

(And sorry for using your thread but it sort of the same topic)…

No prob bro, just wish someone would help my desperate ass ;)

Removed all NAT rules and associated firewall rules and rebooted the system. Then I created only the 2 rules for 1122->22 and 4949->4949 again, now it works! The configuration is still the same as on the screenshots I have attached in the first post. So I guess it's solved now  8)

WAN=10.0.3.2

Do you have Block private networks unchecked in Interfaces - WAN?

You just configure the NAT in the P2 of the IPsec connection and it'll work as you describe.

Where does outbound NAT come into play here at all? Should be no NAT involved with v6.

Some Windows services will either fail, or are in an unsupported configuration, if you disable IPv6. I recall some complaining about recent MS Exchange versions for instance will encounter problems if you disable IPv6 even if you aren't using it and Microsoft's stance is that isn't a supported configuration. But that doesn't mean you need to be using ULA either. Having it enabled strictly with link-local addresses suffices there. And it doesn't introduce other potential complications.

Strange issue.

Your VIPs looks well.

Only thing I'm missing is your WAN gateway IP. Usually this is the lowest IP in the subnet except the network address, but this is the WAN address in your case.

Slight update on my end, made a mistake when checking the version it seems it didn't work on 2.2.2 for me. Rolled back to 2.1.5 and it is working fine for me now on both configuration.

I want to configure my webserver with an external ip address connected to the pfsense box is that possible? I want to disable NAT on that interface so I can configure my server with an external ip address

Okay sorted it out.. wow.

I think this is what helped me. https://forum.pfsense.org/index.php?topic=57970.0.

I am running a OpenVPN Server as well as Client, and the OpenVPN wizard adds a rule. This rule matches $OpenVPN ( not sure what that device actually is), and it matches the packet. the problem is that the rule with the reply-to isn't in there.

So I had to edit the wizard created to rule to match the $OpenVPN network.

550 interfaces?  Into 1 pfsense box?  So pfsense is going to be core router for that many networks?  That you need to firewall between?  Im with dok on rethinking the design, I would think there should be a downstream layer3 switch you have all the 550 networks on..  Pfsense would really only have 1 interface then, your transit network..  Sure it could nat all of them.. But now its just a listing in your outbound nat..

How about some details of what you are trying to accomplish, and we can discuss best way to handle it.. Do these 550 interfaces need inbound fowards, how many public IPs do you have?  Do you need to firewall between these 550 networks?

You keep saying when you put the other firewall in place it works.  pfSense and that firewall have the same inside IP address right?  And the default gateway of your server is pointed at that ONE address right?

Post CURRENT screen shots of:

Firewall > NAT, Port Forward tab

Firewall > NAT, 1:1 tab

Firewall > Rules, WAN tab

Don't make any changes, just post them.

@Derelict:

Create a VIP on LAN for 53.53.53.53.

https://doc.pfsense.org/index.php/What_are_Virtual_IP_Addresses

Not quite sure how any other hosts on your network will know to send traffic for 53.53.53.53 to pfSense but I guess that's your problem.

Assuming that's their default gateway, they'll send all off-subnet traffic there. If it's not their default gateway, adding a VIP won't help since the LAN hosts won't ever ARP that IP. Don't add a VIP. The rule as specified will work, with one caveat - source NAT on LAN is required if the source of the traffic is also on LAN2, as the target server will reply directly back to the source client with the wrong source IP, breaking the TCP connection. The source NAT ensures the reply goes back through the firewall, where it's translated back to the 53.53.53.53 IP so the connection isn't broken.

Did you actually read at least the quoted part!? 1:1 NAT already sends all traffic to the configured host/subnet. Set up the 1:1 NAT and move on! (In fact,  you are overriding the 1:1 NAT with port forwards, and screwing things up.)

And this is exactly why people should post screenshots of their FW/NAT/etc. rules…