Hello DM, and thank you for choosing JUSTANSWER.com
About your network.....can you provide a simple Network Map?
Showing ALL the network devices....the ports they use, IP address's, VLAN's, server designations (network related such as DHCP), etc etc
Do your best to show the PHYSICAL Layout as well. But its okay if you can only do a logical drawing.
I await your reply
Sure do....in fact i used to SELL them. Along with Cisco ASA's, and Meraki MX series.
In order to BE ABLE to sell them....you had to go through their training courses and become Technician Assistant, along with the SALES side of it. Specs, and sizing, and cost, and future proofing, and so on and so on.
Adding a Switch to a Network isnt too difficult, ofcourse it matters a bit on the complexity of the network, and where in the network the switch is going in....but overall, a switch is one of the those network devices, that are Set it....and Forget it.
Okay....so the new client switch should be connected to the SonicWall Directly, instead of passing through the Server Switch.
Can that be changed?
Daisy chaining creates an additional POF (point Of Failure). But, if you are unable to change it....we can work with it.
So your SSLVPN clients are terminating on the LAN side....correct?
Okay.....You can leave the connection between Server Switch and Client Switch.....but I urge you to put a connection between Client Switch, and NSA.....Unless I am seeing this already in the diagram in the box labeled Proposed Remote Users (VLAN ID:1)
Is this an actual Networking device? Or are you just showing the location of SSLVPN termination?
So you just need to decide which port your using to connect on the NSA to the new client switch.
From there....remote VPN user traffic is tagged, and sent out that port.
Easier said than done i suppose...EH!
Theres a fwe different ways to do this....im sure....doing the simplest and most efficient is the goal.
You could create a new Vlan, and tag the VPN traffic as it comes in, to that Vlan which is assigned the port which connects to the client switch.
Are you doing ANY segregation of the network traffic? You mentioned VLAN ID1.....but that is the default VLAN which every node uses.
If you want to control the Remote User traffic, then you should probably place it on a different VLAN. This makes it a WHOLE lot easier to control when they are on their own VLAN.
The exact routes that you want the client to be able to use when they connect to the NetExtender VPN gives you complete control over which machines they can connect directly to. routes for SSLVPN users can be individually controlled, or group controlled, and this is assigned in the Users>LocalUsers>Add User or Edit User>VPNSettings Tab.
No Firewall changes needed.
Place remote Users on different VLAN...try to group your remote users together BY the network resources they need, which will help keep the setup simple.
But about your Server switch......will it be connected to BOTH the NSA, and the client Switch simultaneously? Or are you disconnecting the link between server switch and NSA once you have the client switch in place?
Cant edit VLAN's?? What the heck? What gives on that?
Thats how i would do it, with VLAN's.
But its your network....you know it better than me.
The alternative, is to use a subnet.....which would require a router to be the middle man (you only have 1 the NSA) between the server switch and client switch creating MORE traffic for the NSA to process.
Just create a NEW DHCP Pool for the remote users, on a diff subnet, then you can route that subnet as you wish.
Okay.....sorry for the delay.
The firewall isnt used to for that purpose.
If you must keep the network FLAT, then you should use the NETWORK ACCESS RULES.
You can Allow or Deny by IP address, or User, or Network Service.
Heres the link to the instructions
The path is: Access>Rules>Add New Rule
Okay i finally found it.
You need to use the SSL VPN Client Routes to restrict access to the SSL VPN remote users.
The link shows the topic in FULL detail. and is for the version 5.8
Let me know what you think.
Ok, Then...Remote users must be explicitly granted access to network resources on the Users > Local Users or Users > Local Groups pages. When configuring local users or local groups, the VPN Access tab affects the ability of remote clients using GVC connecting to GroupVPN; it also affects remote users using NetExtender, and SSL VPN Virtual Office bookmarks to access network resources. This is new behavior in SonicOS 5.6 and above. To allow GVC, NetExtender, or Virtual Office users to access a network resource, the network address objects or groups must be added to the “allow” list on the VPN Access tab
Editing the LOCAL USERS (You can edit local users from the Users > Local Users screen. ) that are assigned to your IPSec VPN Users, under the VPN Access Tab (The VPN access tab affects the ability of remote clients using GVC, NetExtender, and Virtual Office bookmarks to access network resources.),you can select the INTERFACE you want to allow the VPN users to use.
Thats the simplest I can make it.
See image for VPNA Access showing the interface as selection
Please kindly take a moment to reflect my effort put forth and performance, and RATE me by selecting the STARS (or SMILE FACES), so I can be compensated.
Thank you, ***** ***** a Great Night!