When assigning a VPN IP pool to VPN clients if the IP pool is on a different network or subnet than the internal port of the PCS device then it will be necessary to create routes on edge routers that instruct the router than when traffic is received that is intended for the NC client network to use the internal port of the PCS device as the next hop.
The easiest way to verify a packet is routed correctly is to have a user sign-in and establish a Network Connect session. Then, from a computer on the internal network (upstream from the PCS's internal port), run a traceroute to the client's Network Connect IP address. (This may need to be allowed through the firewall.) This will show whether there are sufficient routes on the internal network to route the packets back to the internal interface of the PCS.
To run the command from a Windows machine, open the command prompt window (go to Start > Run; type command or cmd and press enter) and type: tracert xxx.xxx.xxx.xxx (where xxx is the Network Connect virtual IP address assigned to the user).
To run the command from a Mac/Linux, open the terminal/command line interface and type: traceroute xxx.xxx.xxx.xxx (where xxx is the Network Connect virtual IP address assigned to the user).
If proper routing is in place then similar output will be displayed as below where 172.18.65.218 is the NCIP.
If the packets cannot be routed to the NC client then the traceroute will show the device where the traffic is being dropped. Commonly, the traffic is dropped by a router or a firewall. This will also be the device which a route or policy should be added to, in order to route traffic destined for the NCIP network to be sent to the internal port of the PCS device. Once the traffic reaches the PCS, the PCS will send the traffic to the appropriate NC client.
Common Routing Issues with Network Connect
IP Pool Addresses outside of the PCS subnet
Many times the above scenario is caused by the Network Connect IP address pool being outside of the PCS's local subnet. Normally the router which is connected to the PCS's internal port will register that port as being part of a that subnet. So when traffic bound for a Network Connect IP address requests the route the router says. I have a route for this subnet but not this specific IP. It then send out an ARP packet which the PCS will respond to. When the Network Connect IP addresses are outside of the router does not associate the subnet with the PCS and so the return traffic becomes lost.
The easiest way to correct this is to add a static route to the router which is connected to the PCS for the Network Connect IP address pool to use the PCS internal port as the next hop.
IP Pool Addresses when using VLANs
If using VLAN's on the switch that the internal port of the PCS connects to, then the Network Connect IP address range must reside on the same VLAN as the internal port of the PCS. This is to ensure that the VLAN tag for the Network Connect traffic leaving the PCS routes the traffic back to the internal interface of the PCS.
Resources that are external from the network or are in the external DMZ
The PCS as a Security measure will not initiate any traffic from the external port. What this means is that a Network Connect client cannot simply access a server in the external DMZ or outside internet by going out the external interface. Instead the Network Connect client makes the request through the internal port which then tries to find a route from the internal gateway to the resources. What this means is you have to provide a route from the internal gate way to the external resource. Please reference the Diagram below.