KB22611 - Does the PCS act as a DHCP Relay Agent when requesting Layer 3 (L3) VPN client IP addresses from my corporate DHCP?

This article describes the steps on assigning IP addresses to Layer 3 (L3) VPN clients on DHCP scope subnets which is different than the PCS internal IP address subnet range.
 

A DHCP server(s) has been setup with IP address scopes which is different from the PCS’s internal IP subnet. The PCS appliance Connection Profile has been configured (Users > Resource Policies > VPN Tunneling > Connection Profile) to use this DHCP server to assign IP addresses to the VPN tunneling client, but the Microsoft DHCP server is not issuing an IP address. See Example configuration below:

PCS Internal IP Address: 10.10.2.25 (/24)
VPN Tunnel Server IP Address: 10.200.200.200
Microsoft DHCP Server IP Address: 10.10.2.30 (/24)
Microsoft DHCP Scope: 10.10.3.1 – 253 (/24)

In this case, the DHCP Relay IP Address field is populated with the internal IP address of the PCS, 10.10.2.25/24, but as the DHCP scope is set for 10.10.3.0/24, the Microsoft DHCP server does not answer the request despite multiple DHCP requests from the PCS.

Source     Destination Protocol Info
10.10.2.25 10.10.2.30  DHCP     DHCP Discover
10.10.2.25 10.10.2.30  DHCP     DHCP Discover
10.10.2.25 10.10.2.30  DHCP     DHCP Discover

 

The PCS is not a DHCP relay agent because it does not forward DHCP packets to/from the client and the DHCP server. Even if it did, the PCS does not have an option in the admin UI to pre-populate the relay agent header field with a specific IP and subnet for a particular subnet scope(s) other than PCS internal IP address subnet range. Virtual ports can be used to change the Source IP used to contact the DHCP server, but the virtual ports still cannot be configured outside the PCS  internal IP address subnet range. In this case, the described behavior is working as designed.

As per RFC 1542, there needs to a router connecting each subnet and each router should comply with the DHCP/BOOTP relay agent capabilities described this RFC. The PCS does not receive the DHCP discover request from the client (Typically with a DHCP/BOOTP header field with a Relay Agent IP address of 0.0.0.0 as the client does not yet have an IP address) and then forward it to the DHCP server.

The first DHCP discover request will always come from the internal IP address of the PCS appliance. This is because the PCS always requests IP addresses from the DHCP server on behalf of all VPN tunneling clients, so the Relay IP Address field will always likewise be the internal IP address of the PCS appliance. (See KB22889 - [MAG PCS] What PCS configuration is required for the VPN tunneling client to obtain an IP address? for more information on how the PCS assigns IP addresses to the VPN tunneling clients).

In a working DHCP relay agent environment, the first DHCP discover request will come from the client to the DHCP relay enabled router. When the relay agent or router receives the request, it fills the Relay Agent field will (with) its own IP address and forwards the message to the DHCP server. If your network topology dictates that PCS internal IP interface and the IP address scopes reside on different subnets, the following options are available to work around this issue:

1. Configure IP Address pool on your connection profile rather than DHCP server(s). However, be sure you add static routes to your intranet’s gateway router(s) to ensure that your Enterprise resources and Secure Access Service can see each other on the internal network.

2. Configure DHCP Option 118 (See RFC http://www.rfc-editor.org/rfc/rfc3011.txt) if it is supported by your DHCP server, however, keep in mind that this option will not work with a Microsoft DHCP server, as Microsoft does not currently implement this RFC. The following RFCs specify the core DHCP standards that Microsoft supports with its DHCP service: