Force UDP Encapsulation for VPN Client without NAT

[jealvarez]

We need to access a PIX running 6.3(4) from a PC with VPN client 4.0.5. The PC is on a public IP so UDP encapsulation or NAT traversal would normally not be required. Unfortunately, one of the routers on the way to the PIX is blocking ESP (IP protocol 50) and we have no control over it. If we force the PC to use NAT (placing a NAT device in front of it), the IPSEC link works fine because the IPSEC traffic gets encapsulated over UDP. If we do not use NAT, the tunnel is established but no there is no traffic due to the ESP block.

We would like to keep the PC on its regular public IP. Is there a way to force UDP encapsulation on a connection where the client does not use NAT? Are there any other alternatives for cases where ESP is being blocked?

Thanks.

[jealvarez]

I checked with Cisco on this today. The response was that forced UDP encapsulation is only available with the VPN 3000 concentrator. So, on connections from the VPN client to a PIX only the automatic mode is implemented. The alternative in cases where ESP is blocked is to use NAT to (indirectly) enable UDP encapsulation.

Cisco should consider adding an option to force UDP encapsulation to the VPN client. Other VPN clients (like Checkpoint's SecuRemote) offer that option. It is useful on cases where ESP is blocked somewhere in the path.

[jpearson]

To Cisco,

This problem also occurs with router to router configurations when ESP is blocked by an corporate firewall and no NAT occurs. Router to VPN3000 also fails since the ESPs are dropped. The only current way is to add an extra router to force NAT translation. I've tried implementing both IPSec and NAT in the same device, but does not appear to work, since IPSec bypasses NAT when both are in the same box.