Client 404 doesn't authenticate with UDP but does with TCP

[dopenfield]

Users running XP Pro SP2 with ver 4.0.4 of the VPN client.

VPN terminates on a 3000 concentrator.

Users authenticate group name on the concentrator and then User IDs via Radius on Cisco ACS server.

Last week two users that had been using UDP from home travelled and from their hotel could not get authenticated.

Log on the Concentrator showed the group ID was authenticated at the Concentrator. Log on the ACS Server did not show any attempt from the Concentrator to send the User ID.

Other Users were successfully authenticating during this same time frame.

Eventually had users change from using UDP to TCP (Port 10000) and things once again worked normally.

Have another user reporting the same scenario from a different remote location.

Do have a ticket open with TAC but so far no joy.

Any thoughts on what might be going on here??

[ehirsel]

Are there any firewalls or other devices that have acls that monitor traffic in front of your concentrator?

How is the client configured for udp transparent tunneling? I believe that the cisco v4 client cannot specify the udp port, and it defaults to udp port 4500.

Also check that the concentrator allows for udp transparent tunnelling.

At the concentrator go to:

Configuration | Tunneling and Security | IPSec | NAT Transparency Screen

Insure that the option ipsec over nat-t is checked.

The initial connection proceeds over udp port 500 (IKE) and that is when the group info is used to create the hash, thus the message that the group was authenticated appears in the concentrator log.

Let me know if this helps.

[dopenfield]

Nothing in the path at our end that should be affecting the traffic.

Users have been accessing the VPN with the original setup for some time. One accesses via satellite connection from home and is behind NAT from that location so I'm not thinking this is a NAT issue.

No the client doesn't allow user to select a UDP port but does on TCP, 10000 is the default port.

Yes the Concentrator is set to support NAT Transparency.

Thanks for the ideas.

[ehirsel]

It may be path mtu issue. At a client that is having the issue, run the set mtu command and set the mtu on the virtual adapter to 1300 (it may be set to 1500).

Let me know if this helps.

[dopenfield]

Hadn't thought of checking that, but when I did the client is set to the default of 1300.

Any other ideas.

I'm only getting phone tag from TAC right now.

[pkapoor]

Check on the client side network to make sure that UDP 4500 is open BOTH WAYS, inbound and outbound.

The way this works is that the 3k concentrator's IP is associated with UDP port 4500 and the client's IP gets a random high-number port assigned to it by the concentrator.

For example:

If client connects using UDP 4500, then the outbound packet from the client has the concentrator's IP as the destination and the destination port is 4500.

The concentrator will send the client a random port number. So the in bound packet will have the destination IP as the client's IP and the destination port number will be that random port number.....the source IP on the packet will obviously be the concentrator and the source port will be UDP 4500.

Oh! BTW, I do not think it is MTU issue....these clients cannot even connect in the first place. MTU becomes an issue when the clients are trying to pass traffic.