L2L VPN Questions: xlates? no sysopt permit ipsec?

slug420 · ‎04-29-2009

setting up a L2L vpn from a 5510 to someone else's Checkpoint and I have a couple questions.

First of all if we are using static nat...translating our private addresses to public addresses...should the encryption domain reflect the translated or untranslated IP?

If the host they will be connecting to using the VPN is 192.168.1.1 an the public address is 4.4.4.4....and lets say the IP on their side is 3.3.3.3....

My encryption domain would be:

access-list encdomain permit ip host 4.4.4.4 host 3.3.3.3

is this right? The packet arrives, consults routing tables, determines which interface it will be leaving from, undergoes any relevant translations, then looks for a VPN that it matches?

Another question...the only way for me to control on my end what traffic comes over a L2L vpn tunnel is to not use sysopt connection permit ipsec, but rather leverage access-lists on the external interface of the firewall to control what traffic can enter our environment (with syopt connection permit-ipsec in place all traffic bypasses that ACL).

So my next question is how do people handle this on VPNs that are using public IPs? I dont know why but our partner insists on using public IPs to hide their VPN encrypter hosts, and will only connect to hosts at our side if we NAT them to public IPs.

So what this means is we have an ACL on our external interface allowing traffic from routable_IP_remote to routable_IP_local...so if something gets screwed up in the future and the tunnel no longer works because a setting was tweaked on one end but not the other...no one would know about it and the traffic would still flow over the public internet without a VPN tunnel since all the translations and access-lists are in place.

How do you mitigate this?

The only solution I can think of is blocking all traffic EXCEPT that of the vpn peer on your upstream router...but that only works if you have a dedicated VPN firewall (you cant block all traffic to your firewall's IP if you are also using it as the hide-nat for outgoing traffic for example).

This seems like such a weak solution...requiring ACLs on an upstream ROUTER (note router, should be used to route not to filter packets) in order to secure connectivity to your FIREWALL (note firewall, security appliance which should be capable of securing itself).

How do you handle this situation???

Jon Marshall · ‎04-29-2009

Chris

"First of all if we are using static nat...translating our private addresses to public addresses...should the encryption domain reflect the translated or untranslated IP?"

You should use the translated addresses not the real addresses.

"So what this means is we have an ACL on our external interface allowing traffic from routable_IP_remote to routable_IP_local...so if something gets screwed up in the future and the tunnel no longer works because a setting was tweaked on one end but not the other...no one would know about it and the traffic would still flow over the public internet without a VPN tunnel"

No it won't. Because you have included the public IP addresses in the access-list for interesting traffic ie. the crypto-map acl and not the acl on an interface, the ASA knows that any traffic from or to these public IP's must be encrypted. So if traffic from this public IP arrived on your outside interface unencrypted the ASA would drop it.

However if you removed the crypto map entry or the acl that defines the interesting traffic then yes that could be a problem.

Jon

acomiskey · ‎04-29-2009

Well said, firewall master!

Jon Marshall · ‎04-29-2009

Adam

Compared to you i am still a mere novice :-)

Only reason i'm ahead of you is you have been absent for quite a while.

Jon

slug420 · ‎04-29-2009

"No it won't. Because you have included the public IP addresses in the access-list for interesting traffic ie. the crypto-map acl and not the acl on an interface"

In my case I do actually have the ACLs applied to an interface. I have them applied to the external interface that the tunnel is being built on so that it (along with 'no sysopt connection permit-vpn') can control what traffic comes in through the tunnel.

I believe what you are staying holds true somewhat though. If the tunnel is built and traffic comes in on the outside interface it will be denied due to some syslog message like "%PIX|ASA-4-402117: IPSEC: Received a non-IPSec (protocol) packet from

remote_IP to local_IP"

I believe I have found in my testing however that if the tunnel is not built at the time the traffic comes in this traffic will not be denied.

So our partner has an ACL on their inside interface allowing 192.168.1.1 to connect via the tunnel to 4.4.4.2 on my side.

Once it has been allowed in their inside interface it gets translated to 3.3.3.2 which then shoots out over the tunnel to my FW where it is allowed in since I have a "permit ip host 3.3.3.2 to 4.4.4.2" line in my outside interface ACL.

If for example someone removed the transform set being used by this tunnel and the tunnel cannot be created the next time this traffic comes through....

They have a 192.168.1.1->3.3.3.2 static inside:outside so it gets translated and it got allowed in by the same ACL on the internal interface as the other traffic.

Now when it gets to me, there is no existing built tunnel...but I have an ACL on my external interface allowing traffic in from 3.3.3.2->4.4.4.2 and a translation converting 4.4.4.2 to 192.168.2.2 (my inside host) and so the traffic gets through.

If im not mistaken the only way the above will not work is if the remote firewall does not pass the traffic since it matched an ACL for a crypto map but the tunnel could not be built. This does not help me however since during that time that the tunnel is down, anyone on the internet could spoof a packet from 3.3.3.2 and it would get right in through my FW.

Am I wrong?

Jon Marshall · ‎04-29-2009

Chris

"In my case I do actually have the ACLs applied to an interface."

Apologies, i meant to say that you have the public IP's in both your crypto map acl and also the acl applied to your outside interface.

From testing i did with pix v6.x a while back the tunnel did not need to be active for this behaviour to happen. As long as the crypto map acl line covers the traffic for the same IP's in the acl then the firewall should drop the traffic.

Unfortunately i don't have an ASA to test with but this was definitely the behaviour previously and i haven't seen anything that says it has changed.

Jon