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
