Site to Site VPN Setup Questions

[heather.burke]

I have been working with another agency to set up a site to site VPN.  During the course of this, we have run into several areas

where I  fail to understand what they are saying.  I have never done this before, but some of what they are saying is challenging some of my basic conceptions of how this process works, so I thought I would throw it out there and see what comes back.

Right now, we have a dynamic PAT to access the internet.  To get our VPN traffic routed correctly, it would have to be outside of this, obviously.  It was suggested that I put in Static NAT entries to tell that traffic how to be handled.  The other agency has come back and said that this would send all that traffic in an unencrypted manner, outside of the tunnel.  Is this true?

They also said that the only way to get VPN traffic to be routed correctly is to put a route on the internal switch, which would tell it where to go when it hits the firewall.  I do not understand this.  Isn't it on the ASA itself that it has to recognize which traffic to encrypt and which traffic not to?  Why would the internal switch have anything to do with that?  Since the traffic will come in an internal interface and leave via the external interface (albeit encrypted) the route should remain the same, shouldn't it?   The tunnel would still take the same physical route to the endpoint, only encrypted, and then unencrypted at the specificed endpoint.  They speak about it as a subinterface, which although setup for the VPN traffic, still travels through the external interface, right?

Any help clearing up my confusion would be appreciated.  I feel like I'm missing a major part of the picture here.

[Collin Clark]

heather.burke wrote:
I have been working with another agency to set up a site to site VPN.  During the course of this, we have run into several areas
where I  fail to understand what they are saying.  I have never done this before, but some of what they are saying is challenging some of my basic conceptions of how this process works, so I thought I would throw it out there and see what comes back. 
Right now, we have a dynamic PAT to access the internet.  To get our VPN traffic routed correctly, it would have to be outside of this, obviously.  It was suggested that I put in Static NAT entries to tell that traffic how to be handled.  The other agency has come back and said that this would send all that traffic in an unencrypted manner, outside of the tunnel.  Is this true? 
They also said that the only way to get VPN traffic to be routed correctly is to put a route on the internal switch, which would tell it where to go when it hits the firewall.  I do not understand this.  Isn't it on the ASA itself that it has to recognize which traffic to encrypt and which traffic not to?  Why would the internal switch have anything to do with that?  Since the traffic will come in an internal interface and leave via the external interface (albeit encrypted) the route should remain the same, shouldn't it?   The tunnel would still take the same physical route to the endpoint, only encrypted, and then unencrypted at the specificed endpoint.  They speak about it as a subinterface, which although setup for the VPN traffic, still travels through the external interface, right? 
Any help clearing up my confusion would be appreciated.  I feel like I'm missing a major part of the picture here.

You want to prevent NAT for traffic crossing the tunnel. Depending on the version of OS you're running, there are a couple of ways to do this. It's typically called NAT exempt or NAT 0. You will need a route in your network stating how to get ot the remote network, most people put this on the core router/switch. You are correct about all traffic leaving the outside interface/route.

[heather.burke]

I think that that is what they are suggesting, by putting the route on the internal switch.  However, what other way is there to get anywhere, except than by going through the ASA?  Is that just because you are putting the route from the internal route to the ASA, and the ASA does the rest?

Yes I believe that NAT that I did was an exception to teh dynamic PAT, but I don't see why that would prevent traffic from going to the vpn?

[Collin Clark]

I think I understand what you are getting at. Since the ASA is the default gateway for your entire network why enter a specific route when it has to hit the ASA anyway? Good question and you don't. However I do like being able to "see" the remote network in my routers. A friendly reminder that that network is not available for my use.

[heather.burke]

Ok, that makes sense.  It is being suggested that the whole reason that our VPN is not working is that this is not set up.  We have a L2 switch, and I do not believe it handles routing functions at all.  I have a hard time believing that if we had a router there instead, that the tunnel would magically work.  However, I am new to this process, so I am open to things that challenge what I believe to be true.

[Collin Clark]

You are correct so stand your ground! Since you only have the L2 switch and an ASA ask them where you should put the route ;-)

[heather.burke]

LOL!  Do you require a static route to the server addresses of the VPN?  I was always thinking that in the VPN setup itself, it would handle routing of information to the tunnel.  Therefore, all data to 10.0.0.0 would always enter the tunnel, and all traffic destined for other external destinations would continue on its way.  Is that not the case?  That's why it was suggested that perhaps all external bound traffic was being sent out with the dynamic PAT, or perhaps with the one static route that we have, which is the any traffic out to the external switch route.  (I can see how that route might be a problem, since perhaps the external traffic would all be lumped together)

I was also told that allowing the ASA to do this routing would burn it out quickly, but I don't see why this would be the case either.  Firewalls started out as routers.  Allowing them to handle a certain amount of routing functionality should not be detrimental to their health.  (especially in our case where we really don't have a huge load demand)  My boss keeps asking wehter or not it will be true that we need to purchase a router for this, but I still just don't see it.

[Collin Clark]

heather.burke wrote:
LOL!  Do you require a static route to the server addresses of the VPN?  I was always thinking that in the VPN setup itself, it would handle routing of information to the tunnel.  Therefore, all data to 10.0.0.0 would always enter the tunnel, and all traffic destined for other external destinations would continue on its way.  Is that not the case?  That's why it was suggested that perhaps all external bound traffic was being sent out with the dynamic PAT, or perhaps with the one static route that we have, which is the any traffic out to the external switch route.  (I can see how that route might be a problem, since perhaps the external traffic would all be lumped together)
 I was also told that allowing the ASA to do this routing would burn it out quickly, but I don't see why this would be the case either.  Firewalls started out as routers.  Allowing them to handle a certain amount of routing functionality should not be detrimental to their health.  (especially in our case where we really don't have a huge load demand)  My boss keeps asking wehter or not it will be true that we need to purchase a router for this, but I still just don't see it.

The route to the server address is a maybe. It was common to need it in the PIX, but the ASA seems to be smarter and you need it less. Worst case put it in and see if it helps. It used to look like this~

route outside 192.168.50.0 255.255.255.0 [IP address of the remote VPN]

The ASA can route just fine. If you start talking 20+ interfaces (interfaces not routes!) then we need to talk further, but with what you're doing it will not be a problem. Go ahead and have your boss get that router. It will be a good start to a lab!

[heather.burke]

I notice that you can specify a default tunnel gateway for a route, which is different than the standard default gateway.  Would doing that help?  If so, what is the tunnel gateway?  The start point or the endpoint or neither?

According to the document I copied below, it would seem as though that might be the ticket, but I'm not sure.  Would doing that ensure that VPN traffic is routed better than a traditional static route (I note it mentions below that static routes are handled first)  It loses me a bit when it talks about floating metrics, though.

Users can enter static routes in the same format as Cisco PIX® to configure routes. Users will have the option to configure two default gateways, one with a "tunneled" option and one without. All traffic that arrives at the appliance and cannot be routed using learned routes or static routes will be routed through default gateways. If the traffic was encrypted when it initially arrived at the appliance, it will be routed through Default Tunnel Gateway (DTGW); otherwise, it will be routed through Default Gateway (DGW). A set of default gateways can be installed for each virtual context.

The IP routing subsystem routes data packets first using learned routes, then static routes, then the default gateway. If a default gateway is not configured, packets that cannot be routed to another host will be dropped. Also, a tunnel default gateway is specified, which is a separate default gateway for tunneled traffic only. A switch to let the default gateways learned through routing protocols override the configured default gateways is provided through the usage of floating metric. If a static route needs to be overridden by a route found by a routing protocol, it is specified with a maximum possible metric. In that case, when a route is found by Routing Information Protocol (RIP) or Open Shortest Path First (OSPF), it overrides the statically configured route.

[Collin Clark]

Can you post the link from where you got this?

Also, for reference here is a great VPN troubleshooting link.

http://www.cisco.com/en/US/products/ps6120/products_tech_note09186a00807e0aca.shtml

[heather.burke]

Sure, here it is:

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6635/ps6659/prod_white_paper0900aecd805f0bd6.html

Our tunnel is now up!  After doing some research, they discovered that I was correct about how I was configuring things.  They had to change a couple of things on their side, and presto, we are now connected!  Thanks so much for your help!

I'd still be interested in your take about the vpn default gateway thing, since it seems like it might be a "good to know" thing.

[Collin Clark]

Glad to hear the tunnel is up and working. The link you sent is for EasyVPN which is a whole different beast and in this particular article the route command is needed because the VPN gateway is on a stick.

As far as the routing commands with the VPN endpoint as the gateway, it is in the link above, but here it is with an anchor to the routing point.

http://www.cisco.com/en/US/products/ps6120/products_tech_note09186a00807e0aca.shtml#solution16