@mvbif Yes, you're right, port forwarding is a DNAT, actually, I was wrong. The thing is, this port forwarding is SNAT-ing too. Nat lonely should not allow anyway traffic not allowed from a security rules. The port forwarding was done and a rule has been added to allow the traffic. Also, the IPSec traffic is allowed via a different rule, so the traffic is allowed. So now i will check but, i feel to say that yes that nat rule will apply only on traffic coming from openvpn and has that destination. Well, this is what should happen. Only traffic coming in via the OpenVPN interface should match. But it doesn't. About the ipsec traffic, are you saying that with nat on, your ipsec host can ping 172.x.x.x , with nat off can't anymore? Yes, that's what I mean. If I exclude the IPSec connected subnet (10.41.13.0/24) from the NAT rule OR I disable the NAT rule, the IPSec traffic cannot go to 172.31.254.100. Btw ipsec should have rules permitting traffic to 10.41.99.65 isn't it? Yes. Also, the thing is, the rule's SNATing too: With the rule in place, 10.41.13.225 for example, can curl 172.31.254.100 and get a reply. On the 10.41.199.65 (the actual IP that the port forwarding rule is set on) I see the traffic coming from 10.41.199.2 (PFSense). Test scenario: Via the IPSec, I'm sending, from 10.41.13.225 a curl 172.31.254.100:2345 (port was chosen so no traffic is going to disturb the test). With the port forwarding rule enabled, I can see traffic on 10.41.199.65, coming from 10.41.199.2 (PFSense IP address) dst port 2345. This clearly matches the traffic. Checking the firewall logs I can see the traffic being allowed from 10.41.13.225 to 10.41.199.65 (translated IP address). This means that PFSense matched the traffic and DNATed via the above rule, but it also SNATed (why?). Disabling the above rule and running the same scenario: curl 172.31.254.100:2345 in the firewall logs I can see the traffic as being allowed from 10.41.13.225 to 172.31.254.100 (not translated) but the traffic doesn't reach the 10.41.199.65 VM (normal, since it was not translated). What's going on?! Also, check this out: states tables filtered by 2345 (dst port): [image: 1740546197177-8710e90a-870d-4772-8d91-8056ab5d502a-image.png] So it sees the traffic as coming from the IPSec interface, but it's SNATing it and then delivering it to 10.41.199.65. I have NO NAT RULES to match this traffic (outgoing on VLAN199 interface) so there should be no SNAT done, from what I can say. There's no NAT rule matching 10.41.13.225 or 10.41.13.0/24 or 10.41.0.0/16. Can't I somehow see what NAT rule is this traffic matching?

@McMurphy Hello, So now seems that at network level the connection is working, Now you should check on apache logs to see if it get's the request, and if there any error about. Connection reset by peer, should be that you reached the server.

@tknospdr Yeah your fine this way - unless you worried about their warning ;) If so you could uncheck it and look into the other option.

Let me see if I can explain my proble... I'm running tailscale in PfSente (in the end that is the main problem). I'm alo running on my network Headscale (a open source self hosted aleternative to pfsense servers) and also a DERP Relay serve self hosted, to use my own replay server and decentrelize from Tailscale servers. DERP Relays servers when configured on Tailscale clients, need to be accessed directly from the public IP, so it can know all the public IP's to rout the traffic. This roules out making split DNS and accessing the DERP server by local IP address... Tried it and it says that the range of ip's is not valid. So I need to access the DERP server making my local service "belive" that the connection is form the public IP. If I access it from outside my home the NAT forwards the traffic and all works OK... When I'm inside my home I need to access it bu the wan interface, and this works with the NAT Refrection, allowing me to access the WAN interface and "follow" the NAT forwarding rules... This works ok to ALL my devices! But PfSense, that also haves a tailscale client installed, does not seems to be following this forwarding rules! When I it tries to access the WAN interface I have a message saying that it was denied, and this only happens in pfsense, all other devices work.

I'm now dealing with the same issue. Still not 2028, but only 3 years shy. I posted a new thread about it as it wasn't until late in the posting process that I realized it may have had something to do with NAT reflection specifically. The rub here is that I am running DNS split horizons and still have my issue. Feel free to answer here or comment on my new thread. Thread here

@SteveITS What I meant by "one type of client device" is the following: The customer has a number of application servers that provide a whole range of services. Their clients have devices that connect to their services. They recently updated their servers to a new major release and it seems the problem is that some clients, running an older version of the client software, were having trouble connecting to the new servers, which it turns out has nothing to do with the port forwarding at all.

@Tiny-0 Repeatedly ran into this and was wasting time trying to re-install and restore config each time, only to have the packages "disappear" again... Is there a Redmine report for this? Does anyone know what the root cause might be?

@johnpoz I understand the logic now. I've added the rule yet, and it works as expected now. [image: 1738307528478-23f9e7e3-9409-40cb-a081-1a46957a3096-image.png] Thanks a lot for your help and patience!

Hi Viragomann, so full disclosure, I installed acme and have a cert then I changed the port on pfsense under Advanced => TCP port then went to dns resolver and used the acme cert for dns records and added the dns name to the IP to resolve the ip to dns name now when I type in the IP or dns it adds the port at the back so trying to remove that port number so it just shows the dns, I have haproxy working work with truenas scale and also a dns record to resolve the IP but this too adds the port number at the end, is there a way I can use the dns without the port number? setting in haproxy maybe? to redirect etc?

@andrew_cb Disabled monitoring, no effect on not passing traffic through NAT.

@ngr2001 Yes 2 PC's 2 different ports... Being COD picked 3191 for external, wouldn't one need to increase their port scope range to what you have listed above? You shouldn't have to... But I'd go ahead and start testing, that's the only way to know for sure. I think if you limit it to 3074-3076 in your ACL, you would see 3074 and one of the other being used instead... You could even try and set one of them to 3074 and the other 3075 only, and see what happens...

@SteveITS said in Port Forward is Ignored: There is also the “don’t block the world, allow your country” discussion which takes much less memory. ^Exactly - I use this method.. I only want US ips and currently Belgium (family living there using my plex) - so I just allow those in my port forwards and wan rules.. This by its very nature blocks all the other ones.. No reason to load up into the tables of bad countries IP of them, all need to load is the IPs that are US and Belgium.

@Gammon I used this guide ones to route out traffic over to a VPN, from pfSense to a VPN ISP.

@CubedRoot 1:1 NAT of multiple IPs to a single backend IP cannot work at all. 1:1 means, that packets addressed to the external IP are forwarded to the internal IP AND outbound traffic from the internal IP is natted to the stated external IP. While the first part might be possible, the second cannot be done. Which external IP should be used for outbound traffic of the single internal? The first, the second, both alternating? You should rather configure port forwarding rules for both external IP. If you also want to use these IPs for outbound traffic from the server set up an outbound NAT rule for it. You can translate it to one of them or to both alternating by adding both to an alias and use it as translation address in round-robin mode.

@Gertjan thx for the explanation. As the problem seems to be related to the php interpreter memory pool and the computer i'm testing on (2sockets - 2 cores of a i7-6700 with 6G of ram) seems pretty weak for the use case i'm trying to to implement. I'm gonna try to see if a can do some test on the server the app will be deploy on. For the firewall related rule, i meant an option in the php script as the goal is to aumotate all the LXC handling process. It works in "pass" mode but i guess it would be better with a firewall rule ? I will give a feedback after some tesing (if they let me play with the big toys :p )

@Bob-Dig Hmm, did you try to only reboot the TS VM? How did you set up network for the VM? Firewall on or off, any extra bridging or VLAN? I have had TeamSpeak running for years without one single problem. But even so, I run two servers on separate machines and use keepalived to manage the master/backup setting... I see now that the other ports are optional, and it's only 9987 required for voice. And it's likely the same port for the chat function so I guess it's time to close the other two...

@marcg said in Should Port Forwards work with Interface Groups?: default NAT reflection policy? Disabled.

@marcg Good info. That makes sense then. It's essentially a DMZ passing through the external IP. Still not sure how both the att router and my pfSense passthrough can have the same IP but I'll chalk it up to magic. In any case, I have it working great now. I can reach my iLO gui if for whatever reason the pfsense goes down, I can reboot or reconfigure it to get everything back up remotely.