VPN client remote Network(behind pix)cannot access our Network VPN 3005

[mariocabrejo]

Hi,

We have a user on some remote location(behind pix) that cannot access our network resorces, eventhough on my vpn 3005 logs shows that he passed phase1 and Phase2. This is a translation problem. What is do I need to make this work?

Here is my vpn log when user authenticates from remote newtork:

16039 06/29/2004 13:15:57.010 SEV=4 IKE/52 RPT=394 66.153.120.35

Group [hillintl] User [hillintl\jwh]

User (hillintl\jwh) authenticated.

16040 06/29/2004 13:15:57.060 SEV=4 IKE/131 RPT=394 66.153.120.35

Group [hillintl] User [hillintl\jwh]

Received unknown transaction mode attribute: 28682

16042 06/29/2004 13:15:57.120 SEV=4 AUTH/22 RPT=404

User hillintl\jwh connected

16043 06/29/2004 13:15:57.120 SEV=4 IKE/119 RPT=394 66.153.120.35

Group [hillintl] User [hillintl\jwh]

PHASE 1 COMPLETED

16044 06/29/2004 13:15:57.130 SEV=5 IKE/25 RPT=751 66.153.120.35

Group [hillintl] User [hillintl\jwh]

Received remote Proxy Host data in ID Payload:

Address 192.168.253.1, Protocol 0, Port 0

16047 06/29/2004 13:15:57.130 SEV=5 IKE/24 RPT=305 66.153.120.35

Group [hillintl] User [hillintl\jwh]

Received local Proxy Host data in ID Payload:

Address 65.117.186.106, Protocol 0, Port 0

16050 06/29/2004 13:15:57.130 SEV=5 IKE/66 RPT=751 66.153.120.35

Group [hillintl] User [hillintl\jwh]

IKE Remote Peer configured for SA: ESP-3DES-MD5

16052 06/29/2004 13:15:57.130 SEV=5 IKE/75 RPT=751 66.153.120.35

Group [hillintl] User [hillintl\jwh]

Overriding Initiator's IPSec rekeying duration from 2147483 to 28800 seconds

16054 06/29/2004 13:15:57.140 SEV=5 IKE/25 RPT=752 66.153.120.35

Group [hillintl] User [hillintl\jwh]

Received remote Proxy Host data in ID Payload:

Address 192.168.253.1, Protocol 0, Port 0

16057 06/29/2004 13:15:57.140 SEV=5 IKE/34 RPT=447 66.153.120.35

Group [hillintl] User [hillintl\jwh]

Received local IP Proxy Subnet data in ID Payload:

Address 0.0.0.0, Mask 0.0.0.0, Protocol 0, Port 0

16060 06/29/2004 13:15:57.140 SEV=5 IKE/66 RPT=752 66.153.120.35

Group [hillintl] User [hillintl\jwh]

IKE Remote Peer configured for SA: ESP-3DES-MD5

16062 06/29/2004 13:15:57.140 SEV=5 IKE/75 RPT=752 66.153.120.35

Group [hillintl] User [hillintl\jwh]

Overriding Initiator's IPSec rekeying duration from 2147483 to 28800 seconds

16064 06/29/2004 13:15:57.190 SEV=4 IKE/49 RPT=753 66.153.120.35

Group [hillintl] User [hillintl\jwh]

Security negotiation complete for User (hillintl\jwh)

Responder, Inbound SPI = 0x27abef6a, Outbound SPI = 0x818f45ab

16067 06/29/2004 13:15:57.200 SEV=4 IKE/120 RPT=753 66.153.120.35

Group [hillintl] User [hillintl\jwh]

PHASE 2 COMPLETED (msgid=09b91fe5)

16068 06/29/2004 13:15:57.430 SEV=4 IKE/49 RPT=754 66.153.120.35

Group [hillintl] User [hillintl\jwh]

Security negotiation complete for User (hillintl\jwh)

Responder, Inbound SPI = 0x15a0c3fe, Outbound SPI = 0xc7fae66a

16071 06/29/2004 13:15:57.430 SEV=4 IKE/120 RPT=754 66.153.120.35

Group [hillintl] User [hillintl\jwh]

PHASE 2 COMPLETED (msgid=35d05a8c)

Thanks

[ehirsel]

One thing to check at the user's workstation after the vpn tunnel is established, is that the proper dns and/or wins servers are being sent to the client. Have the client run the ipconfig /all command (I assume that the client is running ms win os - let me know otherwise). Insure that the dns domain name, dns servers, and wins servers are properly configured.

If the dns info is correct then have the user run this command: nslookup hostx where hostx is a host on the other side of the vpn tunnel. This will test dns name resolution. Let me know how that works out.

If the name resolution works, then mtu may be an issue. By default windows sets the DF bit in tcp frames, and relys upon icmp unreachable messages to let it know to send smaller frames. You can test this by having the user run the set mtu program that comes with the client (or have someone local to logon as pc admin to run the util) and set the mtu on the adapter corresponding to the vpn client virtual adapter to 1300 instead of default. This will set the frame size before IPSec encap to 1300 (including tcp and ip header, yielding a max tcp mss size of 1260.

If name resolution fails, but the correct dns/wins and doamin-name is sent to the client, then re-examine the filter rules on the vpn 3015. Insure that the client's assigned address does not conflict with another pool, and that that address/subnet can access resources on your internal network. If there is a firewall behind the 3015, re-examine those rules too.

Lastly, if the 3015 is doing RRI with any internal routers, check that the routing protocols on those routers are not preferring other paths back out, bypassing the 3015 for the remote user.

Let me know how things proceed from here.

[mariocabrejo]

Ehirsel,

Thanks for your input, I did follow them, name resolution as MTU size was ok. I am sorry I forgot to mention I was using vpn software client not hardware.

Anyway, using Ipsec over Udp did fixed the issue, only had to make a new group and specify this user and select the udp port number on the concentrator(you have to make sure your firewall accepts this port number).

Other option was to use Nat-T but the other option did worked so why bother.

Here is the Link for any other that has the same problem

http://www.cisco.com/warp/public/471/nat_trans.html

Thanks

Mario Cabrejo

Network Engineer

[pkapoor]

The issue seen herein gentlemen is called NAT Transparency. It happens especially when a host is getting PATed by some headend device (in our case a PIX).

Here is more on NAT-Transparency.

http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080110bca.html

By the way Mario, just for your information the concentrator has 3 NAT-Transparency features.

1. IPSec over TCP

2. IPSec over NAT-T

3. IPSec over UDP.

The first 2 are globally configured and affect all groups. The third one is group-specific.

If all are enabled, then the concentrator prefers IPSec over TCP, followed by IPSec over NAT-T, and finally IPSec over UDP. Of course, the peer connecting must also support the same feature.

My 2 bits for this post.