Connectivity to VPN 5000 fails when going through router w/ NAT& CBAC

[ssanders]

I'm trying to have clients behind a 2610 router connect to a remote site via the internet using the VPN 5000 client. I can connect to the remote site's concentrator without using NAT transparency mode. However no packets show being exchanged within the client statistics. Plus I can access no resources on the remote network. I do however get an IP address assignment from the concentrator. I have no idea why this connection is successful since the router is configured to NAT everything going out.

The valid connection config is to use NAT transparency mode. This works fine outside our router and all resources can be accessed. So, something is blocking on our router. I have other remote networks we connect to using Cisco's VPN client 3.6.3. These connections all work fine behind our router. The only difference is the transparency mode is doing encapsulation over UDP as opposed to TCP. I've tried adding the necessary port (80) in my outside access-list on the router to no avail. Can someone tell why encapsulation over UDP works and TCP doesn't?

[gfullage]

The VPN5000 with NAT Transparency encapsulates the IPsec packets into TCP port 80 packets, so to any other device they look like HTTP packets.

On the router doing CBAC, are you inspecting HTTP packets? If so, the router is going to look at these more closely, see that they're not really HTTP packets and it'll probably drop them. Turn off HTTP inspection and see if it works then. There's really no need to inspect HTTP packets anyway, mostly it just causes more trouble than it's worth and most people end up turning it off.

As for why the tunnel is built successfully WITHOUT NAT Transparency, that's becuas ehte tunnel is built using ISAKMP, which is UDP port 500 packets, these are NAT'd fine by any NAT device. When you actually start trying to pass data over the tunnel, this is ESP which is IP protocol 50, this is where most NAT devices fail cause there's no TCP/UDP port in them. That's why you can build the tunnel but not pass traffic.

The answer is to use NAT Transparency, but you need to make sure the CBAC router isn't dropping them.

If you really, really, really want or need to inspect HTTP packets on the router but still need to get the NAT Transparency to work, you can use the "NATTransport" variable in the General section of the VPN5000 concentrator to change the default NAT Transparency port to something other than 80. Then specify that same number on the VPN5000 client and you should be able to connect properly with another TCP port that the CBAC router won't inspect too much.

[ssanders]

I removed the HTTP inspect command and was still unable to connect to the remote site's VPN concentrator using transparency mode with port 80. I then tried completely removing CBAC off the inside interface. I still was unable to connect. I then tried it with the outside interface access-list removed. Still I could not connect. I do not know what else could be blocking the connection on our router. The only other thing configured besides NAT/CBAC is IPSEC for VPN access into our network. I would not think this would have any effect on connections originating from inside our network to the client's remote site.

Are there any known compatibility issues with the VPN client software were using VPN 5000 ver 5.2.3 DES and our Router IOS version 12.2.8(T)?

Also since we have other customer sites we access, I also have Cisco VPN secure client 3.6.3 loaded on the desktops as well. Connections to remote sites using this client always works. Could there be an issue with having both Cisco clients on the PC?

As I said the connection alway works fine outside our router. It doesn't work inside our router.

I'm stumped, I would be grateful for any other ideas someone may have.

[minmei]

Could it be PAT? If the IKE stuff (negotiation, tunnel building) is working over UDP port 500, using port address translation from inside your firewall will work since you initiated the connection and the negotiation is on the same port. However, when the remote site starts sending you esp traffic (encapsulated packets) your firewall can't figure out which internal PC to deliver them to because it's not related to the UDP 500 port you got initially.

Try a static address for the machine on the inside.

Just a thought,

Chad