Full IPSec tunnel

Netstudent

We have a remote site that uses our internet feed. They connect back to us on a Full T, but we are changing over to MPLS. During the interim I need to create a site-to-site VPN with the ASA, but I need to tunnel everything. All of thier traffic destined for our internal services, as well as their internet traffic needs to be tunneled to our network.

My question is, if I want to fully tunnel everything, including internet traffic, should I just create an ACL that defines the source network to any destination on the remote side? Then default route towards the ASA.

That seems like the most logical move.

dtlokee

The proxy acl should simply be "permit ip any any" in the ASA.

Netstudent

dtlokee wrote:

The proxy acl should simply be "permit ip any any" in the ASA.

What about on my side..The ACL's will have to match and I can't do permit ip any any on my side. I can't tunnel all my traffic back to them. Wouldn't it be a better configuration to define their network in the acl's?

Ahriakin

I usually do (local subnets) -> (Any) on the satellite site, and the reverse on the hub. Also is your Hub VPN endpoint your Internet gateway? If so you'll need to enable same security traffic on that interface and create an outside->outside nat rule for the remote subnets (outside->in will be handled by your existing inside Nat0 rule for the remote subnets).
If you have multiple subnets on the other side it's best to put them into an object-group, that way you can use the same object-group in your encryption and NAT ACL's (and if you have specific standard firewall ACL rules to only allow specific private subnets in and out of the interfaces), besides saving you time on the initial creation of the rules (since you can't use the same ACL for 2 functions but you can use the object-group as much as you like) it makes changes later much easier, you just add or remove subnets from the object-group and you affect all rules that apply to them at once.

dtlokee

do you have another interface you can apply a different crypto map to for the the tunnel back to the remote site? Or perhaps you could put in deny statements for all the subnets at the other remote sites.