@jimp I tried to do the same but no error has been received. i think it is fixed but i didn't install any patches to fix this. I don't know how the issue was resolved automatically...Please update....

Why should the thread be closed? You can mark it solved yourself.. Other users might have questions and or comments.. I for one have a comment to the personal insult remark..

If you took that as personal - sorry but your in idiot ;) @Grimson was making a comment to using such an IP range for your internal networks vs using the called for and standard rfc1918 space is pointless.. Such a statement is not making any sort of personal attack.. Its pointing out that your going to shoot yourself in the foot using such a range.. And even called out the fact that it is listed as bogon ;)

As to the current climate of online activity... Some people need freaking stop being 13 year old girls on their first period would be my comment to that ;) Come on people the whole world is not out to get you.. Here is the HARD part about online communication in text - people are HORRIBLE at interpreting tone in text.. So DON'T - take the words at face value.. words to exchange info to HELP YOU!! Using such an IP range is moronic at best... So his phrasing of of don't be an idiot is quite appropriate.. He didn't call you an idiot - he was calling the use of such a range idiotic...

Just kill FTP with 🔥

Well, can you SSH to the tunnel address from the other side? Meaning from the other side's LAN to the other side's tunnel address?

If so, that means sshd is listening on and can receive connections on that address so it should work.

You would want to assign an interface to the OpenVPN instance on the connecting side and set up outbound NAT on OpenVPN for the proper sources to the ssh on the other side.

I don't see any reason that should not work if sshd can receive connections there as described above.

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..