PIX VPN using external addresses

We have a company that has a policy against using internal IPs in their IPSec tunnels. Can someone give me the basic PIX config differences for using the external IPs as opposed to the internals? All of our current tunnels use the internal IPs and several attempts at using the externals haven't gone very well.

Thanks in advance.

Reply to
Nate
Loading thread data ...

you can use the NAT and global comands

M.Ammoura

Reply to
Heart Key

In article , Nate wrote: :We have a company that has a policy against using internal IPs in their :IPSec tunnels. Can someone give me the basic PIX config differences :for using the external IPs as opposed to the internals? All of our :current tunnels use the internal IPs and several attempts at using the :externals haven't gone very well.

It's not so bad, really.

The first thing is to reconfigure your ACLs to match the traffic to the remote system, in the usual way, just as if it were not tunneled. You can skip this step if you are using sysopt connection permit-ipsec to bypass interface ACL checking for IPSec.

Then put appropriate global and nat statements, or static statements. You might use "policy nat" or "policy static" if you want the translation to be distinct for the VPN.

Then you ensure that the remote network is not matched by your nat 0 access-list ACL.

Next is to configure the ACL for the crypto map match address clause so that the "source" address is the *post-translation* address -- the address the PIX will translate outgoing packets -into-.

Set the "destination" address in that ACL to be the pre-translation remote IP -- the IP as would be in flight towards you before it hit your PIX's interface. This is, to be clear, almost always the same as the "just plain" remote IP, and the distinction between whether it is pre-translation or post-translation only matters if you are doing "reverse nat" [or in the odd situation where your VPN is connected to an interface with a -higher- security level than your inside interface.]

If you don't know what "reverse nat" is, then what remember is that the crypto map match address ACL "destination" must be in terms of the external IP addresses of the remote system, not the internal addresses. [Normally it would use the internal addresses, but you're deliberately not using internal addresses ;-) .]

Once the above is done, clear the ipsec sa's and you should be in business.

There's a lot of flexibility in the order you do the steps; the order I chose above was selected to try to mimimize vulnerability windows, but if the vultures aren't waiting at the gate then the order almost doesn't matter.

Reply to
Walter Roberson

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.