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.

Yes, you can set a source IP (or an alias containing several IPs) in either the port forward directly or in the firewall rule filtering traffic forwarded by it. Steve

You sir are my new best freind THANKS SOOOOOOOOO MUCH! :D It was trying to route everything out a Management VLAN at our Provider :) Looks like it also fixed some of our VPN issues and other things. Hope this thread helps someone who may also be in the same situation.

GREAT !!! THANKS !!!

@rico said in DMZ server not getting the internet: Wow, this is a lot of Youtube tabs. And that's exactly the problem. People only replicate what others (oftentimes with shady knowledge) show on YT. They don't read manuals or docs anymore and try to understand how it's working. And the result is a not working config without the slightest cue where to look and how to solve it. @surajitit said in DMZ server not getting the internet: Need help as soon as possible. Really? ASAP is here: https://www.netgate.com/support/