Arkwright All-Knowing Sage ✭✭✭✭
Reactions
Comments
-
Look at Network tab in web developer tools.
-
Translated destination should be "Original" because you aren't translating the destination, right? I.e. the destination is already correct when the client sends the packet. It does seem a bit unusual to be NATing between clients and a server in this kind of arrangement. We would never NAT our clients to the server we host…
-
Your source subnet should be X0 not X2, because the X0 network is where the traffic of interest is originating from, right?
-
RFC 4638.
-
There's an RFC for this [can't remember the number off the top of my head] but SonicOS does not support it, so you're stuck with 1492.
-
If I was right, then it's by accident! I had no idea that would actually be the fix when I suggested it.
-
Firewall cannot do this by itself. The closest it comes is to generate alerts when network probes are failing but by that point it's probably too late in terms of user experience.
-
Losing internet access [however briefly] because some random IP tried to bring up a tunnel is not the expected behaviour. There must be something else going on here, or a bug in that version. We generally don't bother tying down IPsec to known site-site IPs [although that's almost certainly best practise] so I see this…
-
I think you're missing a lack of support for the configuration you're attempting :) I can't see how a /32 mask would work on anything other than a PPP link? Biggest mask SonicOS supports is /31.
-
Change the firewall's HTTPS management port from 443 to something else.
-
Typically all logged in SSLVPN sessions immediately disconnect. End users can reconnect to the SSLVPN, but will nearly immediately get disconnected when they begin to send traffic over the tunnel. Yes, we've had this.
-
Loopback NAT is not "obvious" but once you follow the pattern in that KB article it will work, from internal. If you cannot get the simple inbound NAT working to that IP but you can to others then I suggest you double-check everything. Don't expect ping to a NATed IP to work if you haven't included in the services you're…
-
I'm not able to deploy DPI-SSL to all computers and they are many You need to make sure you are only applying DPI-SSL to the computers you are able to install the certificate on. In the scenario you have described, it is not possible to work around the issue by changing the type of certificate.
-
However in checking a few of those IP's and usernames, it doesn't match what we're seeing right now Ditto. None of the IPs or usernames in that list match a sample of what I found on customer firewalls. I think hoping for an exhaustive list is wishful thinking :(
-
So the inbound NAT would be just the same as the .100. IPs and you should be able to get that working the same way, right? IF you want the public reachable from the inside, you need a loopback NAT policy: