Obviously the IP you deleted on pfSense is routed to another one which is still assigned to pfSense WAN or the ISPs routers ARP table still isn't refreshed.

What we are here for ;)  Glad you got it sorted.. The actual exchange of info is normally the hard part.. Always a piece of the puzzle missing it seems..  To be honest I don't recall an issue with port forwarding that was not actually pebkac.. Not saying there hasn't been any.. But I have been around these forums for a bit, lots of versions of pfsense - lots of posts.. And do not recall a port forwarding issue that was not peback related.. Common issue is traffic isn't even getting to pfsense wan - so how and the F could it forward anything ;)  The hard part is getting the info needed to figure out what the user is missing..

:P Both my LAN and my Opt1 networks are added to the VPN server config…I didn't mention that in my first comment. One of the posts somewhere in this forum suggested to use NAT which didn't make much sense but I thought I might try anyway.  I'm assuming PFSense has a routing table like most routers so my initial thought was that it had to do with the rules.  Thank you for the help anyway. FYI, I was able to find the problem but it was a hardware related error.  Thanks again!

I'm using this setup right now. I set up a ppp connection, with /dev/cuaU0.0  as serial port. apn, phone number, username and password depending on your 3g provider. I associated it with an interface. I created gateway group and set up policy routing like any other dual wan configuration

Sadly, most of those "Bridges" & such sometimes rely on "UPNP" as i currently use Wemo. has an Odd behaviour of my Alexa not Auto Discovering them when they state it can. So i had to use Yonomi as a "Middle Man" to allow them to be Discovered. Odd issue, but a work around has solved this/

PFSense is simply ignoring it!?! No, pfSense is doing what it is being told to do which is apparently incorrect. Or some other issue is keeping it from working. See the above troubleshooting document for a pretty comprehensive list of things to check. And don't just skim them. actually check them all.

@johnpoz: Did you forward the ports from the nat router in front of pfsense?  Pfsense can not forward something that never gets to it.. If you can not figure what your doing wrong - look over the troubleshooting doc.. https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting If your trying to simulate coming from the internet by coming from the wan that is rfc1918.. Your going to have to make sure your uncheck block rfc1918 on the wan interface.. OK I will try it

Here it goes my working Outbound NAT from LAN to LAN: [image: 1531410232636-transferir-resized.png]

Thanks ill take a look! Either they havnt done it, just said they have. Or something is still wrong. Cause the issue remains.

No there is no reason for 2nd pfsense.. Just connect your 2nd wan to the 1st pfsense via a vlan on the wan interface..

@Derelict: Port forwards translate the destination address and/or port. Outbound NAT translates the source address and/or port. It helped me to realize that "Outbound NAT determines how traffic leaving a pfSense system will be translated". That is, "outbound" from the pfSense system - not necessarily "outbound from the network". One can apply Outbound NAT rules to traffic that is "inbound" to the network (including Port Forward traffic).

The primary address is assigned using a PPPoE connection, the other addresses are a block assigned on that subnet. If I setup OpenVPN on the primary, perfect, no issues. If I try and use one of the other addresses, they are VIP's then no go, won't work. Now, I have see other references to this issue on the forum where the solution is to use localhost, assign the VPN to that. Doing that alone still did not work, assigning the VIP to localhost AND assigning OpenVPN to that DOES work. OK, port forward works nicely, replaced the 1:1 rule with that. Edit: Port forward does NOT work, I obviously did not wait long enough for the rules to reload. Setting it back to 1:1 and removing the port forward it's working again.

My guess is this is not a NAT problem but that you may need some incoming firewall rules from your provider to your ATA lan address..

anyone ?

Thank you very much, that was indeed the problem. I thought in the wrong direction, the port on the firewalls side can of course be random as long as on the remote side it hits the 80 / 443.