Cloud router was blocking traffic between cloud private networks. What exactly is "Cloud router" ? Did you not know such a thing was sitting in between your hosts when you started the troubleshooting?

@webminster so users/devices point to an IP to send mail? Why would you not just use some fqdn, now if you want to move the server it's a single change of the dns record to what the new IP is.

@tinfoilmatt @SteveITS Funny, its solved. I needed to reinstall 2.8.1 on new hardware anyway, imported my config. Guess what, its working now without any other changes.

Hey Guys, Cancel request, problem solved. Solved all with port forwarding.

@sysxtreme That's perfectly fine, I just mentioned in case the AI changed the context of your statements, you don't have to be good at something to make a difference either, your english is perfectly fine. Yes so one of the most fantastic use cases for NAT is translating a subnet to multiple subnets port forwarding and load balancing from the upstream/wans becomes a very easy task. You certainly do not get more than a single prefix usually the norm really is /48 /56 and they become /64 in some cases you may also only get the one /64 you will get but it's fine with NPt/NAT66 you don't even need more than a single IPv6 for most use cases let alone more than a single /64. I would not waste time trying to complain to your telecommunications agency about this because I would really not expect any government to have provisions for customers to get more than "what they need to be reasonably connected to the internet" in a very purposefully ambiguous language anyway which would allows the ISPs flexibility in how they want to connect their customers, most of the government really will not be able to understand the technical differences between deployment models and so they trust the ISPs to just 'make it work'. Yes you can use OSPF internally (technically also BGP) but the usual OSPF deployment consists of point to point links which facilitate inter-router communication and routing so if you have a complex network you can just route things internally via OSPF/BGP and have NAT66/NPt at the upper end. You can also Tier things: WAN ---NAT66 MIDDLE NET ---NAT66 --NAT66 --NAT66 --NAT66 LAN 1 LAN 2 <OSPF> LAN3 <OSPF> LAN4 In this example your LAN 2/3/4 can route to each other via OSPF point to point links without any need for NAT among them but the middle net cannot access them just a WAN wouldn't due to firewalling and the connectivity to the upstream remains due to NAT+GW in this case the WAN router. LAN 1 remains isolated without routes to 2/3/4 but can see anything you port forward to MIDDLE NET and upstream towards WAN. (you may need to disable reply-to and a few other tweaks for this to work but anyway it's just an example). It can be much much more complex than this but all internal subnets can remain within your local IPv6 ranges you don't even need /64 unless you're using that network for an actual LAN with RA/DHCPv6/SLAAC i personally use /96 more often than /64 because i just want the last 2 hextets anyway to match a /16 IPv4. You can also do NPt to your 'middle net' and from there NAT66 as needed you basically have an internal WAN also route traffic to different uplinks effectively increasing the overall internet speed available to you without causing any internal conflict and maintaining the internal routing structure. Unrelated to your question but to other people out there IPv6 can be either "just work" or better than "just work" it really is up to how much you're willing to spend on engineering and designing and it will pay dividend in the future. Hope it satisfied your curiosity.

@mgc6288 Had an opposite problem. NAT reflection: NAT+proxy -> can access from outside, but not from internal network. Changing NAT reflection to pure NAT solved it. Spent all night debugging. Wrote my post here for the pfsense team to take a look.

Internet → WAN:8080 → DNAT → 172.16.10.2:80 → SNAT(outbound hibrido o manual ) → 172.16.10.1 → respuesta tunel OK

WAN/65 -> 41 network id (hex 41 = dec 65) WAN/10 -> 10 network id (hex 10 = dec 16) Typo in the above, I meant: WAN/65 -> 41 network id (hex 41 = dec 65) WAN/16 -> 10 network id (hex 10 = dec 16)

@njc :) here’s a couple

@luckman212 said in Why is there an automatic Outbound NAT for ::1/128: NAT it to the routable V6 interface IP assigned to my ix0 LAN And why would it do that, you have it set on what your calling wan6 it was adding NAT rules for some site to site WG tunnels that I already had static routes for No it wasn't.. Unless you set it like that.. Example - I have an wg interface, only traffic that gets natted to that is traffic I route out that interface [image: 1763396222121-nat.jpg]

@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.