@HansSolo said in Port Forwarding Troubleshooting: Early on, one must become acquainted with the Save buttons and which ones need to be used and when. Yeah, wait until you try to use Squidguard and realize that none of your changes will stick until you go back to the General settings tab and click the Apply button at the top, after you have clicked Save at the bottom.

Works perfectly. Thanks!

I removed the bond0 interface and everything seems to be working with the single interface. The 2 ports on the switch was set to 802.3 LAG but I used mode 6 ALB on Centos 7 which did not need 802.3 LAG... I think that was the issue. I am not exactly sure what and how that is breaking the port forwarding though... I'll setup the bond interface once I have everything else configured and for sure working. johnpoz - And what does this have to do with pfsense at all?? You are right, nothing to do with pfsense! Thanks for the troubleshooting tips!

@joelones said in Redirect http on another port for a host override: So what I want to accomplish is the following; I'd like for users on the network, instead of accessing services as [ip:port], to access them as such [MachineName/ServiceName]. I realize this question is old but I found it while looking for something else and this response may help someone else. What you are trying to do is often done with pfSense handling the LAN routing and Nginx or Apache handling the port routing on the local server running your services or apps. In pfSense, services > dns resolver I use host overrides like this (example): Host=test1, Domain=something.com, IP Address=192.168.12.20, Description="Main app/service on this server" Then under "Additional Names for this Host" i have: Host=test1, Domain=something2.com, Description="Main app/service2 on this server" Host=test1, Domain=something3.com, Description="Main app/service3 on this server" This routes LAN request targeting test1.something.com, test1.something2.com and test1.something3.com to 192.168.12.20 server. On that server I have Nginx running (same thing can be done with apache) and routing request to different service ports. Here is a basic example Nginx config for http://test1.something.com and http://www.test1.something.com being routed to a service running on server at 192.168.12.20 on port 3005 on a Ubuntu server. # file /etc/nginx/sites-available/test1.something.com server { listen 80; listen [::]:80; server_name test1.something.com www.test1.something.com; location / { proxy_pass http://127.0.1.1:3005; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection 'upgrade'; proxy_set_header Host $host; proxy_cache_bypass $http_upgrade; } } The firewall on 192.168.12.20 only needs to allow external traffic from port 80 (and 443 if https) and Nginx will route to the appropriate local service port. More information about that can be found Here and Here and Here

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. [image: 1555644917735-actiontec-mi424wr_01.png] [image: 1555644925841-actiontec-mi424wr_02.png] [image: 1555644942526-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.