Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

PIX and IPsec over TCP

The only documentation I can find suggests using a VPN Concentrator to allow clients to use the IPsec over TCP configuration from their VPN client software, rather than a PIX.

My client wants to allow consultants who are behind their own firewall to have VPN access to their network, but NAT issues are raised (NAT at the consultants end).

Any ideas on whether a) the PIX (6.2) now supports this, or b) an alternative?

Thanks,

Mike.

2 REPLIES
Cisco Employee

Re: PIX and IPsec over TCP

Current 6.2 of the PIX doesn't support IPSec over tcp yet. This is only being supported on the VPN 3000 as the vpn head end.

New Member

Re: PIX and IPsec over TCP

Hello Mike,

Ask your consultants whether they are using one-to-one NAT or PAT (hiding address) at their site. If they are using one-to-one, you can set up the VPN. Recently, I had similar problems, and I can summarize my findings in the following three cases:

First case - No NAT

This is the case where client is using DialUp, Cable or ADSL to connect to local ISP and receives an official IP address. No NAT is being used. In this case everything is perfectly OK.

Second case - one-to-one NAT translation at the client side (after IPSec):

In this case, VPN client is sitting behind Firewall which performs One-To-One NAT translation (in PIX terminology – Range). In this case, IPSec VPN tunnel is established, but no further traffic is possible. Here is complete process:

1. VPN client initiates connection from behind remote firewall to headend firewall on IKE/UDP 500 in order to establish the IPSec tunnel. Translation for this connection is properly built on remote firewall.

2. Returned traffic from headend firewall to VPN Client (IKE/UDP 500) is permitted by remote firewall because connection is initiated from behind remote firewall. After negotiating security policy between VPN Client and headend firewall, IPSec tunnel is established.

3. VPN Client is now trying for example to connect to some web server inside headend network. Traffic is encrypted on the VPN Client site and sent out to headend firewall. However, returned traffic is blocked by inbound rules od remote firewall. This is ESP traffic (IP protocols 50). Workaround is to permit ESP inbound traffic on remote firewall:

conduit permit ip any any esp

Third case: Many-to-one translation (PAT) at the remote site

In this case, everything is the same as scenario 2, except that remote firewall in front of VPN Client is performing PAT, and not NAT. In this case, it is not even possible to establish the IPSec tunnel. In Syslog of headend there is a message: Deny inbound (no xlate) udp/500. Even with the rule allowing UDP/500 it does not work.

Hope it helps.

Sasa

181
Views
0
Helpful
2
Replies
CreatePlease login to create content