@Jaritura Thank you for your reply! I replicated the settings from my former pfsense box to the new one and confirmed with what you said above. Im still missing something. On both systems I Pure NAT, Enable NAT Reflection 1:1, and Enable automatic outbound NAT for Reflection selected. Firewall -> Rules -> WAN has the required ports forwarded IPV4 TCP/UDP * * Server IP 80 * none Firewall -> NAT ->Port Forward the same required ports are forwarded WAN TCP/UDP * * WAN address 80 Server IP 80 Firewall -> NAT -> Outbound I have both set to Automatic outbound NAT rule generation mode along with two Mappings for each subnet: WAN "Network subnet" * * 500 WAN address * (Not sure why this is here? Not knowingly using IPSec) WAN "Network subnet" * * * WAN address * Neither is using a DNS Resolver

@patient0 I’d run into/posted this a while back and it was driving me nuts. Good to hear FreeBSD fixed it. Or accounted for it.

@jliolios Got it, got it. Alright, this all makes much more sense now. Foundational understandings: 1.) When you assign pfSense's GUI (called the webConfigurator) a port, it listens on all interfaces, including both WAN and LAN. Since most people never 'open' this port to inbound connections on the WAN interface, it typically never presents a conflict or a problem that the webConfigurator's nginx-based web server listens on all interfaces by default. (See this post for a recent thread on this point.) 2.) You have both: 'Opened' port 9443 on the WAN interface; and Crafted a NAT rule to forward any/all inbound 9443-destined traffic arriving on the WAN interface, to be 'redirected' to the EZProxy host that I'm assuming is not homed to 172.16.0.1 3.) At some later point, you changed the webConfigurator's listening port to 9443. It would not have been readily apparent at that time that inbound 9443-destined traffic arriving on the WAN interface now had two potential and conflicting routes to take: the webConfigurator webserver, and the EZProxy LAN host. With all that being said, and returning to your original question, what do you mean when you've said: [in Use of a custom port for admin console caused issue with NAT using same port:] in this case 443 took a back seat to 9443

@mcfly9 yep, that is what you need, together with DNS64, I do use the standard NAT64 prefix. In the pfSense doc it's mentioned to enable PRE64 in the router advertisment. It does work for me without it. pfSense doc: NAT64 ... pfsense ignoring the first 96 bits of the destination IP address ... The NAT64 prefix is not ignored but the whole is translated and the information (src, dst & port) is keep since pfSense gotta know where to send the return traffic.

Never mind, I figured it out via the firewall rules.

@SteveITS I haven't tried disabling or removing Outbound rules, but it's worth a shot. I'm not sure it would make a difference, but stranger things have happened and it's quick'n'easy to test. Outbound is just directing traffic to the gateways (ISP or VPN, depending on the VLAN). I'll test my loopback theory too.

@Bob.Dig Yes, of course. "First match wins" is also applied to port forwardings and outbound NAT rules.

Edit the IDRAC network settings, and set a static IP.

@Pagi So I guss, the NAT address changed to the WAN address. Set it to LAN3 address and it should do, what you want.

UPDATE: I now recommend absolutely to avoid ULAs (fd:: and fc:: due to RFC 6724) it seems that those specific subnets will usually prioritise IPv4 traffic and other oddities so you can absolutely use them for special use cases but for a LAN or a dual stack setup I recommend the other f000::/4 subnets which work because they're not official ULAs (so I guess I want them to be that way now).

@alexanderjh said in Issue with local Ubuntu VPN behind PFsense: this is really tricky with UDP. The thing is, I use the pfSense Openvn server, that uses the default UDP and default 1194 port. I don't know anything about "IPSEC" and "strongwan". What protocol number it is, if it uses ports, etc Keep mind that your issue isn't pfSense related right now. Here : proof : [image: 1758006997553-20acf017-6cdd-4194-925f-e19a72353f95-image.png] your VPN traffic never even reaches the pfSense WAN port. It can't redirect what it didn't receive ^^ That said (example) : if IPSEC is using IPv4 and UDP, and port '45000' as a destination. Your rules do work fine for traffic with destination port 80 and 443, TCP, IPv4 - the web server traffic.

@jimp Ok , thanks)))

@netblues Can you Post you Setup?

@sho1sho1sho1 nothing in the resolver would or could do that.. You running pfblocker? Show the rule in your ruleset. There is this feed in pfblocker [image: 1755628936429-pfblocker.jpg] That sure doesn't even look like a NS ;; QUESTION SECTION: ;4.64.4.64.in-addr.arpa. IN PTR ;; ANSWER SECTION: 4.64.4.64.in-addr.arpa. 28800 IN PTR wnpgmb0273w-dr09-v924.mts.net. And it doesn't even answer dns, atleast not from me. That is a bell canada IP.. Is that who you use for ISP?

@johnpoz -Yep-that worked just fine Jonpoz. TYVM.