Mobile SSL VPN users blocked when trying to access resources behind SNAT

VPN
1

See Edit 3 for solution.

Hello. I have spent several hours troubleshooting this issue, and am at my wits end.

To start. I have a Policy that I call “reverseProxy”. The type is just a custom type targeting ports 80 and 443 on UDP and TCP. It is From: Any, and To: an SNAT External → ‘internal IP’.

All users, whether internal or external, are redirected successfully on this policy. However, I am trying to set up the SSL VPN, and the SSL VPN users are not redirected. They are instead blocked by “internal policy”. Using the Policy Checker in the Web UI told me that it would be classified as a Spoof Attack. I tried to do it again to get a screenshot, but now it just says:

Policy Checker cannot complete the requested search at this time. Verify that your search parameters were entered correctly and try again.

I have no idea how to modify the policies to allow VPN users access to server behind the SNAT. The VPN policy allows To Any, and the SNAT policy allows From Any. Any help would be appreciated, I’ve been going in circles and am losing my mind.

I did try to change the VPN settings from Routed to Bridged, but unfortunately that is not an option as Bridged is not compatible with OpenVPN clients like we are using on Andriod devices.

Here is a screenshot of my policies: https://i.imgur.com/jojoAUA.png

Edit: I restarted the Watchguard which enabled me to get a screenshot of the Policy Checker in action. It’s not telling me that it would be classified as a spoof (I must have fat-fingered the IP when testing earlier). You can see that on the VPN network it’s not redirecting to the NAT IP, but when I test with an IP coming from the WifiNetwork interface then it is redirected properly.

1251×853 33.3 KB

Edit 2: I grabbed a screenshot of the Traffic Monitor log. This one does say spoofing again. I really have no idea what’s going on anymore, but this is the only message that gets generated. https://i.imgur.com/qcNFJFm.png

Edit 3: Finally stumbled across the fix. The SNAT was configured with the interface “External”. All I had to do was change that to “Any-External” and it started working correctly. Thanks to everyone for their help.

2

Need screen shot of traffic monitor when attempting

3

To test your SSL/VPN you should be able to go to https://[ip]:443/ssl_vpn.html - if you are proxying the firewalls port 443 to an internal IP then SSL/VPN cannot do its job.

4

Disabling spoofing might work in a pinch. It shows spoofing because the packet originated from the firebox since it’s a virtual IP, but the firebox doesn’t own that IP. Try adding a separate loop back policy. There are support documents on how to set it up. Basically it goes From: VPN subnet (like 192.168.114.0/24) To: setup an SNAT just like you have, then add in the Advanced options for the policy a different public Source IP. Turn on logging for the policy, move the new policy above the existing SNAT if it doesn’t automatically go there. Don’t use ANY for port range, just the ports you need. This may help it auto-order above the others. I may not be explaining it perfectly, but I really think this is the right path.

5

Done. It’s in my edit now but here is a direct link: https://i.imgur.com/qcNFJFm.png

6

I forgot to add that I moved the VPN to port 444 to accommodate this when setting up. The clients able to connect to the VPN, they just cannot access the server behind the SNAT once connected.

7

So basically like this: NAT Loopback and Static NAT (SNAT)

Except in the From field I enter the VPN network range like 192.168.114.0/24?

8

Is “vpn client ip” the ip range your specify on your sslvpn range?

Because ip spoofing is when the firewall is seeing traffic coming through an interface with a subnet that the firewall doesn’t expect.

You have any weird Nats or anything?

9

And you created an IP pool for the VPN clients to use that is not part of your internal IP scheme and then gave the users access to that IP in the allowed network resource? The trace shows port 443, not 444 which is what the traffic should be arriving on.

10

Yup. Then if it doesn’t work right away look at the log to make sure it’s using this new policy.

11

I mean the easy answer is to disable ip spoofing if you want it to work now, and then get a ticket going out maybe you figure it out soon

12

That raises a good question. The VPN clients do have an IP scheme that is difference from my internal scheme, and they are set to be allowed all network resources.

However, I am tracing with port 443, as the users are accessing an HTTPS resource over the VPN. Should I be tracing port 444 in that case? The VPN is port 444 but the HTTPS resource behind the SNAT is part 443.

13

It doesn’t look like it made a difference. I realized a lot of stuff wasn’t being logged, so I turned on more logs and took a screenshot. ReverseProxy-00 is the original, ReverseProxy.1-00 is the one I made with your suggestion. https://i.imgur.com/DH2F7sK.png

Same problem with the policy tester. It says it is allowed and the ReverseProxy policy is applied, but the Source and Destiination NAT IP never changes.

I also briefly disabled spoof protection, it made no difference.

14

Yes, the IP is the first IP in the range (x.x.x.2).
I don’t think I have any weird NATs. The VPN clients, wifi network, and DMZ are all different NATs, but that’s pretty standard I assume.

Is there a way I can disable IP spoofing to see if that makes a difference?

15

When you access this NAT from internal IPs, not vpn, what does the traffic log show?

16


Edit: replaced link as the original had some IP info I forgot to mask.