Single NetExtender profile for both external access and WLAN zone
NoLuckCanuck Newbie ✭
in SSL VPN
Is it possible to configure SonicWall/SonicWave so that NetExtender clients can connect using a single server profile while either external or connected to WLAN via SonicWave?
Connection profile using “remote.domainname.com:4433” works fine while external but will not find server while on WLAN Zone. Creating a second connection profile using the WLAN interface IP “192.168.168.1” does work.
Is there some way to configure the SonicWall to redirect/resolve “remote.domainname.com” to the interface IP so htat users dont have to select a particular profile based on their location (WAN vs WLAN) ?
Category: SSL VPN
Hey! You will be signed out in 60 seconds due to inactivity. Click here to continue using the site.
This can be called 'hairpin SSLVPN' and comes down to a few things.
What does 'remote.domainname.com' resolve to when internal? It should resolve to the correct WAN public IP.
Do you have SSLVPN enabled on the WLAN zone? It should be.
Finally ensure there is a rule allowing traffic from the WLAN zone to the WAN zone allowing access to the WAN public IP on the SSLVPN port.
That's how I've done it.
Thanks for the reply TKWITS
Remote.domainname.com does resolve to the correct public IP bound to the WAN interface.
SSLVPN is enabled on the WLAN zone. Create a NetExtender profile using the WLAN interface IP address (192.168.168.1:4433) and it works fine.
Default rule WLAN > WAN = Allow is present
Well, I’m stumped. I must be missing something, but as far as I can tell everything seems to be configured correctly but it just wont work. Is there a specific NAT policy that needs to be created for the hairpin function to work?
I did open a case with support yesterday. No response so far.
You do not use a NetExtender profile that uses the WLAN interface address.
The default rule is not sufficient.
I think you may have misunderstood my comment. Creating a NetExtender profile that points to the WLAN interface IP was for testing purposes only and that does work. Also, editing the Windows host file to resolve the WLAN interface IP of 192.168.168.1 to remote.domainname.com works, but is not a solution as it would just reverse the problem when attempting to connect from outside the organization.
"The default rule is not sufficient' What rule needs to be created to allow the hairpin to function?