As you may have noticed from my last few blog posts I’ve been playing around with a Juniper SA device running in my home test environment. Recently I’ve written about using the WSAM or Virtual Desktop Profiles to ‘redirect’ traffic to an end-user. This posting get’s back to the good old VPN style setup by using a program called Network Connect. This is a client based SSL VPN, that is itself pretty customisable. The Juniper Admin can restrict users on a device, protocol and port basis, as well as using features such as split tunnelling (i.e. access to two or more subnets) as well as bandwidth throttling.
Setting the Network Connect Server address
1) Select network > network connect and ‘entire cluster’ (if the SA’s are in a cluster)
2) Enter the IP address to be used for the network connect server. As specified make sure that the IP address is different from the internal or external addresses already in use by the SA(s)
3) Enter an IP address filter (if required) or leave as *
Enabling Network Connect
1) Select user roles > **role name** > network connect
2) Select the split tunnelling mode preferred.
NB Although it is generally very useful for the client to have access to their local subnet this can also prove a security risk. If the client requires internet access it’s generally best to route this via the Juniper SA devices to a proxy server where the traffic will also be filtered using company policy. However, I realise that sometimes routing both corporate traffic and all other services, whether HTTP or otherwise, can prove very tasking over a slow VPN line. This is where it may be best to allow some kind of split tunnelling rule. I’ll leave it up to you to decide which is best.
3) Select auto-launch network connect
Creating a Network Connect Access list
1) Create a new access policy and give it a relevant name
2) You’ll need to enter the resources that the NC clients will have access to. The entry .*.:* will allow access to all protocols, all ports and all ips on the company network. This is generally not a good idea!
Best practise is to manually detail each service, i.e. tcp://myserver.company.local:80 will give NC users access to just HTTP on myserver. This may be continued to include HTTPS and perhaps an ICMP rule to allow for PING to check of the server availability etc. You may find that the resource list grows quite large.
3) Select the role(s) to which this access policy should apply
Defining Network Connect Clients
1) NC clients can be assigned an IP address via an internal company DHCP server or a static address pool. I personally don’t use a DHCP server due to the extra f/w configuration (and in my opinion f/w weakening) so I’d define a static pool. Here you would just enter a list of IP addresses that can be assigned to clients. Each IP address should begin on a new line.
2) Transport encryption modes can be customised to suit. Again I generally go with the highest encryption available (AES256/SHA1), but performance will be hit. A compromise could be made here, especially if users are having to operate on 3G or GPRS.
3) DNS settings can be customised as wished. If the Juniper SAs use different DNS servers or a different DNS domain you’ll need to manually supply the settings here to match those of the internal company network.
4) Set a proxy server (if required).
5) Choose the roles this NC connection profile will apply to.
1) If you are using spilt-tunnelling networks then you’ll need to enter the resources (i.e. the IP range of the company network i.e. 192.168.2.0/255.255.255.0 etc)
2) Select the roles for which this policy will apply
3) Give the policy a meaningful name and save
1) Adjust entries to suit. These can be based on guaranteed and maximum throughput.