VPN 5000 Client Connection Through PIX 520

it · ‎12-02-2002

I have several users who need to connect to an external client's VPN utilizing the VPN 5000 client. We have a PIX 520 as our firewall, but it also terminates ipsec connections for our external users

.

I've given our internal users the appropriate static IPs and allowed IKE and ESP. I've even gone so far as to allow ANY traffic to the external client's VPN box to our user IPs. No luck. The connection times out. Looking at my logs, the PIX attempts to make the connection, but ultimately tears it down with a SYN Timeout message. Any ideas?

Thanks!

gfullage · ‎12-02-2002

The VPN5000 clients are on the inside, and the concentrator is on the outside, is that right? What do you mean by "the PIX attempts to make the connection, but ultimately tears it down with a SYN Timeout message", the PIX shouldn't be making any connection in this scenario, it should just be passing the packets through, shouldn't it (I may have the wrong idea of what you're trying to do here)?

Are you using NAT Transparency on the clients (encapsulating the IPSec packets into TCP port 80 packets)? It doesn't sound like it since you mention that you're allowing IPSec and you've created static's for each internal client. But then you mention a SYN Timeout, which indicates TCP connections are going on somewhere.

If you're doing NAT Transparency, then there's a few bugs with older version of both the client code and the concentrator code to be aware of. Client versions before 5.0.12 sent the wrong ACK value in the 3rd TCP handshake packet, and the PIX would see this as invalid (being the good stateful firewall that it is) and drop it, so the connection would never get started.

Once that was fixed in the client, the connection could now be established, but when the tunnel was brought down, the client would send a TCP FIN, the concentrator wouldtear down the tunnel but wouldn't send a FIN ACK back to the client. Again, the PIX saw this as the TCP connection not being closed down properly and left it active, and so if the client then tried to re-connect before the TCP idle time in the PIX, the PIX said no,no, there's already a connection existing for that, and you couldn't re-connect.

In short, make sure you're running > 5.0.12 client versions, and > 5.2.20 or 6.0.17 on the concentrator.

If you're running later client versions (5.1 or higher IIRC), you can actually specify the TCP port that NAT Transparency will use, but if you change it on the client, you also have to tell the concentrator to accept connections on that port too. You do this by specifying:

[General]

NATTransport=nn where nn is the TCP port number to use

(http://www.cisco.com/univercd/cc/td/doc/product/aggr/vpn5000/5000sw/conc52x/ref52x/sections.htm#xtocid63)

it · ‎12-03-2002

Correct, the clients are inside on the concentrator is outside. When I say that the PIX attempts to make the connection, I mean that it builds the connection for the inside to the outside as it details in the log. The PIX isn't managing the VPN5000 connection outside of building and tearing down the NAT connections.

We are using NAT transparency on the clients, and we are attempting to use an older version of the client. I'll upgrade the client and try again. I'll let you know how it turns out! Thank you VERY much for your detailed analysis!