@owlbear Which type of VPN is it?

@enicolau I was able to solve it by using bitnat in the config, such that point b does the nat of c for a

@jasonharper Could you send me an example print please?

@darkmatter5 yeah 20.x is a horrible choice for a network on your local network be it docker or not.. Use another 10/24 network that doesn't overlap with your current network, or use other rfc1918 space other than 10, 172.16/12 or 192.168/16 has plenty of space to be used. How exactly do you have your docker setup, normally dockers get natted to the hosts IP. If you setup non natted network for your dockers, this network would need to be viable on the actual network its connected to. This would need to be just another L3 running on the same L2, or a vlan.. With a vlan being a better choice..

@shaz1300 said in Need some help with a NAT config: Follow up on this, there is an extra rule that needs doing that will force any outbound traffic from the device on the IP192.168.1.1 that goes out of the WAN on the firewall to be NATed to have the same x.x.x.30/29 address as was forwarded to it inbound. I am correct in thinking this is an outbound NAT rule on Hybrid mode and setting the interface as the WAN, the source as the subnet the device is on, in this case 192.168.1.0/24, the destination as any and the NAT address as x.x.x.30? Yes. You didn't mention before. You can do this with an outbound NAT rule. If you want it to be applied to the single IP only you can specify this with a /32 mask. However, best practice instead of adding an inbound and an outbound NAT rule is setting a 1:1 rule on WAN. This does both in one. However, it doesn't allow any traffic. For passing inbound traffic you will have to add a firewall rule to WAN and use the internal IP of your device as destination.

@steveits thanks Steve but I was wrong, or more likely misread and understood Netgate's usecase for reflection, well all would work until there's some filtering going on the destination host, which is the case with my scenario Anyhow the issue is resolved with the assistance of reddit To sum it up if anybody else comes with similar scenario: Old checkpoint fw is bound neither to interfaces or direction, only source and destination, for all the rules, firewall and nat, so just 1:1 NAT on checkpoint did everything regardless of interfaces. When i fully realized that and tsg-tsg mentioning 1:1 i added 1:1 on the specified VLAN interface and that’s it, and no reflection after that since that would again NAT everything to pfSense VLAN interface IP and stopped at dns01 named.conf because of allowed transfer hosts anyhow this is pfctl exact rules binat on bce3.40 inet from 10.5.0.11 to 10.5.0.12 → 112.82.112.164 binat on bce3.40 inet from 10.5.0.12 to 10.5.0.11 → 112.82.112.165

Couldn't make BigBlueButton work behind pfsense/opnsense with 1:1 NAT + Reflection etc., so I gave up on that approach. I still found a solution assigning the second public IP directly to the BBB VM, which I documented here: https://serverfault.com/questions/1121061/assigned-second-public-ip-to-vm-from-outside-not-reachable/1121266#1121266

@derelict That was it, your point 2. Thanks

@viragomann I thought about DNS queries in general, but you already answered :) Will block DoT. Thank you!

@dma_pf said in NAT Translation Breaks DNS: How to route the Localhost DNS request out the VPN interface? localhost would use the routing on your box.. Why would it use your isp dns? Thought you said you were resolving? And not forwarding.. There is no scenario where unbound would ask your isp dns unless you allowed those to be set via dhcp, and you were set to forward. Pfsense itself might ask them, if loopback didn't answer? Ie unbound was down/not working.. If you want to use your vpn dns, then set your default route to go out vpn. Or forward to your vpn dns.. I really don't get what you think having multiple connections to your vpn gets you? Do you actually have multiple wan connections?

@jblackburn yeah a vlan capable switch which can be very cheap and small would make a great addition to your abilities of what you can do and how easy it is to do without having to jump through odd hoops to get something to work ;) Would allow you to bring up any network you want on your pfsense without having to really have lots of interfaces on the pfsense device itself.. Add a AP that can also do vlans - and man you would really be cooking with gas ;)

@steveits I believe mine is set to 300 seconds, but I had let it sit for over a day.

@steveits @johnpoz I'm happy to say that it all worked out. I managed to get the netgate working as it is supposed to with different LAN segments. The netgate WAN port now receives a public IP which makes things a lot more simple as well. I setup WireGuard and am able to make remote connections with the peers I have configured. This thread can be closed :)

@hsv said in NAT Outbound not working: If I switch to "Manual Outbound NAT" I never really understand why anyone would do that - but yeah you can always go back to auto or hybrid mode.. It would really have to be a specific case to not just use hybrid.. All the BS guides out there about switching to manual nat for vpn services don't make a lot of sense since hybrid works just fine for natting to your vpn interface, etc.

@sokonomi so your running sonarr - pretty sure you can change that default 8989 port. Are you running it as docker, you can also set the docker port to be something different and leave sonarr as 8989. As to accessing via just sonarr via some url link, you can set your box to use a search suffix so that just using host would auto do a dns query for whatever your search suffixes are, ie sonarr.yourdomain.tld I never get why this is of concern to so many - so what if the url is http://something.domaint.tld:port - once you create the bookmark, what does it matter just click the bookmark. Unless you were wanting to hand this off to users, and you feel the users are too stupid to understand putting the :port on the end of the url, or you concerned that port would not be available outbound from where they are at, etc. But if you provide more details of what your trying to accomplish we can go over all the different ways to skin that specific cat. but anything via just host name is going to be bad practice - you should always use fqdn when accessing resources.

Ok, thanks to all who looked at this... got in touch with person who was more knowledgeable about the production version of this. There is NAT'ing going on, but it is not at the FW level - its being handled at the router level before the FW. So... that makes my question null/void. I will have to re-examine what I am trying to do and find another way to accomplish it.

@t-sato said in pfSense+Postfix via Port Foward: One interesting thing is I had to select NAT reflect type NAT+Proxy on the mail server related port forward to access from other net. Pure NAT did not work from other LAN interfaces. This does masquerading again, but it is only applied to traffic from inside your network. NAT reflection helps you to access your inside service by requesting its public IP. To avoid the need of NAT reflection, we add host overrides to the internal DNS (maybe DNS resolver on pfSense) and point it to the internal IP of the service. But nice, that you got sorted the outside access without masquerading.

@viragomann [root@centralino ~]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.16.3 0.0.0.0 UG 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 eth0 192.168.16.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 [root@centralino ~]# ip address 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:0c:29:0d:d2:c0 brd ff:ff:ff:ff:ff:ff inet 192.168.16.176/24 brd 192.168.16.255 scope global dynamic eth0 valid_lft 4759sec preferred_lft 4759sec inet6 fe80::20c:29ff:fe0d:d2c0/64 scope link valid_lft forever preferred_lft forever 192.168.16.1 pfsense1 192.168.16.2 pfsense2 192.168.16.3 carp [image: 1672700334542-91f41c82-520f-4a86-872a-b66361ff8505-image.png]