Also, on the Route Print from the Remote PC you can see the routes created in the route table which will be removed when Netextender disconnects. As we can see when we connect to the SSL VPN the traffic to the Networks is being Natted out correctly.Ĩ.

There should already be a NAT policy auto created to NAT the Traffic out of the WAN IP from the SSL VPN Network, if not create one like below, (Tip if you enable Tunnel All mode on the SSL VPN Client Route Settings and then Disable again it will auto create the NAT policy for you and retain it even after a reboot.)Ħ.

We now need to add the IP addresses to the SSL VPN Services Group VPN Access Networks like on the image on the right,ĥ. Add the Firewall rule from SSLVPN to WAN, in this instance I am using the Group for the IP and the Ping to 9.9.9.9 IP.Ĥ. Setting up the SonicWallġ. Add the Address objects for the required remote IP addresses like below making sure the objects are in SSL VPN Zone, you can then add to a Group.Ģ. Add the individual Objects not the Group to the SSL VPN Client Routes, in this example I have also got the Internal networks added to the routes as we will need to access those via the SSL VPN.ģ. This currently doesn’t work With FQNS only IP address as all the SonicWall is doing is updating your route table on your PC / MAC which won’t support FQDN entries. This Document will show you how to achieve this. Though you could use Tunnel All mode, this isn’t necessary for all other web traffic, it would cause additional overhead on the SonicWall and possibly throughput issues on the remote workers endpoint. In certain scenarios you may need to have certain Public IP addresses forced through the SonicWall SSL VPN due to access to the sites / applications being restricted to your Business Public IP address, this would mean that any remote user would not be able to access the service or application whilst connected to the SSL VPN.

While the original post listed version 10. This document is created based on 6.5 firmware but the procedures are the same with previous versions of SonicOS. The security vendor disclosed in a blog post Friday evening that it 'identified a coordinated attack on its internal systems by highly sophisticated threat actors exploiting probable zero-day vulnerabilities on certain SonicWall secure remote access products.'.

Sonicwall netextender routing issues