VPN3 client fails to connect to PIX at Phase 1

[mburnford]

My VPN client 3.0.1 does not even connect to the PIX506 v6.0(1) at Phase 1. The client log shows:

SENDING>>>ISAKMP OAK AG(SA, KE, NON, ID, VID, VID, VID) to 193.130.x.y (i.e. PIX outside)

It tries 3 retransmissions, then says:

Exceeded 3 IKE SA negotiation retransmits... peer is not responding.

The PIX log shows nothing. But before I added an access list to pass ip it showed:

Deny udp src outside:62.x.y.z/500 dst inside:193.130.y.z/500 by access-group "100" so obviously it is reaching the PIX. (62.x.y.z is not the outside interface address; it must be the ISP address as it changes if I try when connected to a different ISP).

I have followed all guidelines, isakmp policies, etc. and have isakmp key ????? address 0.0.0.0 netmask 0.0.0.0 with matching key in VPN3 client group access information on Authentication tab, have a vpngroup set up with matching name, have an address-pool set with isakmp client configuration address-pool local <poolname> outside.

The PIX is working for users inside to get to Internet, and is passing SMTP mail, it also passes www.grc.com security tests OK.

I have tried "Allow IPSec through NAT mode" both on and off on client settings, but no differnce.

Can anyone please enlighten me on what PIX statements are related to failures at this stage.

(I'm sure that I'll have fun and games before it all works, but we need to solve this Phase 1 stage first.)

Michael Burnford

[rjphillips]

Have you got the command

isakmp enable outside

in the configuration ?

Rhodri

[mburnford]

Yes, that one is there...

Michael

[mburnford]

Further, I can ping the PIX outside interface and the PIX ICMP trace shows "Inbound ICMP echo request (len 32 ....etc) isp_address > PIX_outside_address > network_server_address" followed by "Outbound echo reply (len ...etc) server > PIX > ISP" so I presume that is all working.

However when I try the VPN3 client the trace gives just "Outbound ICMP unreachable (code 3) server_address > PIX_outside_address > ISP_address" messages.

Does this mean the client is getting to the server but the reply is not getting through? What PIX command line will correct this?

Michael

[pdentico]

Is your client behind any sort of firewall??

[mburnford]

No firewall at the client end. I have tried the client with connections to 3 different ISPs including Compuserve to see if the ISP has something funny.

If a ping replies but the VPN3 client connection does not reply, what is the difference? Both are ICMP are they not? What PIX command handles this?

Michael

[rjphillips]

Michael

From the reference to GRC.com I'm guessing you have an outbound access-list on the outside interface. This may be blocking the outbound ICMP (this is just a guess, no config info so difficult to tell). Is anything showing as being blocked in the PIX logs when you ping from VPN3 client ?

as for VPN client, the following generic config works fine with 3.X clients, check it against yours I guess (IP's and passwords changed,obviously)

ip local pool ippool 192.168.0.1-192.168.0.10

sysopt connection permit-ipsec

crypto ipsec transform-set VPDNDES esp-des esp-md5-hmac

crypto dynamic-map dynmap 50 set transform-set VPDNDES

crypto map mapName 10 ipsec-isakmp dynamic dynmap

crypto map mapName interface outside

isakmp enable outside

isakmp policy 20 authentication pre-share

isakmp policy 20 encryption des

isakmp policy 20 hash md5

isakmp policy 20 group 2

isakmp policy 20 lifetime 86400

vpngroup myVpnGroup address-pool ippool

vpngroup myVpnGroup idle-time 1800

vpngroup myVpnGroup password cisco

Rhodri

[turnbull]

Check you have the following statement in the config:

sysopt connection permit ipsec-isakmp

This will allow valid ipsec traffic to bypass ACL's

By the way, vpn3.x doesn't require the wildcard isakmp key statement. It is authenticated through the group statements.

Compare with the following sample:

http://cisco.com/warp/public/110/pix3000.html

[mburnford]

Many thanks for the help.

My config seems OK from your info, but it still doesn't connect. The point at which it fails seems to be to do with the inside interface. I will put together a config and post it later.

Michael

[pdentico]

What are the debugs from the pix.

I usually use "debug crypto ipsec" and "debug crypto isakmp"

They may prove to useful. Also, can you provide a config to look at.(Cleaned up of course)

[mburnford]

OK here is a config. I'm sure there s something simple I am missing...

PIX Version 6.0(1)

This is relevant commands for e-mail and Internet access (working well)…

access-list 100 permit tcp any host 193.x.y.29 eq smtp

icmp permit any unreachable outside

icmp permit any echo-reply outside

icmp permit any time-exceeded outside

ip address outside 193.x.y.28 255.255.255.240

ip address inside 172.x.y.1 255.255.255.0

global (outside) 1 193.x.y.17-193.x.y.21

global (outside) 1 193.x.y.22

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

static (inside,outside) 193.x.y.29 172.x.y.2 netmask 255.255.255.255 0 0

access-group 100 in interface outside

route outside 0.0.0.0 0.0.0.0 193.x.y.30 1

This is what I have added for VPN3.0 clients to access system (doesn’t work)…

ip local pool vpnpool 10.1.2.1-10.1.2.254

nat (inside) 0 access-list 90

sysopt connection permit-ipsec

no sysopt route dnat

crypto ipsec transform-set vpnset esp-des esp-md5-hmac

crypto dynamic-map dynmap 50 set transform-set vpnset

crypto map vpnmap 10 ipsec-isakmp dynamic dynmap

crypto map vpnmap client configuration address initiate

crypto map vpnmap interface outside

isakmp enable outside

isakmp identity address

isakmp policy 10 authentication pre-share

isakmp policy 10 encryption des

isakmp policy 10 hash md5

isakmp policy 10 group 2

isakmp policy 10 lifetime 86400

vpngroup vpn3 address-pool vpnpool

vpngroup vpn3 default-domain

vpngroup vpn3 idle-time 1800

vpngroup vpn3 password ********

VPN3.0 clients are set up with group vpn3, with matching password and trying to connect to 193.x.y.29 (which is the only address that even responds at all). Although I can ping 193.x.y.29, when the VPN3 client tries it the icmp trace gives “Outbound ICMP unreachable (code 3) 172.x.y.2 > 193.x.y.29 > 168.x.y.z”

I assume that it doesn’t work because it cannot negotiate a connection. What access-list etc do I need to set up? I have tried all sorts of combinations of the following with no success.

access-list 100 permit ip any host 193.x.y.29

access-list 100 permit udp any host 193.x.y.29 eq isakmp

access-list 100 permit tcp any host 193.x.y.29 eq 50

access-list 100 permit tcp any host 193.x.y.29 eq 51

access-list 90 permit udp any host 193.x.y.29 eq isakmp

access-list 90 permit tcp any host 193.x.y.29 eq 50

access-list 90 permit tcp any host 193.x.y.29 eq 51

access-list 90 permit ip 172.x.y.0 255.255.255.0 10.1.2.0 255.255.255.0

I’m a bit lost now – I thought VPN with Cisco would be quite straightforward.

Thanks

Michael

[pdentico]

You don't need the following access-lists:

access-list 100 permit ip any host 193.x.y.29

access-list 100 permit udp any host 193.x.y.29 eq isakmp

access-list 100 permit tcp any host 193.x.y.29 eq 50

access-list 100 permit tcp any host 193.x.y.29 eq 51

access-list 90 permit udp any host 193.x.y.29 eq isakmp

access-list 90 permit tcp any host 193.x.y.29 eq 50

access-list 90 permit tcp any host 193.x.y.29 eq 51

You only need this one:

access-list 90 permit ip 172.x.y.0 255.255.255.0 10.1.2.0 255.255.255.0

They are not keeping it from working but let's try to clean up a bit.

Everything looks right otherwise. Can you get those debugs? They are the best way of troubleshooting.

Also how is the client PC connected to the Internet? That might also help to know.

[mburnford]

Many thanks.

Here are debug traces:

This is when trying from the VPN3 client...

REAPER_TIMER

PEER_REAPER_TIMER5: ICMP unreachable (code 3) 172.x.y.2 > 172.x.y.1

6: ICMP unreachable (code 3) 172.x.y.2 > 172.x.y.1

7: ICMP unreachable (code 3) 172.x.y.2 > 172.x.y.1

...and simple pinging from the client computer...

PEER_REAPER_TIMER

PEER_REAPER_TIMER

PEER_REAPER_TIMER8: Inbound ICMP echo request (len 32 id 5 seq 256) 62.x.y.135 > 193.x.y.29 > 172.x.y.2

9: ICMP unreachable (code 3) 172.x.y.2 > 172.x.y.1

10: Inbound ICMP echo request (len 32 id 5 seq 512) 62.x.y.135 > 193.x.y.29 > 172.x.y.2

11: ICMP unreachable (code 3) 172.x.y.2 > 172.x.y.1

12: Inbound ICMP echo request (len 32 id 5 seq 768) 62.x.y.135 > 193.x.y.29 > 172.x.y.2

13: ICMP unreachable (code 3) 172.x.y.2 > 172.x.y.1

14: Inbound ICMP echo request (len 32 id 5 seq 1024) 62.x.y.135 > 193.x.y.29 > 172.x.y.2

15: ICMP unreachable (code 3) 172.x.y.2 > 172.x.y.1

PEER_REAPER_TIMER

PEER_REAPER_TIMER

PEER_REAPER_TIMER

172.x.y.1 is the PIX inside interface, 172.x.y.2 is the NIC in the server.

The client is Win2000Pro with dial-up to ISP. I have tried different ISP including Compuserve. I connect to the ISP then run the VPN client.

One thing I notice is that the outside of the PIX is connected to a Cisco 2500 router provided by the ISP (UUNET) which connects to the 64k kilostream line. When talking about IKE mode config the Cisco documentation says the router needs to permit IKE Mode Config, and that version of router does not allow this. However, they tell me that as the router is doing nothing more than passing it all through, this is irrelevant. What does it all mean?

The ISP has opened ports/protocols 500, 50 and 51.

Michael

[cjacinto]

Make sure you have the proper acl (extended acl):

nat (inside) 0 access-list 110

access-list 110 permit ip 172.x.y.0 255.255.255.0 10.1.2.0 255.255.255.0

Then capture the following debugs on the PIX:

debug crypto isakmp

debug crypto engine

debug crypto ipsec

Compare your config on the PIX and client from:

http://www.cisco.com/warp/customer/110/pix3000.html

Once you get the output of the debugs compare them on the one list on the sample as well. It would tell you what is not matching on Phase 1. I suspect that it is actually passing phase one but failing Phase 2 (IPSec).

From the client make sure you are trying to ping the 172.x address rather than the 193.x address.