Reset Search
 

 

Article

KB9225 - How to verify that Network Connect traffic is being routed properly to and from the NCIP Pool

« Go Back

Information

 
Last Modified Date6/7/2017 5:21 PM
Synopsis

This article provides steps to detect problems with and verify proper routing is in place for packets to reach Network Connect clients using the internal port of the PCS device as the next hop.

Problem or Goal
Network Connect users are able to connect and get an IP assigned but cannot access any resources.  When they open Network Connect from the system tray it is observed that bytes are being sent but '0' bytes are received.  
 
User-added image

This would indicate that traffic is not being routed correctly to Network Connect clients.
Cause
This issue can occur if:
  • The NCIP pool is on a different subnet than the internal port of the PCS device.
  • The NCIP pool is on a different network than the internal port of the PCS device.
  • The internal port of the PCS device is in the DMZ and the NCIP pool being used is on the same subnet as the external interface which is not in the DMZ.
Solution

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. 
trace_route

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.

Screenshot_001
Related Links
Attachment 1 
Created ByData Deployment

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255