Thanks for the quick reply! I can't believe it was that easy, I guess I overlooked those settings!

In case anyone was curious about what my issue was it was indeed the SSH terminal server that wasn't responding. The boiled down version is I am using a layer 3 Cisco router as an async terminal server. Overkill but this is the hardware I had so I'm using it. The gateway was indeed set to the pfSense however apparently because of the configuration I am using with ip alias and vty; routing is enabled. When routing is enabled the Cisco ignores the default-gateway for obvious reasons. The order in which I programmed and tested configuration had me believing the gateway was being used. Ultimately it was Derelict @Derelict on here that got me pointing in the right direction. I was too deep in the forest to see the trees. Once he proposed the foreign subnet and gateway suggestion this made me verify again the route information on the Cisco. This is when I discovered the gateway was no longer the default-gateway despite my running config stating such. I can't recall the forum post on Cisco forums however it was this information that made me realize that I have to run my terminal server in router mode whether I wanted to or not so I setup a static route to point to the pfSense at the gateway. This got things chooching again. Thanks for the help!!!

@johnpoz It's already working. I found this article https://www.netgate.com/docs/pfsense/nat/accessing-port-forwards-from-local-networks.html and use NAT Reflection for now. I will still look at the host override solution. Thanks for your help

@johnpoz thanks for the help man.

You would have to edit the xml file to reflect the interfaces of whatever system you moved it too..

Nat reflection is ALWAYS the worse option to choose.. I don't understand why anyone would ever want to nat reflect.. if host.domain.tld is on the same network next to you - then why would you not just resolve host.domain.tld to that IP.. Why would you ever want to go to the public IP to be reflected back in?? As to forwarding port X to port Y.. That is always a work around in itself to all to go to the same service with the limitation of napt and only 1 public IP, etc. If you want to go to host.domain.tld:port then go there where host.domain.tld resolves to the local IP and not the public ip..

@emammadov said in Using Aliases With NAT Redirect Target IP Will Not Work: I have tested through WAN and it worked. Did you actually test this off your LAN though? If you simply use your WAN's IP address from your LAN that is not an accurate test as pfSense will loopback the connection. The test I do is disconnect my cell phone from the WiFi and use my cell data to make sure the connection works.

Still trying to play with this... I just found that if I disable pfBlockerNG, my NAT-Type goes to Open! I poked at it for a while and began to mess with the list of countries being blocked via GeoIP. I never could figure out what was blocking it. Any guidance would be great.

@Derelict I assumed having gateways defined would allow the network to smartly know the route to take and so having them on the same subnet would work. Literally never had to think about subnets until this week. To test, I ended up doing all my Lan stuff on 10.25.1.x instead with a Xen Private Network. Once all the VM's worked, downloaded the configuration from pfSense and did a search replace on the rules before 'restoring' the xml file and swapping the modem cables over. Got the home network running on a virtual pfSense okay at the moment, bare a few weird dns issues with kube-dns and dns resolution from pods. This will make it easier to move to a physical machine once ready. Just hope Xen doesn't crash at all.

Happens all the time. I am not putting any weight into the addresses in the diagram. But yeah. If they want to talk to 25, then put the hosts they need to talk to in 25.

That should of been addressed by your client and your AP as well. For example unifi release firmware back in oct 2017 to address 3.9.3 anything above should be fine. But sure being able to leave the vpn on makes it simple.

Open states will stay open. They will need to be closed, expired, or otherwise killed/reset to point to the new server.

It was something in the setup process. I'll look at it again sometime.

@derelict https://puu.sh/BGisz/cf24c96a73.png WAN up https://puu.sh/BGisc/2fcf7bcb35.png WAN down

I figured it out! My Fios router was blocking the ports. I put my pfsense router's ip into the DMZ on the fios router and all port rules forwarding worked!

Here in the UK that's exactlky how I have this setup at home. VLAN over a LAGG group to a switch. The VLAN is untagged at the switch and connected to a VDSL2 "modem". The PPP session runs over the VLAN to the modem, v6 comes up using dhvpv6 over the pppoe session. The "modem" device is in fact a Huawei router in bridge modem supplied that way and locked by default. Steve

@jimp Thanks, it seems to be a rules of Snort (that I have deleted) that cause problem. I'll try to reboot the system. EDIT: I have solved according to this guide: https://forum.netgate.com/topic/119115/block-snort2c-hosts-blocking-http-traffic-for-lan-clients/2

Using Flowroute's host routing (no SIP registration / routing), I apparently needed to enable Ans Call Without Reg in the section Proxy and Registration on the SPA8000 trunks (on lines, if I were routing to individual lines) in question. Inbound calls are now working as expected.