03-02-2010 09:09 AM
Have a Cisco 3005 Concentrator and some users are not able to route traffic due to the gateway not being the same as the VPN interface. The issue occurred after one of the groups was deleted from the 3005 device. Users are able to connect but cannot reach the remote network. When looking at "route print" the gateway shows a different IP address other than the Interface IP of the VPN virtual device. Is there a way to force a change or clear out routes? Example;
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 172.20.10.5 172.20.10.122 20
10.1.0.0 255.255.255.0 172.20.10.1 172.20.10.59 100
10.2.0.0 255.255.255.0 172.20.10.1 172.20.10.59 100
126.96.36.199 255.255.255.255 172.20.10.5 172.20.10.122 100
127.0.0.0 255.0.0.0 On-link 127.0.0.1 306
127.0.0.1 255.255.255.255 On-link 127.0.0.1 306
127.255.255.255 255.255.255.255 On-link 127.0.0.1 306
169.254.0.0 255.255.0.0 On-link 172.20.10.122 296
169.254.255.255 255.255.255.255 On-link 172.20.10.122 276
172.20.10.0 255.255.255.0 On-link 172.20.10.122 276
172.20.10.0 255.255.255.0 On-link 172.20.10.59 276
172.20.10.0 255.255.255.0 172.20.10.1 172.20.10.59 100
172.20.10.6 255.255.255.255 On-link 172.20.10.122 100
172.20.10.59 255.255.255.255 On-link 172.20.10.59 276
172.20.10.122 255.255.255.255 On-link 172.20.10.122 276
172.20.10.122 255.255.255.255 172.20.10.1 172.20.10.59 276
172.20.10.255 255.255.255.255 On-link 172.20.10.122 276
172.20.10.255 255.255.255.255 On-link 172.20.10.59 276
172.20.10.255 255.255.255.255 172.20.10.1 172.20.10.59 276
172.20.11.0 255.255.255.0 172.20.10.1 172.20.10.59 100
172.20.21.0 255.255.255.0 172.20.10.1 172.20.10.59 100
172.20.31.0 255.255.255.0 172.20.10.1 172.20.10.59 100
172.20.50.0 255.255.255.0 172.20.10.1 172.20.10.59 100
172.20.51.0 255.255.255.0 172.20.10.1 172.20.10.59 100
Solved! Go to Solution.
03-09-2010 11:50 AM
There are some group settings for NAT-T, so it makes sense that some clients had the problem but others didn't. Good to know that another cause of a VPN client routing problem could be related to the absence of NAT-T. I rated your answer.
03-02-2010 10:57 AM
This URL provides information on how to modify static routes on the concentrator.
This URL provides information on how to remove dynamically learned routes.
03-02-2010 11:03 AM
Looked at the routing on the concentrator but the issue resides on the client. The routes on the concentrator are correct. The
client is not sending traffic out of the interface due to the incorrect gateway, from what I can tell. I'm looking
for a way to correct the gateway on the client side.
03-02-2010 11:13 AM
I'm thinking that the group you deleted was the group these clients were in, and now they are using the base group?
Are they using split tunneling?
03-02-2010 11:27 AM
Split tunneling is enabled and yes the users were in the group that was deleted. The profile on the client side has bee
n deleted and recreated and other groups have been tried with the same results. On another system using the same g
roup the VPN connects and the gateway for the remote access shows the VPN interface IP address and
users are able to access the remote network. If the gateway for the remote network shows anything other than the VPN interface the
n routing does not work. I've tried deleting routes and re-adding with no luck.
03-02-2010 11:30 AM
Can you check the order of the Windows adapters? We've run into some issues when the VPN adapter is not listed first. HTH
03-02-2010 11:45 AM
VPN adapter is listed first. I can ping the VPN adapter IP but nothing beyond. Tracert to anything on the remote network timesout on the first hop.
03-02-2010 12:16 PM
try configuring reverse route in concentrator and check the logs then paste here
03-02-2010 12:26 PM
My best guess is that this problem is related to the split tunnel ACL.
You can also assign dynamic filters by group or user. Please check to see whether this is the case.
Please also make sure the IP subnet of central site that you connect to does not cover the IP range subnet of local gateway (for ex: Main off IP 192.168.1.0/24, local gateway 192.168.1.0/24.
It may be with the change to the default group that the address pool for the VPN client has changed. Please verify that routing to the remote client's network is available within your central site.
03-02-2010 12:58 PM
Do not think it is a Split Tunnel issue as the majority of the users have no issues. At this time 3 users have a routing issue that I am aware of, two of which were connected when the group was deleted and one was not connected when the group was deleted. Have re-installed the Cisco client on two of the three users and the routing issue still appears.
03-02-2010 01:05 PM
Are you able to verify the remote clients' address pools? If the deleted group was assigned its own address pool then these clients will get new addresses. If they overlap with the concentrator's address it could cause some access problems.
03-02-2010 01:10 PM
Address pool has been verified for the users and all users use the same pool. Tested using a different group and address pool with same result, connects but cannot route traffic.
03-02-2010 01:26 PM
Are all of your clients running Vista or is there possibly a difference between the Vista and non-Vista clients' results?
03-02-2010 01:35 PM
Have users with XP, Vista and 7 that are having this issue. Have disabled local firewalls with same results.
03-02-2010 04:45 PM
The concentrator will save a backup configuration file every time you save the configuration. Do you possibly have the backup file that could be used to determine the settings for the deleted group?
My other question is, I haven't worked with Vista before, but does the output of the route print indicate that this PC has dual NICs?
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: