Why do you have 1.2.3.4 identified as floating ip external in one capture and 1.2.3.6 identified as primary CARP IP in the other. What is the difference? What is what?

I would check that MAC addresses on the ping traffic are sourcing from where they should be and not being ping-ponged around out there. I would double-check all netmasks of all the hosts/interfaces out on WAN.

Do this:

Diagnostics > Test Port

Select the destination server, TCP, and a port the destination server is listening on.

Do the test sourcing from the WAN interface address and the WAN CARP VIP. Does it work for both?

Thanks for the responses, problem solved!

@KOM
Thanks for the info on the Floating Rules. I hoped it could have been used to handle rules for both directions. As I mentioned in the second post it's been disabled.

"Also, you shouldn't have a WAN rule that allows all traffic. WAN should be locked down except for NATs."
Normally I fully agree and that's how our main firewall is set. For this case as I mentioned in the OP security isn't a concern on the pf initially because it is all behind our main firewall. The clock vendor's docs are short on reliable details. Priority is to get full functionality to the NAT'ed clocks then start locking it down.

@chpalmer
Virtual IP was the missing link. In the OP I mentioned a Checkpoint mindset might be throwing me off. In CP the Virt IP is made for you when the NAT is assigned. I added the virtual IPs and all tests work now. Thanks!

@derelict

No, We have to postpone it.as we are new in it so. by the way thanks again Sir.Thank you so so much for your kind support and help.

Thanks!!

Thank you so much.. Let me try this ...

@netblues said in Outbound NAT Issue - VPNWAN:

What kind of vpn?

OpenVPN

Why were you checking outbound nat when you have a vpn?

Because the Troubleshooting guide recommended checking it when the other steps succeeded but pinging 8.8.8.8 failed.

What is the exact config. Does vpn accept traffic from a single ip or the whole lan? (without nat). Is it a managed service or just a host you are using somewhere?

It is a managed service. All traffic from the LAN is tunneled through it.

Did the successful test run through the vpn or the firewall has local access?

That is a good question, I'm not sure. I know that "curl http://www.google.com" worked fine from the firewall, but I don't know if it was going out over the regular WAN or the VPN tunnel.

Did you try just restarting the vpn client?

Well I didn't try that on its own. But I did reboot the whole firewall a couple of times, which would have included restarting the VPN client of course.

What if the vpn server had an outage?

Nope that wasn't the issue because I could use the VPN just fine from my cell phone over its LTE network. Both the WAN and VPNWAN were shown as Online and with healthy RTT and RTTsd values.

Also, thanks for taking an interest! I sort of suspect the issue will arise again at some point, since it seemed to occur randomly in the first place, so I'm happy to take ideas of things to look at or try if/when it does break down again.

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.