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:
- 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.
- 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:
RFC 2131: Dynamic Host Configuration Protocol (obsoletes RFC 1541)
RFC 2132: DHCP Options and BOOTP Vendor Extensions