The problem is probably that the Pi does not have the benefit of pf's reply-to which would automatically route reply traffic from arbitrary addresses back over the VPN.

You best bet is to perform outbound NAT at pfSense so the Pi sees those forwarded SSH connections as sourced from the OpenVPN tunnel address instead of the original source address of the client. It should then be able to route the reply packets properly.

@viragomann Thank you , Will try those options.

Hmm...you cannot set the machine's IP in the software?
Maybe try setting up a Port Forward on the software subnet to the IP of machine/port.

edit: you may need https://docs.netgate.com/pfsense/en/latest/nat/accessing-port-forwards-from-local-networks.html

OK, got it. The Actiontec actually has a set of default rules. You can't get at them, but the string "Blocked - default policy" occasionally turns up in the web view of the logging.

Awkwardly, it allows anything outbound from its immediate LAN, 192.168.1.1/24. So an SMTP server plugged directly into one of the Actiontec's ethernet ports works perfectly fine. Placing it on another internal subnet, though, puts the default stuff in play. From there, this was a downhill run. The screen shots are provided to document the details for the community.
Actiontec mi424wr_01.png
Actiontec mi424wr_02.png
Actiontec mi424wr_03.png

@Derelict very weird indeed, I had clients using it and it's using my internal DNS, so not sure what was going on.

So you have what problem exactly your ddns not resolve publicly? Or you do not have port forwarding setup?

You should prob start your own thread with your details if you want any help... And again its bad idea to open your DVR to the public internet.

Thank you for the reply. We got it working on LAN only for now ( we disabled the NAT rule). Will reply again, once server working on both LAN and WAN.

ubnt@ER-X8a:~$ show upnp2 rules Firewall pin holes pkts bytes target prot opt in out source destination 0 0 ACCEPT udp -- * * 0.0.0.0/0 192.168.1.19 2 udp dpt:9308 1022 249K ACCEPT udp -- * * 0.0.0.0/0 192.168.1.17 3 udp dpt:4965 157 11513 ACCEPT udp -- * * 0.0.0.0/0 192.168.1.17 3 udp dpt:4960 149 9678 ACCEPT udp -- * * 0.0.0.0/0 192.168.1.16 5 udp dpt:4965 159 10532 ACCEPT udp -- * * 0.0.0.0/0 192.168.1.16 5 udp dpt:4960 NAT port forwards pkts bytes target prot opt in out source destination 0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:9308 to:192.168.1.192:9308 0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:4965 to:192.168.1.173:4965 0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:4960 to:192.168.1.173:4960 0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:4966 to:192.168.1.165:4965 0 0 DNAT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:4961 to:192.168.1.165:4960 pkts bytes target prot opt in out source destination 13 728 MASQUERADE udp -- * * 192.168.1.165 0.0.0.0/0 udp spt:4965 masq ports: 4966 13 728 MASQUERADE udp -- * * 192.168.1.165 0.0.0.0/0 udp spt:4960 masq ports: 4961 ubnt@ER-X8a:~$

So the ERX uses the Masquerade ports it auto-generated as the destination port in its port forwarding rules for the clients. Pretty cool.

Yes true but that has ZERO do with AP talking to your controller via L3 adoption.

Once your controller at site A has adopted the AP at remote sites, then you could enable control cloud and remotely mange it.

If you need to troubleshoot port forwarding
https://docs.netgate.com/pfsense/en/latest/nat/port-forward-troubleshooting.html

Just to close this out:

The main problem was that:

From my location, one DNS Service 9.9.9.9 works about 5% of the time from my office, and never from my home. Oddly, their alternate 149.112.112.112 is very reliable, but slow.

Getting ahead of myself earlier, I already had SNORT running, and that was also blocking 1.1.1.1

So, rather than getting some redundancy by using 2 service providers, I was getting close to nothing.

I also had issues with the DNS resolver settings but finally got this sorted out, with everything running over 853 which was the objective there.

The only outstanding question I have is:

On main LAN, a PC (192.168.1.x) gets DNS server default IP of 192.168.1.1 via DHCP and an NSLOOKUP reports the server as "firewall.localdomain" as expected.

Replicating the setup on LAN 2, the PC (192.168.2.x) gets DNS server 192.168.2.1 via DHCP defaults but the NSLOOKUP reports the server as "unknown" - but everything seems to work - Admin WebGUI; servers on LAN; and Internet.

Changing the DHCP Server settings to hand out 192.168.1.1 as the DNS server for LAN2 resolves the issue and PCs on LAN2 show the DNS server name.

I thought the Interface IPs x.x.1.1 & x.x.2.1 as I have them, would behave the same - especially as the default action is to use these for each interface.

Is there an extra step needed for LAN2 to properly identify the DNS server?

Thanks

@e4ch Thank you so much for posting this clear, and now I've understood it, simple solution to a problem I was fighting. Saved me a ton of hair pulling!

Still no answers?

Is it possible to set up a Virtual IP on LAN, which would replace the "third PC" in OP and forward ports from pfsense -> Virtual IP -> destination 192.168.1.10 ?

I tried this with "IP Alias" and "CARP Virtual IP" but port forwarding does not work.

Choose an external port that's considered safe.

But you should really use a VPN to access internal resources, opening such devices to the WAN is pretty stupid.

The OpenMesh APs connect to our internal network and have an internal IP. For the Public/Guest WiFi, it acts as its own DHCP/DNS/Gateway for the clients that connect to the AP. It then only routes traffic from the AP to our pfSense router to get access to the Internet while not allowing access to the internal network.

The Split DNS is not making a difference since the client DNS server is the AP, not the pfSense router. I tried the other options but had all kinds of issues.

I'll take a look at the switches we have (hadn't reviewed them yet since I'm new with this company) and see if maybe I can setup a VLAN for the public WiFi and only allow the VLAN to access the Internet.

Thank you jimp. On my question to them, Molotov TV confirmed to me that they cannot warrant anything if I do not use my ISP's DNS servers. Well: my chosen servers are cloudflare's and Quad9: nothing to do with my ISP.

So I used this setup two or three evenings with, on the pfSense firewall, formarding mode unchecked (off). I could watch TV through the Apple TV and Molotov, everything worked.

To be extra sure, I tried as a last attempt to check again forwarding mode, to return my setup exactly to what it was in the first place when my tests failed. Il should fail as it did before. But it now works beautifully. I double-checked and rebooted the firewall. Still works.

I feel like a fool with my silly questions. Maybe my little 127.0.0.1 DNS server knows it all and no longer need any assistance. Thank you for the reply. It helped a lot, and my Apple TV now works, hopefully with DNS over TLS using Cloudflare and Quad9's DNS servers.

@Grimson said

RTFM: https://docs.netgate.com/pfsense/en/latest/interfaces/interface-settings.html#private-networks

Thankyou Grimson, after Reading The Fine Manual.
I concluded that
since the WAN IF of pfSense router actually does not have a public IP and has a IP Address 192.168.1.253
RFC1-918, I think it is secure from outside attack over internet even after turning off the block Private IP Address and loop back address and this is the proper way to configure and it's not a work around. Please correct me if i'm wrong.
WAN-IF.JPG
RFC-1918.JPG
Thanks

Hello jimp,

thank you very much, the new rule works.
I'll never thought of using outbound rules to change inbound port forwarding.

All the best,
Ivo

I managed to ... sort of solve it.

Netgate support told me to try and put each tunnel on a different internal IP alias.
After doing that (and creating the relative NAT and firewall rules on the border box) the second tunnel got up.

I still have no idea why this is the case exactly, but I'll take the working tunnel over understanding pfsense's IPSec and/or NAT mechanics for now.

https://www.netgate.com/docs/pfsense/nat/forwarding-ports-with-pfsense.html

@samax2207 capture your SIP traffic and analyze it