Check: https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting

Thx, this was one option, but we need to separate the IPSEC for other reasons, too. There is not much effort in upgrade and then encountering the same issues as before (we cannot make sure the same phenomenon is not occuring in later release). The problem here was that the IPSEC tunnel was disabled and shutdown on the pfsense and in the next step, the tunnel was started on the linux system. Nothing wrong so far, we checked all the ipsec status, even shutdown the ipsec service. But the outgoing initial packages were not NATed. After hours of research, the solution was found: The solution is in the UDP protocol, which is connectionless (but not stateless). In the firewall states, the old UDP connection (500:500) was still present from the before-active IPSEC connection and after kicking out this state, a new connection initiated from the linux box was accepted successfully. The useful point came from https://forum.pfsense.org/index.php?topic=45255.60 (having the same issue with SIP UDP states) Thank you all ! Marcus

Issue solved Problem related to SIP ALG in the router which must be disabled. in my case i have a cisco router, so I entred: #no ip nat service sip tcp port 5060 #no ip nat service sip udp port 5060 and everything started working as expected.

@dwasifar: @maus: @jimp: You cannot use 1:1 NAT with dynamic addresses. But what if we think in a different way ? Like running a cron script to detect the public ip addresses of wan ports to see if they changed and auto fresh the NAT rules . The problem is that pfSense has always stressed that all the configuration could be done in webui and very few documents about cli config is touched .  Any docs about it ?    :P You couldn't run that cron job frequently enough.  Even if you set the script to run every five minutes, your connections would still be down an average of 2.5 minutes if the dynamic IP changed.  And who knows what would happen to existing user sessions when that script changed the config on the fly. Can't your ISP provide static IPs? My ISP only provides static IPs in expensive enterprise plan which is not a good deal for my family use .  On the other side, my IPs  refresh exactly every 96 hours ,long enough to treat it as "static" if we could auto fresh the NAT rules wisely and minimize the impact from temporary down connections ,that's why I'm seeking for a work around here  ;)

Hi, just in case you have problems. I just did the setup with a CARP address on wan. 1. Create a NAT Forward for Port 21 to internal IP 2. Create a NAT Forward for passiv Ports. (like 20000 to 20010) to internal IP 3. Add the following lines to vsftpd.conf pasv_enable=YES pasv_address=CARPWANIP pasv_min_port=20000 pasv_max_port=20010 4. Search for listen_ipv6=YES comment this out and add listen=YES If you don't do step 4 you will see on the external FTP client somthing like: ftp> dir 227 Entering Passive Mode (0,0,0,0,78,39). ftp: connect: Connection refused

I'm waiting for that moment like a sun :) I trying to delay replacement of pfSense (most possible with RouterOS or IPfire) as much I can and trying to see would this limitation will be avoided somehow with some new update. pfSense works like a charm - and I really don't want to change it just because of stupid PPTP who is out of my network.

"From inside the office, going to https://server.domain.com does not resolve." Yes it does resolve or server.domain.com:8443 wouldn't work either..  If your service is listening on 8443 then yes you would have to tell your browser to go to that port, not just resolve the fqdn to your internal IP.. dns has zero to do with ports. Simple solution - save a bookmark in your browser to the 8443 url ;)  Other solution be to just do a nat reflection, or setup an internal port forward. Or change this server to listen on 443 ;)  Or setup the server to redirect traffic it sees on 443 to the application on 8443..

Thanks Dwayne. I had a similar issue; on my work computer, while connected to my employer's VPN, any attempts to access my local resources by URL failed; the traffic was redirected to the pfSense login screen instead.  This was close enough to your problem that I thought your link might help me solve the problem, and it did.  NAT reflection was what was needed.

Well then just double nat everything, and what your calling your wan behind pfsense.. Then your router in front of pfsense doesn't have to route.. Just put pfsense in the dmz of that router.. Your isp does not support putting their device in bridge mode?  So pfsense becomes the edge and gets a public IP on its wan?

I would use a VPN for that.

Well that doesn't work because 172.16.0.0/24 is not in the traffic selector. Port forwards translate the destination address, not the source address.

Policy routing setup and seems to be working. I am not sure the NO_WAN_EGRESS is working yet, but I will confirm and tweak today. Thanks again for the assistance.

I forgot to mention, when I point it to each server directly instead of the cluster (say 10.0.0.51 or 10.0.0.52), it still does not work

"10.10.10.1.1024" Sorry but hat is not 11.11.11.20 so why would it be forwarded? Obfuscating address are not going to let us help you..  especially when you change it to be something that clear would not work per your rule.  That IP is from what you stated is your wan gateway IP, not some public IP 11.11.11.20