TKWITS Community Legend ✭✭✭✭✭
Reactions
Comments
-
SSLVPN performance unfortunately has regularly degraded over the years. Make sure youre running at least version 8.266 of NetExtender. It's surprising because they went from their own underlying stack to the 'open' WireGuard stack, which many other companies use and don't have the performance problems with it.
-
Open up those access rules to 'Any' traffic. Have you had any progress?
-
I wouldn't NAT only the specified VPN traffic, NAT any traffic from the Palo to anything on the internet with their assigned public IP. Otherwise you'll end up missing something. Same on inbound. Show your Sonicwall access rules for the Palo. Do you know what else is behind the Palo? Double NATd VPNs can be a pain, and…
-
It's not likely the Palo is NATing outbound traffic to the 72.x.x.x address for two reasons: You didnt give them the 72.x.x.x address for their WAN interface; thats not how routing works. What IP did you tell them to use on the Palo WAN interface? Show your Sonicwall NAT rules for the Palo traffic.
-
Generally you want to see packets 'forwarded'. But I cannot tell from your description if the palo traffic is what is leaving. Post sanitized screenshots of the packet details from the packet monitor, and provide a better description of what IP the Palo is using.
-
To answer the questions: The Cloud Providers IP address object should be in the Zone in which it exists (i.e. it's on the Sonicwall's WAN). What you are essentially doing is a port forward, so you'll need Access Rules too. See…
-
Consider the data sheet says DPISSL throughput is 500 Mbps, but has a note saying "Threat Prevention/GatewayAV/Anti-Spyware/IPS throughput measured using industry standard Keysight HTTP performance test tools. Testing done with multiple flows through multiple port pairs. Threat Prevention throughput measured with Gateway…
-
Read the article thoroughly and come back with questions because you are missing the point.
-
Read up on how TCP works. The webservers are replying with RST packets for a reason.
-
This a common setup. You can simply group all the 'external' SSLVPN users under one 'internal' group and require MFA on the group.
-
My guess is the Sonicwall is auto-populating the name based on it knowing the details of the SSLVPN session. To me it sounds like your cleanup of SSO didn't catch everything, but what that is I do not know. It would probably benefit you to restore from a backup.
-
@Arkwright "why would you have a route to a network that the switch already has an IP in, via something else also in the same network?" I have seen this so many times it becomes nauseating when I have to deal with it.
-
My questions were to guide you to the settings you should test with. "Are your SSLVPN clients allowed to connect to the internal interface of the Sonicwall? Are you setting the SSLVPN client DNS as the internal interface of the Sonicwall? Are you setting the SSLVPN client DNS lookup order?"
-
Here's a link that might help. Basically no 'Layer 3 routing' should be performed by the switch in a 'router on a stick' configuration.
-
I hope you are mistyping 192.168.x.x and you are not actually using 172.168.x.x as your internal subnet. I dont know if what you are trying to accomplish is possible but I was trying to guide you to settings that you can test.