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

@iulianh Just add them as virtual ips: https://docs.netgate.com/pfsense/en/latest/firewall/virtual-ip-addresses.html

@amartinelli Yes, best practice for a VPN with the purpose of maintain a remote network is to establish a site-to-site VPN on pfSense. This gives you access to pfSense itself and to devices behind it as well. In your Secomea example the device connects to their server, which acts as a relay then. You can do the same with your own VPN server. But this requires that your server has a public IP naturally. The setup of a site-to-site OpenVPN is well described in the pfSense docs: OpenVPN Site-to-Site Configuration Example with SSL/TLS. Or you can also setup a Wireguard with pre-shared keys: WireGuard.

@keylevel There is nothing you can do on your pfSense at all. Even if you do a sort of translation, pfSense would have to route the traffic to 192.168.1.0/24, which it has two gateways for. Hence routing is not possible. The address translation hast to occur on one of the remote sites. So pfSense would see another subnet and could route traffic to it properly.

@natethegreat21 Closing this out and opening a new topic.

solved by add a WAN_IGB0 interface and use it in NAT Outbound. [image: 1670056555355-9b2fcfee-c934-445d-b725-d7da11b2337f-image-resized.png] [image: 1670056599435-66f43f6c-9d85-4177-a228-fc0e29157020-image-resized.png] [image: 1670056514929-784a3a56-3edb-423f-a98d-d4694c7c0e68-image-resized.png]

@viragomann I did some further testing and found that it was pfBlockerNG which was causing the issue. I'll have a look at my settings in it later today. Thanks for your help