VPN clients to PIX from behind same NAT-hide

[scot.hartman]

I'm having some issues with some VPN clients to a PIX firewall.

The PIX is on 6.3(3) code and the clients are running v4.

I have one remote user in particular who has two machines that he

connects to the PIX simultaneously.

One needs a specific IP so he's using the group mgroup which

assigns a .31 address.

The other gets one from the vpnpool by using the vpnuser group.

They both end up coming from the same IP address from his NAT

router. Whichever one connects first, wins. The other cannot

connect.

I have nat-traversal enabled, I've had him try his clients with

and without transparent tunneling.

Debugs while the second one is trying basically says proposals

not acceptable. But log off of the other one and it works.

I've included some debug output and some config info below...

Can the PIX support multiple clients connecting from behind the

same PAT/NAT address?

Any ideas?

Thanks

========================================================

Some debug output.

========================================================

pix (config)#

crypto_isakmp_process_block:src:64.7.14.28, dest:66.45.73.244 spt:500 dpt:500

OAK_AG exchange

ISAKMP (0): processing SA payload. message ID = 0

.

.

.

ISAKMP (0): Checking ISAKMP transform 2 against priority 40 policy

ISAKMP: encryption AES-CBC

ISAKMP: hash MD5

ISAKMP: default group 2

ISAKMP: extended auth pre-share (init)

ISAKMP: life type in seconds

ISAKMP: life duration (VPI) of 0x0 0x20 0xc4 0x9b

ISAKMP: keylength of 256

ISAKMP (0): atts are not acceptable. Next payload is 3

.

.

.

ISAKMP (0): atts are not acceptable.

crypto_isakmp_process_block:src:64.7.14.28, dest:66.45.73.244 spt:500 dpt:500

VPN Peer:ISAKMP: Peer Info for 64.7.14.28/500 not found - peers:1

ISAKMP: larval sa found

ISAKMP (0): retransmitting phase 1 (0)...

crypto_isakmp_process_block:src:64.7.14.28, dest:66.45.73.244 spt:500 dpt:500

VPN Peer:ISAKMP: Peer Info for 64.7.14.28/500 not found - peers:1

.

.

.

========================================================

VPN config info...

========================================================

sysopt connection permit-ipsec

crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac

crypto dynamic-map outside_dyn_map 20 set transform-set ESP-3DES-MD5

crypto map outside_map 65535 ipsec-isakmp dynamic outside_dyn_map

crypto map outside_map client authentication RADIUS

crypto map outside_map interface outside

isakmp enable outside

isakmp identity address

isakmp keepalive 11 60

isakmp nat-traversal 20

isakmp policy 40 authentication pre-share

isakmp policy 40 encryption 3des

isakmp policy 40 hash md5

isakmp policy 40 group 2

isakmp policy 40 lifetime 86400

vpngroup vpnuser address-pool vpnpool2

vpngroup vpnuser idle-time 10800

vpngroup vpnuser user-idle-timeout 28800

vpngroup vpnuser password ********

ip local pool vpnpool 192.0.2.50-192.0.2.100

ip local pool vpnpool2 192.0.2.129-192.0.2.190

vpngroup mgroup address-pool mpool

vpngroup mgroup idle-time 10800

vpngroup mgroup user-idle-timeout 28800

vpngroup mgroup password ********

ip local pool mpool 192.0.2.31

vpngroup ggroup address-pool gpool

vpngroup ggroup idle-time 10800

vpngroup ggroup password ********

ip local pool gpool 192.0.2.33

access-list dmz1_outbound_nat0_acl permit ip any 192.0.2.0 255.255.255.128

[mostiguy]

Check the device he is behind that is doing PAT. Disable any IPSec passthrough features on it, and install the latest firmware on it. I have seen similar problems with some SOHO gear, and generally these two steps will resolve it.

[scot.hartman]

I'd thought it might be something at the remote end. Nice to have a confirmation. Odd thing that drove me crazy is that he CAN connect from both SOMETIMES. Drove me batty.

I've asked him to check for any IPSec passthrough settings. He doesn't see any but will update his firmware. He'd mentioned he's getting ready to replace the router and that he did have other public IPs he wasn't using so I've asked that he give one of these systems a static NAT to avoid any clashes.

Thanks.

[pkapoor]

A static 1-to-1 mapping for one host and a dynamic NAT/PAT for the other host will do the trick. However, certain NAT/PAT devices do not support multiple IPSec pass-throughs.

Having worked at TAC and addressed several of these cases (it is a known thing) I can confidently tell you that the issue is due to the NAT/PAT device behind which multiple clients sit. Of course, you will need NAT-Traversal enabled on the PIX.

P.S. - I personally prefer a 3DES / SHA / Group 2 ISAKMP policy for VPN Clients in the 4.x versions.

Paras

[scot.hartman]

Thanks for the insights. I'm thinking the static NAT on one will end this as an issue for me. He is, after all, able to connect from both occassionally even from behind the same NAT/PAT.

P.S. I actually did have it as 3DES/SHA at one point and during one of my gyrations had built two different tunnel policies with different settings to try and differentiate the clients (to no avail). When I trimmed back to one, I ended up with the MD5. Do you see a stability gain with the SHA, or is a personal security preference due to bit size, strength, etc.?

[pkapoor]

The reason I prefer SHA is this. When a client connects, it sends all its ISAKMP policies to the gateway. The gateway will then start processing them in the order of their priority, against its own. Now, the priority of the client policies is listed with the strongest encryption first i.e. the AES proposals will be considered first, then the 3DES/SHA, then 3DES/MD5, then the DES/SHA, and so on. Therefore, if you do not have AES configure 3DES/SHA/Group2 as the policy because it is the strongest within the "3DES" classification. This will mean that the negotiation will happen faster, less processing is required, and fewer resources are engaged. Further, I have seen sometimes that the client will have been working for a long time with DES, however, it will (for no apparent reason) stop connecting with a DES policy. The debugs in such situations show that the client is not able to negotiate with DES (SA not acceptable!). This observation comes from having worked for a year and a half with the VPN team at Cisco TAC. Therefore, the advise/preference.

[scot.hartman]

Excellent. Good to know. Thanks.