VTI with IPSec behind ASA

[brandonbittinger]

Hello all,

I am looking into using a router at a remote site and a router at a the main site behind an asa to create a VPN using Virtual Tunnel Interfaces on each router. I plan on securing the tunnel with IPSec. 

I am not 100% sure how the Virtual Tunnel Interfaces work. I know I can secure them with IPSec but I also know you can use GRE and secure the GRE tunnel as well. 

My question is what ports will need to be forwarded through the ASA in order to allow the tunnel to connect through it?

Any help is greatly appreciated!

[Karsten Iwen]

It depends on your addressing what needs to be allowed and forwarded on the ASA.

I assume that the router will have a public IP on his interface, then you have to forward and allow udp/500 and udp/4500. That's all that is needed.

[brandonbittinger]

The router will likely have a private address that is NATed to a public address. Or would that not work for this scenario? It would be a 1 to 1 NAT and the external address would only be used for the purpose of this tunnel. 

[Karsten Iwen · Accepted solution]

That will work. In case of 1:1 nat, allow UDP/500, UDP/4500 and if you want PING for troubleshooting in your outside ACL. That's all you need.

[brandonbittinger]

The router I am planning on using is current the hub for all of our Metro E connections as well as connecting a few sites that has Microwave connections. So if any traffic is coming from a Metro E connected site or a Microwave connected site it passed through this router to get to internal resources within the main building. 

Am I able to use the interface on this router that is connected to the inside of the network to send the tunnel traffic out through or will that class with the traffic trying to get to the web through the Metro E and Microwave connections? I am assuming that this could cause traffic from those remote sites to be NATed to the external IP of the tunnel. Or is that not correct? I am guessing that it would look at the source address and use the NAT pool like normal but I wanted to make sure. 

Thanks for the help!

[Richard Burts]

Perhaps we need a better understanding of the topology and of the data flows. Based on the other thread I am assuming that this router has a Metro E connection to multiple sites and that you are thinking about establishing the VTI tunnel to provide a backup connection to one of the sites. You are currently running EIGRP over the Metro E to each of the remote sites. You would plan to run EIGRP over the VTI to this remote site providing a backup path.

You would want to manipulate the EIGRP metrics so that the Metro E path was preferred. The VTI tunnel would always be up and EIGRP running over it, but with higher metrics so that when available traffic would flow over the Metro E path and if there is a problem with Metro E then traffic for the remote site would flow over VTI.

I am not sure where NAT comes into this. I assume that there is NAT on the ASA (and you would want to configure it so that the ASA does not attempt to translate the traffic of the VTI). Is there also NAT on the router?

HTH

Rick 

[brandonbittinger]

You are correct. The router in question currently has 3 connections, one to the Metro E, one to our Microwave tower, and the last to the local network. There is no NAT on the router, only the ASA. This is also the router I would like to add the VTI to that will then connect using the internal interface out through the ASA where NAT will make the traffic appear to be coming from a specified external IP address. 

I want all web traffic to pass through the main building to ensure it is filter by the web filter and firewall. I didn't bring this up in the last thread but realized later that our other method would not make the traffic pass through the Barracuda Web Filter that is running in inline mode between the ASA and core switch. Thus this VTI solution that terminates to a router inside the network connected to the core switch. 

I just wanted to verify that the traffic that is coming from the remote location over the VPN will be NATed corrected. When the traffic reached the ASA it will be NATed based on the original source address correct? I just wanted to make sure that the traffic is being NATed in the normal pool like all the other addresses and no being NATed to the external address I am using for the tunnel. I am pretty sure that it will be NATed normally through the ASA but I wanted to make sure. 

I hope this clears the situation up. Let me know if I missed anything of you need clarification. 

[Richard Burts]

There are still a couple of things that are not clear. You say that the router in question has 3 interfaces but none of what you describe in the connections seems to go to the ASA. Perhaps you can clarify? Also you mention a core switch but it is not clear where the core switch is in your topology.

I believe that NAT will not be an issue. It may be helpful to take a closer look at the address translation on the ASA and to be clear about the contents of a packet going through the VTI tunnel. With VTI (as with other tunneling technologies) there is the original IP packet with its source and destination addresses which is encapsulated in a new header which has the tunnel source and tunnel destination addresses. As the packet goes through the ASA the address translation will be done on the tunnel source or tunnel destination (depending on the direction of the packet) and will leave the original source and destination addresses without change. So when a packet from the remote gets to the router through the VTI tunnel, the router will strip off the tunnel header and then forward the packet using the original destination address (which has not been translated).

HTH

Rick

[brandonbittinger]

The topology is as follows: 

Internet -> ASA -> Barracuda Web Filter -> Core Switch 

The router in questions has one interface connected to this core switch. 

I think your explanation was what I was looking for. The original header will be left in tact and the packet will be translated as normal. I figured it would I just wanted to be sure. 

Thank you again for your assistance! You have been very helpful! 

[Richard Burts]

Thanks for clarifying the topology. If both the Metro E and the VTI tunnel are on the same router then it would be easy to manipulate the EIGRP metrics so that the Metro E path was preferred. In normal circumstances both connections to the remote would be active and EIGRP would choose the path over Metro E. If something disrupts the Metro E connection then the path via VTI will be used.

As packets in the VTI tunnel pass through the ASA the tunnel header address would be translated (source or destination depending on the direction the packet is going) while the original packet IP source and destination remain the same. So in the router, after the VTI header is removed, then forwarding of the packet would be the same whether it arrived via Metro E or via VTI.

If you do implement this please let us know how it works for you.

HTH

Rick

[brandonbittinger]

So EIGRP should prefer the Metro E route without any need to modify metrics, correct? And like you said if anything should happen to the Metro E route it will automatically start utilizing the VTI route and then flip back when the issue has been resolved and the Metro E is back online. 

I'll keep you posted on how the implementation goes. Thanks again for the help!

[Richard Burts]

I would expect the bandwidth reported for the tunnel to be lower than the bandwidth of the Metro E and so would expect the EIGRP metric to be less attractive over the VTI tunnel. But that is something that you should check as you implement it. And if for some reason the metrics do not automatically work out that way it is something that you could manipulate.

HTH

Rick

[brandonbittinger]

Are there any diagnostic commands I can run on the router to see which route traffic is being sent or is my best bet just running a traceroute from a PC? 

[brandonbittinger]

Also on a side not, below is a link to the guide I plan to reference to complete this project, obviously a build on top of it given the changes we have discussed prior.

http://www.cisco.com/en/US/technologies/tk583/tk372/technologies_white_paper0900aecd8029d629.html

If you look at the config in the link they are using 3des for encryption as well as for the transfer set. I think I would prefer to use AES but there are a good many options and combinations. Do you have a standard you generally use for VPNs? We will have to keep in mind the limitations of the 1941 to choose an encryption method that balances security and compute power. 

For the Policy encryption I was thinking AES192 and then for the transfer set using esp-aes 192 with esp-sha256-hmac. Would that be reasonable, too secure, not secure enough, too resource intensive?  Also would this scenario benefit from AH authentication? 

[Richard Burts]

The guide that you reference would appear to be a reasonable one to follow with the changes that we discussed, especially in terms of routing protocol. The example does use 3des, as do many of the older documents. [as a side note I wish that Cisco would provide dates for documents such as this. It obviously is a bit old (consider the reference to the Cisco AVVID architecture, and the examples using 3745 routers running 12.3T code) but still a reasonable presentation of configuring the feature] As you should be aware there is a tradeoff between degree of security and the resources required to provide the security. If you are dealing with Personally Identifiable Medical Information or with high dollar financial transactions then you want the highest level of security. If you are dealing with more mundane traffic between a branch and HQ then compromises in level of security are acceptable. I would suggest AES rather than 3des and think that 128 or 192 should be acceptable levels of security and appropriate for a 1941. I would not suggest using AH.

HTH

Rick