The Access Server can enable VPN clients to access private subnets available on the Access Server host. The options for the Should VPN clients have access to private subnets? setting are as follows:
- No: VPN Clients are not allowed to access any private subnet.
- Yes using NAT: VPN Clients can access private subnets, and each VPN Client’s virtual address is transformed via NAT so that the Access Server host’s IP address is used as the source address on client packets destined for private subnets.
- Yes, using routing (advanced): VPN Clients can access private subnets, and it is the virtual address of each VPN Client that is used as the source address on client packets destined for private subnets. Routing must be configured on hosts on the private subnet(s) so that response packets can be routed back to the VPN Clients via the Access Server host’s IP address on the private subnet.
Note: NAT is usually preferred for allowing VPN Clients access to private subnets. Routing is more complicated to configure, as it requires routing changes on the network infrastructure. Routing is offered to accommodate applications that do not function properly through NAT.
When one of the Yes options above is selected, the private subnets must be specified. You can enter multiple subnets, each specified as a network/netmask_bits pair such as 10.33.4.0/24 on a separate line in the textbox.
When Yes is selected for the Should clients’ Internet traffic be routed through the VPN? setting, the default route on a newly-connected VPN Client host is set to point to the VPN gateway’s virtual IP address. This setting prevents ‘split tunneling’. All network traffic on the VPN Client host flows through the Access Server (with the client’s Internet traffic going through the Access Server’s public IP address
To assing the settings you will need to scroll down to the bottom of the page and click: Save Settings