@johnpoz exactly i can access my services either using their local lan ip or using ddns (nat reflection) when using nat+proxy but not when using pure nat. i have read that pure nat is better than nat+proxy and i would also need it once netgate fix this issue: (https://redmine.pfsense.org/issues/7727) and those are the two reason why i need and want to use pure nat.

That's a limitation in miniupnpd itself, as far as I'm aware they haven't added a way to disable that check. They added some related things to help pf use specific addresses to work around it, but it still won't let you use a private address directly on the WAN. Need to raise the issue again with miniupnp and see if they will add a daemon or config file option to disable that check.

The issue was due to blocking private networks on the WAN interface. I disabled the Block private network under Reserved networks and everything is working as expected now. [image: 1614599407044-a65ef545-6a79-43ba-89c9-88644af1e737-image.png]  Hope this helps anyone else that experiences a similar problem.

To update this post: I have upgraded Netgate SG-3100 to newly released v.21.02-p1 and also upgraded the unbound package to the unbound-1.13.1 with: pkg upgrade -fy unbound; pfSsh.php playback svc restart unbound Unfortunately, all the NAT issue came back again. HAProxy does not respond to HTTPS port from outside the LAN network, and Xbox NAT status changed to closed again even though both using the same port forwarding settings that I had in the previous version 2.4.5p1. I have reloaded v.2.4.5p1 again with the same port forwarding setting, and everything started working again. Xbox NAT status is Open, and HAProxy correctly working from WAN.

local proxy server needs to be on a different subnet for nat to work.

@sweety Is there a typo here? This feels like a trick question These are not really in the same category. Please google what is NAT. Please google what is OpenVPN.

@skysurf76 Official response from Ubisoft on their forums...."Hey there, thanks for getting in touch! I'm sorry that you are running into this issue. Due to technological limitations two players are only able to play from the same network if one of them invites the other. Please keep in mind that you will have to complete port forwarding to the system that is the host, although I imagine you've already done so. Here's an FAQ with the ports, just in case. Alternatively you both can play if you get invited to groups by people outside of the local network. " Their explanation doesn't make any sense. They took their xboxes to their dads and it magically worked fine, unless the kids did something different with their sequencing as to how they grouped up. I'll interrogate them soon.

@ta2oo The packets shown in these captures are all marked as retransmissions. That is a typical indication for enabled checksum offloading on Proxmox / KVM. But maybe there is another basically wrong configuration network in your virtual network. Are there also issues with other network protocols?

All depends on what your doing, what your serving, etc. Both methods are valid - you can get some security behind a reverse proxy like HAproxy.. But its normally easy to just forward based on IP than having to deal with the headers, etc. But with using a proxy you can also do some really neat stuff as well..

@cool_corona said in 10 port forwards.... one is not working.: all is fine for now. Other then horrible exposure of rdp to the public internet via a port forward ;)