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

@bjd223 said in Can I Use VPN To Expose Service Through Double NAT: I guess if you could route only the Emby traffic/machine over the VPN that would be more ideal I am just not familiar if you can do that on pfSense. But you asked in the pfSens forum so... and yes, it is possible.

@mvmatch see my edit of last post with a little drawing - maybe that will help you understand that ISP can use internal rfc1918 space without a nat..

@gulzoa712 That's what your NAT rule does. Any source, meaning the internet, on port 80 goes to your internal address of 192.168.15.213 on port 80.

@belalalali well that would come down most likely to what you resolve the fqdn of this webserver your trying to access. If you resolve host.domain.tld to the IP that is accessible via the tunnel - then yes the traffic would go down the tunnel. If you resolve host.domain.tld to the public IP then the traffic would go out via your normal internet connection.

@sbrews said in More NAT help/seeking knowledge: it has to be done this way. Company Politics/Polices and optimal networking rarely see eye to eye ;) heheh

For those replied /tried to help/point me in the right direction - thank you. Going to have to put this on the back burner as I have been banging on this for a couple weeks now with no progress. The network people at my 4 letter place are not familiar with pfsense... and are busy with other things. This is/was a pet project for me - trying to duplicate a piece of our physical environment in virtual box so I can test/experiment with things without impact on the physical environment.

@rafaelvilelacosta94 Again, 40.x and 50.x are not private ranges. Moving on from that, you would do something like this for your openvpn rules- action/proto/src/srcport/dest/destport pass * 40.40.20.0/24 * 192.168.42.xy z block * 40.40.20.0/24 * * * pass * 50.50.10.0/24 * LAN subnet * etc... with xy being the ip of the server and z being the port(s) they need to access.

@viragomann Sorry for the delayed response. I sorted the issue, but I digress. I was trying to access the WAN1 address and was checking if port forward was working from a network which by default was given to another physical firewall which blocks access. I tried testing the WAN1 port forward using another outside network, and it works fine. I should have troubleshooted this quite early. But hey, I'm glad it's sorted. Thanks for helping out, everything you told is accurate and helped me figure this issue out. Now I have allowed VLAN access from WAN2 (physical firewall) to WAN1 (virtual firewall) and I am able to access port forward from LAN of WAN2. Cheers!

@khensu said in Same Device in two Subnets: But somehow a lot of people probably dont even know what a IP Address is and just want it to magically work. Agree - grandma beth, not saying the discovery is not useful.. What I am saying - what do you think that discovery discovers - the IP.. Just let the user put it in!! Other solution is when you want to use those devices, just put your phone/tablet on that vlan - change to that ssid. I'm not a fan of setting up vlans, and then just breaking that boundary by sending multicast across that boundary.. ;) Or setup avahi - I have gone over it a few times myself on how to troubleshoot it. Let me see if can dig up last time.. https://forum.netgate.com/post/1016923 here is troubleshooting it https://forum.netgate.com/topic/166642/mdns-struggles/11

@pfsensor666 The server addresses the response packets back the the client IP, which is 10.0.2.6. So the server will direct the response to his default gateway, FW2. To instruct FW2 to direct the packet destined for 10.0.2.6 to FW1 you need a static route, otherwise it will send the packet even to its default gateway. Instead of a static route you can also masquerade the traffic on FW1 by an outbound NAT rule. Which means the source IP in request packets gets replaced by the firewalls interface IP. But doing this, the server will see the access coming from 162.168.1.1 instead of the real clients IP.