No traffic through Vlan

[stuart.beck]

Hi All, I've managed to inherit a problem with a VPN connection from an outside client through a cisco 1712. The connection is being correctly authenticated via a radius server however the client cannot then be contacted and the logs seem to be indicating to me that there is no traffic between the client and the cisco. I have been assurred that the client network configuration has not been altered in any way and that the problem "must" be with the cisco. Any ideas what might be causing this situation?

[spremkumar]

Hi

Can you post the configuration of your cisco 1712 router with public ips and passwords masked ??

regds

[stuart.beck]

Hi Spremkumar,

my configuration is attached....

The machine that is having the problem is connecting to the local pool client2-vpn-client.

Stuart.

[Richard Burts]

Stuart

I have looked at the config that you posted. I notice that there are only two addresses in the pool. Is it possible that the remote client connects, authenticates, but is not assigned an address from the pool? Can you verify when this problem occurs what address the client has and is using?

Your original post says that they claim no changes on the client. Are you aware of any changes on the router (or anywhere else in the networking environment)?

HTH

Rick

[stuart.beck]

I can see in our logs that the remote host is picking up an address within the range, in the latest case 10.66.5.141. The pool originally had only one address so as to force the ip address of the client host connecting to the vpn (I dont know if there is a better way to do this).

I have been told that there are definately no changes at this end, Although I have been told of no changes at the remote client end, I cannot be certain of this as it is located in an interstate client office.

I have finally been able to collect a log of the connection attempt from the cisco VPN client (attached) which shows the connection being established to .141.

[Richard Burts]

Stuart

Thanks for posting the additional information. Based on the log messages it looks to me like the PC is successfully establishing a VPN session from log message 30 up through log # 122. log messages 123 through 132 show keepalive messages being sent (and do not reflect responses). Log message 133 seems to show the PC attempting to establish another VPN session. I am not sure from these logs to explain what is happening.

Is it possible to get any indication from the router what it thinks is going on during this?

HTH

Rick

[stuart.beck]

Hi Rick,

I've attached the portion of the log that is related to this particular logon attempt. There as a small section of a logout at the top as I got the client to logout of the VPN connection and re-login to produce the client log.

The current debugging settings on the cisco are as follows, I'm happy to do another test with further debugging enabled.

#show debugging

vLAN:

Virtual LAN packet information debugging is on

VLAN (de-)encapsulation events debugging is on

Radius protocol debugging is on

Radius packet protocol debugging is on

Radius elog debugging debugging is on

Radius elog debugging debugging is on

Cryptographic Subsystem:

Crypto ISAKMP debugging is on

Crypto Engine debugging is on

[Richard Burts]

Stuart

Thanks for posting the additional information. It certainly does seem to show that the VPN IPSec session is correctly set up and authenticated. And after session setup the accounting records do seem to indicate that there was no input packets and only 3 output packets and that did not change for a period of 10 minutes.

I have encountered a somewhat similar situation at a customer site. In one case we believe that the issue was resolved by making a change in the firewall installed on the client machine. In one case we believe that the issue was resolved by properly configuring IPSec Passthrough on the DSL/Cable router. It might be worth asking that they check the remote end again - even though they claim that there were no changes.

HTH

Rick

[stuart.beck]

Sorry for the delay, Turns out in this case to have been Zone alarm, which had been installed and then removed about two week sprior as it was determined it would not do the job that was wanted. So now we have some connectivity.

We seem to have two remaining issues,

1. the connection goes down periodically, this appears to be related to an IKE SA rekey.

2. When the connection does go down, the PC cannot sucessfully reconnect without a reboot, we have tried a logout/logon and also a client software shutdown/restart without success.

[stuart.beck]

Hi Rick,

I've attached a client log from since the connection was working....

Everything appears ok until about 7:27 02/09/06 in the client log when the IKE SA rekey occurs (might be a red herring)

At about 7:47 a further new key is requested and we start getting Xauth error messages soon after the connection is shutdown and automatically restored (by a script), at which point no packets are received by the concentrator