Remote Access Design Guidelines – Part 4: IP Routing and DNS

[アーティクル]
03/17/2009

Hello Customers,

In this post, I will walk through some aspects on IP addressing, routing and name resolution related design guidelines.

4.1 IP Addressing

The VPN client machine will have minimum two IP addresses – one that it gets from ISP through which it connects to VPN server (called as outer or internet IP address) and other is the one it gets from VPN server through which it connects to machines behind VPN server (called as inner or intranet IP address). And each of these addresses can be IPv4 or IPv6 or both.

All tunnels are supported over IPv4 Internet. However please note that L2TP/IPSec, SSTP and IKEv2 tunnels are supported over IPv6 internet and PPTP cannot be used in this scenario.

Both IPv4 as well as IPv6 addresses can be sent to VPN client by VPN server – for all tunnels. This way the VPN client machines can access IPv4 as well as IPv6 resources of Intranet. RRAS server can be configured in following ways - with an IP address pool that it will use to hand-out the (inner) IP address to the VPN clients:

If handing out IPv4 address to the VPN client: IPv4 pool can be statically configured on the RRAS server using MMC, netsh OR it can be dynamically obtained from a DHCP server located on intranet interface of RRAS server. This address is passed to VPN client during PPP IP configuration (i.e. IPCP) stage or IKEv2 configuration payload stage.

For example, we have a RRAS server with two network interfaces – one towards internet (100.100.100.1/24) and one towards intranet (192.168.1.1/24). In this scenario, there are two options for VPN clients’ IP address pool: -

Option a) VPN client gets the IP address from the same intranet pool (i.e. 192.168.1.0/24). This scenario is common in small-medium businesses – as one IP subnet is sufficient for LAN as well as remote access clients. In this scenario – care must be taken to restrict the pool to appropriate IP addresses if statically configured on RRAS server – otherwise you may land into situations where same IP address is allocated to VPN client by RRAS server as well as a LAN client by the DHCP server. The advantage in this scenario is as RRAS server supports proxy ARP functionality, LAN clients automatically detects they need to send packets via RRAS server when trying to send packets to VPN clients. And you don’t need to configure any additional routes.

Option b) VPN client gets the IP address from a different pool which is not same as intranet interface (say 192.168.2.0/24). This is common in big organizations having large number of machines and subnets. In this scenario – you must ensure appropriate IP routing is done for this subnet on the LAN side i.e. LAN clients must be able to reach to the subnet which VPN clients belongs to (i.e. 192.168.2.0 in this example).

If handing out IPv6 address to the VPN client: IPv6 pool can be statically configured on the RRAS server with a prefix length of 64 (e.g. 3000:1:1:2:: ). This prefix has to be different compared to RRAS server intranet interface. This prefix is passed to VPN client via IPv6 router advertisement once the PPP interface comes up or IKEv2 configuration payload stage.

For example, we have a RRAS server with two network interfaces – one towards internet (100.100.100.1/24) and one towards intranet (3000:1:1:1::/64). In this example, the IPv6 address pool for VPN client cannot be same as 3000:1:1:1::/64 and it has to be a different pool (say 3000:1:1:2:: ). You must ensure appropriate IPv6 routing is done for this prefix on the LAN side i.e. LAN clients must be able to reach to the prefix which VPN client belongs to (i.e. 3000:1:1:2::/64 for this example).

4.2 Name resolution

The intranet resources can be accessed by VPN clients using names (e.g. https://team/mysite). And names can be resolved to IP address using DNS based resolution (IPv4 as well as IPv6), WINS based resolution (only IPv4) and NetBIOS based broadcast resolution (only IPv4).

WINS and DNS based name resolution requires a server address to be provisioned on the VPN client. The WINS server can run on top of IPv4 based network only, whereas DNS server can have IPv4 as well as IPv6 address – or in other words VPN client can reach the DNS server over IPv4 or IPv6 based network.

The IP address of WINS and DNS server is provisioned on VPN client in one of the following ways:

· Statically configured inside VPN client configuration – inside Network Properties of VPN client.

· Dynamically obtained from the VPN server – during connection establishment. This handshake process varies between PPP based tunnels (aka PPTP, L2TP and SSTP) and IKEv2 based tunnel (aka VPN reconnect).

For PPP based tunnel, the WINS and DNS server’s IPv4 address picked up from VPN server’s private interface is passed via PPP IPv4 configuration stage (called as IPCP) to the VPN client. And the DNS server’s IPv6 address is passed via DHCPv6 Inform transaction after IPv6 prefix is assigned to VPN client via router advertisements. Note: This requires VPN server to be running DHCPv6 relay agent and DHCPv6 stateless server running on the network behind VPN server.

For IKEv2 based tunnel, the WINS and DNS server’s IPv4 as well as IPv6 address is picked up from VPN server’s private interface and is passed via IKEv2 tunnel establishment phase.

The NetBIOS based name resolution for IPv4 resources works as a broadcast – i.e. doesn’t require any server to be provisioned. It requires “Enable broadcast name resolution” to be enabled on RRAS based VPN server and “Enable NetBIOS over TCP/IP” setting to be enabled on VPN client.

4.3 Routing on VPN Client side

Once the VPN interface comes up, VPN client machine has two IP interfaces – one is the VPN interface and second is the internet interface on top of which the VPN connection is established.

Every TCP/IP packet goes through a route look-up to find the best matching route (longest prefix match) for the given destination. And for most practical cases, most of the resources don’t match a specific route and thereby matches the default route (i.e. routing table entry with destination as 0.0.0.0 for IPv4 and ::/0 for IPv6).

There are two choices for the “default route” on the VPN client machine:

Default route over VPN interface: This means all the traffic (intranet as well as internet) will flow on top of VPN interface from client to server – except the local subnet traffic flowing over underlying internet interface.

To enable this scenario,“use default gateway” should be enabled inside IPv4 and IPv6 properties of VPN client configuration.

For example, the client machine has a LAN interface providing Internet connectivity with IP Address as 192.168.1.2 with default IPv4 route to a broadband router running NAT with IP address 192.168.1.1. On the LAN side, there is a printer too with IP address 192.168.1.3.

Once the VPN connection is successfully established, the client machine has a VPN interface with IP address as 10.0.0.100 with VPN server tunneled address as 10.0.0.1. And one more default IP route is added on the client machine “with lowest metric” (or in other words highest preference) – with gateway address as 10.0.0.1. Same thing happens if IPv6 prefix is assigned to the VPN client.

Whenever the client machine access any machines on the LAN side (i.e. 192.168.1.0/24), those IP packets goes directly over LAN without going over VPN tunnel. However, when the client machine accesses any resources behind RRAS server (i.e. intranet resources) or machines on the internet side (say https://www.microsoft.com), those packets traverses the VPN tunnel and reach the VPN server. And the VPN server based upon the destination routes the packet onto Internet or to Intranet side. Note: If private IPv4 address is given to VPN client, then NAT should be running on RRAS server or some machine in-front of RRAS server (i.e. between RRAS server and internet) to translate the private IP to public IP.

Note: This scenario requires DNS server on intranet side to resolve Intranet as well as Internet queries. And it is assumed that local subnet traffic is resolved via some broadcast resolution (like NetBIOS for IPv4 and LLMNR for IPv6).

Default route over internet interface: This means only intranet traffic traverses the VPN tunnel and rest of all traffic (i.e. local subnet traffic OR Internet traffic) goes over underlying internet interface. This scenario is also called as “split-tunneling”.

To enable this scenario,“use default gateway” should be disabled inside IPv4 and IPv6 properties of VPN client configuration.

If we take the above example, once the VPN connection is successfully established, the default route remains untouched (i.e. continue to point to the underlying internet interface).

The VPN client can access the intranet machines which falls under the IPv4 subnet (i.e. 10.0.0.0/8) or IPv6 prefix that the client receives from the VPN Server. This may be well suited for small deployment (i.e. having one subnet or prefix range), however in case the intranet resources are divided into multiple subnets or prefixes, then that entire range needs to be provisioned on the VPN client using some mechanism (like using connection manager administration kit aka CMAK).

Note: This scenario requires DNS server on intranet side to resolve Intranet as well as Internet queries – as DNS queries may still go over VPN interface. And it is assumed that local subnet traffic is resolved via some broadcast resolution (like NetBIOS for IPv4 and LLMNR for IPv6).

Warning: As a security note, Internet connection sharing MUST be disabled on the VPN client machine – to prevent other users (behind VPN client machine or may be on Internet) to access the corpnet using the VPN client machine’s tunnel to the VPN server.