Cisco PIX vpn and vpn client

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

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

Reply to
RTR
Loading thread data ...

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.

Reply to
Walter Roberson

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

Reply to
RTR

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

Reply to
RTR

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

Reply to
RTR

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.

Reply to
Walter Roberson

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.