Cisco PIX vpn and vpn client

Dec 15, 2006 5 Replies

I have cisco pix 501 with IOS 6.3(4). and running Cisco VPN client 4.6.04.config is IPSEC over UDP I have a linksys router behind which the pix sits, I have forwarded UDP port 4500, 500, 10000, 50 to the pix. for some reason the vpn client connects from some internet connections and from some it does not and I do not get any error messages.



I have attached the log file from the vpn client, when it was not connecting. Thanks for the help.



MC


--------------------------------------------------------------------------------------------------------------------------



1 23:42:27.997 12/14/06 Sev=Info/6 IKE/0x6300003B Attempting to establish a connection with 71.78.123.220.


2 23:42:28.017 12/14/06 Sev=Info/4 IKE/0x63000013 SENDING >>> ISAKMP OAK AG (SA, KE, NON, ID, VID(Xauth), VID(dpd), VID(Nat-T), VID(Frag), VID(Unity)) to 71.78.123.220


3 23:42:28.037 12/14/06 Sev=Info/4 IPSEC/0x63700008 IPSec driver successfully started


4 23:42:28.037 12/14/06 Sev=Info/4 IPSEC/0x63700014 Deleted all keys


5 23:42:33.034 12/14/06 Sev=Info/4 IKE/0x63000021 Retransmitting last packet!


6 23:42:33.034 12/14/06 Sev=Info/4 IKE/0x63000013 SENDING >>> ISAKMP OAK AG (Retransmission) to 71.78.123.220


7 23:42:38.041 12/14/06 Sev=Info/4 IKE/0x63000021 Retransmitting last packet!


8 23:42:38.041 12/14/06 Sev=Info/4 IKE/0x63000013 SENDING >>> ISAKMP OAK AG (Retransmission) to 71.78.123.220


9 23:42:43.048 12/14/06 Sev=Info/4 IKE/0x63000021 Retransmitting last packet!


10 23:42:43.048 12/14/06 Sev=Info/4 IKE/0x63000013 SENDING >>> ISAKMP OAK AG (Retransmission) to 71.78.123.220


11 23:42:48.055 12/14/06 Sev=Info/4 IKE/0x63000017 Marking IKE SA for deletion (I_Cookie=7C22991E7FF28FA8 R_Cookie=0000000000000000) reason = DEL_REASON_PEER_NOT_RESPONDING


12 23:42:48.556 12/14/06 Sev=Info/4 IKE/0x6300004B Discarding IKE SA negotiation (I_Cookie=7C22991E7FF28FA8 R_Cookie=0000000000000000) reason = DEL_REASON_PEER_NOT_RESPONDING


13 23:42:48.596 12/14/06 Sev=Info/4 IKE/0x63000001 IKE received signal to terminate VPN connection


14 23:42:48.626 12/14/06 Sev=Info/4 IKE/0x63000086 Microsoft IPSec Policy Agent service started successfully


15 23:42:49.067 12/14/06 Sev=Info/4 IPSEC/0x63700014 Deleted all keys


16 23:42:49.067 12/14/06 Sev=Info/4 IPSEC/0x63700014 Deleted all keys


17 23:42:49.067 12/14/06 Sev=Info/4 IPSEC/0x63700014 Deleted all keys


18 23:42:49.067 12/14/06 Sev=Info/4 IPSEC/0x6370000A IPSec driver successfully stopped



-----------------------------------------------------------------------------------------------------------------------------------------



It doesn't use UDP port 50: it uses IP protocol 50 (ESP), which is a protocol in the same sense that TCP and UDP are protocols.

let me clarify. I have forwarded UDP port 4500, UDP 500, TCP 10000, and Tcp and UCP 50. I understand that 50 is ESP, but on my linksys there is no place to forward protocol numbers. But the issue is from some internet connections I am able to connect to VPn and from some I am not able to.

Thanks

MC

let me clarify. I have forwarded UDP port 4500, UDP 500, TCP 10000, and Tcp and UCP 50. I understand that 50 is ESP, but on my linksys there is no place to forward protocol numbers. But the issue is from some internet connections I am able to connect to VPn and from some I am not able to.

Thanks

MC

protocol 50 (ESP), which is

let me clarify. I have forwarded UDP port 4500, UDP 500, TCP 10000, and Tcp and UCP 50. I understand that 50 is ESP, but on my linksys there is no place to forward protocol numbers. But the issue is from some internet connections I am able to connect to VPn and from some I am not able to.

Thanks

MC

protocol 50 (ESP), which is

There is no poinnt forwarding TCP and UDP 50, they will not add anything.

If you cannot get IP protocol 50 (ESP) through, then your VPN connections

*require* the NAT-traversal mechanisms, incoming UDP 500 and UDP 4500, and outgoing UDP 500 and some random UDP port (the mechanisms use a pair of undirectional UDP streams with fixed destination ports, instead of the more typical random source port that has to be replied to.)

Conversely, the places that fail are likely ones which do not support NAT-T on the client, or in which UDP 500 or UDP 4500 cannot get through.

Also, if your Dlink is not letting -outgoing- ESP (IP 50) through out of your PIX, I believe the connection could fail if the other end is *not* being NAT'd. NAT-T is negotiated independantly in the two directions, with UDP 4500 being sent to as the destination on each side that -is- NAT'd, but if a side is -not- NAT'd then the other side will try to send regular ESP to it. The negotiation mechanisms take place before any ESP has been attempted, and so do not know whether ESP will make it through or not; it's a bit of a flaw in the protocol.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required