Sonicwall Netextender connects but fails to pass traffic

can I double check you have put in the firewall rule to allow the traffic?
vpn > lan
all vpn clients >LAN ip addrs > allow ?

Hi Ben,

If it is handing out the IP you should be passing traffic.

Where is your DHCP located?
Are you using Tunnel All Mode or Split Tunnel?
Make sure your Client Routes are setup correctly.

Go under Users > Local groups, ensure that the relevant user group is a member of the “SSLVPN Services” group:

Under Users > Local groups, ensure that “SSLVPN Services” group has VPN access to LAN Subnets. In case it doesn't have such access click on configure button for "SSL VPN Services" group and go to VPN Access tab.
Add LAN Subnets to Access List.

Go to SSL VPN>Client Settings and then to Network>Interfaces and check if the Net Extender IP range is the same as on the interface to which it is related to (X0 in example).

In Network>Interfaces click "Add Interface" and configure it with a different range of IP addresses.

Go to SSL VPN>Client Settings  and change interface to the created virtual interface from above and modify the NetExtender Start and End IP to the range for that interface.

Now Test it by reconnect to SSL VPN using Net Extender.
IP address from new range should be assigned.
Open a command line and try ping any device in LAN from a PC connected via NetExtender - you should receive a response.

Let me know how it goes!

Thanks diverse. I did some other testing before you posted this that might conflict.  So the current siautaion is:

ssl vpn ip rage: 192.168.50.2-100
ssl vpn dns: 192.168.55.10 (valid)

Connecting from a client I can ping the sslvpn interface X4 @ 192.168.50.101 and any host on the Lan interface (or my core switches VLan1) of 128.128.1.0
I cannot ping any host on any other subnet in my VLANs address group witch includes: 192.168.51.0, 192.168.52.0, 192.168.55.0.

The VLAns address group was added to the list under Users> local users for SSLVPN services access.

As a test I removed the VLANs entry and added my servers vlan entry.  Cannot ping.

This is setup for the tunnel all mode, and my DHCP is not handling the SSL VPN scope.. the sonicwall is setup to dole those IP's out.  Which I just discovered.. my client is missing a DGW on the NetExtender interface.  Maybe thats a problem.

sorry I'll repeat my one I think it got over looked
can I double check you have put in the firewall rule to allow the traffic?
 vpn > lan
 all vpn clients >LAN ip addrs > allow ?
let me make it more complicated..
Sonicwall as least my NSA 5600 units, add in firewall rules as default to the interface VPN and my LAN (interface 1x)
that default rule says allow all traffic from VPN to LAN subnets.
(so what you are experiencing is what has happened "Connecting from a client I can ping the sslvpn interface X4 @ 192.168.50.101 and any host on the Lan interface (or my core switches VLan1) of 128.128.1.0")
This is grate if you use your NSA as a router too so it knows of your entire internal subnet ranges.
if like me you don't then the NSA will only know about the range you have put on the "LAN" interface there by only allowing traffic between your LAN subnet and VPN clients.
(again " I can ping the sslvpn interface X4 @ 192.168.50.101 and any host on the Lan interface")
so if you add a rule allowing all VPN DHCP clients to all internal addresses you will then have coms.
I have 2 address object 1 called VPN clients contains the address range the VPN clients  get when connecting, the other is called "internal clients" that contains all subnets on my network I use super subnetting so I don't have a massive list.

No sadly we do use our Sonicwall as a router internally. (not my choice).. However my sonicwall does have address object for every subnet we have.  Looking under the Firewall settings I have rules for the following:

LAN > SSLVPN (for all subnets including X4 Subnet and X0 Subnet, also Any)
SSLVPN > LAN (same as above)

I tried it this way as a last ditch effort after having an address group of VLANS that encompassed all of those that did not work as well.