@soner_balci The the request does obviously not come from the internet. Otherwise you should not see a private source IP.

@viragomann Awesome answer! I really appreciate you taking the time and attention to detail, to go through and answer each question. Very helpful! Had thought of and actually made groups after posting, but the time limit for editing had run out when I tried to do so. Makes sense. Q6: Apologize, I wasn't clear, I meant referencing the picture. Source any and inverted on LAN address. Should have specified. Q2: What's been interesting in practice, is although all are on the same rule redirected to 127.0.0.1, some worked and redirected to 127.0.0.1 and others redirected to the static ip on the interface. Therefore those did not work with the firewall wall pass rule specifically for port 53 to 127.0.0.1. I.e. No DNS until 127.0.0.1 was changed to xyz interface address in the pass rule. Prior to changing the pass rule, the interface static IP could be seen in the firewall logs as -p 53 blocked (from a lower separate block rule to 'this firewall') on many of the interfaces, so had to change the pass rule from single host/alias --> 127.0.0.1 to xyz 'address'. Then once change to just the xyz interface address, dns resumed and all worked again. No changes to the lower block rule. Any ideas as to why the explicit redirect to 127.0.0.1 would lead to that result on some interfaces, but others redirected specifically to the static ip of the interface? Anything to do with resolver functionality? edit: When I went back and didn't have it as an inverted rule, but rather * (any) for destination, it redirected to 127.0.0.1 as expected. I'll not delete and leave the above though, for anyone that might experience the same with the inverted rule. Thank you again for your time and great detailed answer above!

@steveits Thank you Steve, that explanation makes perfect sense. I never realised it could mess up my setup but I learned the hard way, it took me two full days of troubleshooting, wiping the MacBook and rebuilding its setup before it dawned on me that it came down to my silly mistake. Oh well. At least it broadened my understanding of the way it works.

Hi, I had upnp working behind a private ip using CE 2.6.0. All I had to do was to add an outbound NAT mapping with static port. Now it's not working in 23.01. [image: 1681565817086-screenshot-2023-04-15-153535-resized.png]

@jimp Interesting, yeah I dug through the PHP for it a bit but I'm no expert when it comes to coding so couldn't find a reference to why it would have picked that. Just seems odd to me since it's a higher IP address than the VLAN it's bound to, and it's a VIP, so doesn't really make sense for it to be picked. I'll see if I can find more info on it purely because I'm curious.

Final reply: I could not find a way to make this work. The IPSec client was not able to make use of the port forwarding and Outbound NAT rules. The replies form the RDP server never reached the IPSec client. Disabling the firewall with pfctl -d did not make this work either, so i suppose it is some kind of system rule that cannot be overridden (i.e. "do not forward port forwarding replies to IPSec interface". My solution: Port forwarding from the firewall that seperates VLAN1 and VLAN2 to the RDP Server Outbound NAT rule for RDP with the LAN IP address of the pfSense. IPSec client connects to the RDP port / IP address of the Firewall that separates the VLANs. RDP Server sees the pfSense as Origin and replies accordingly pfSense sends packets back to the client with the IP address of the firewall Request and reply have the same IP address (of the firewall) -> connection established This is not my prefered solution, but after three days i am out of ideas. I am sure there is a more elegant way.

@steveits I found the Firewall Auto Rule Order I don't know what Alias Native is. [image: 1680551376108-apeolos-1.png] this is what I see on the drop down. I wouldn't know how to create my own rules.

@sdugoten I assume, that's an OpenVPN client. So go to its settings and set a check at "Don't pull routes". Most VPN providers push the default route to the clients.

@suporte-speedtech Up

@msibyte https://docs.netgate.com/pfsense/en/latest/nat/reflection.html "NAT reflection refers to the ability to access external services from the internal network using the external (usually public) IP address, the same as if the client were on the Internet." NAT + Proxy is one method to do this. It has nothing to do with access from the Internet, that is just plain old NAT.

@urbnsr And no real reason for a vip with a reverse proxy, just have it listen on the IP of pfsense on that vlan on port X, and backend is your destination be that the same port X or a different port, etc.

@johnpoz figured it out. It was as stupid thing I did to try to remember the public IPs I had given the virtual networks. I set them up as virtual IPs and labeled them Do Not Use thinking it would just be a place holder that would not matter unless I created a NAT policy with them. But, apparently it does matter. After I deleted those virtual IPs, all traffic came back and web access resumed. I'm an idiot. Thanks for your assistance!

Nevermind, I've worked out what's going on. That firewall rule is catching all dns traffic not just the redirected traffic. It had me confused for a while!

@viragomann Perfect, thank you!

The answer is yes and no. No: If you only have 1 public IP address because your OpenVPN will be on the same Public IP as your assets such as a webserver. Yes: If you have 2 Public IPs and the assets you are trying to access are not on the same public IP as your OpenVPN server.

@johnpoz Thanks for the answers.

Thanks Steve! Finally got the right option. Had to use NAT + Proxy.