ASA Tunneled default command

[fsebera]

When the command route inside 0 0 <ip-of-next-hop> tunneled is configured on the VPN ASA, when a packet from a remote user VPN is received, is the local route table consulted for possible destinations before using the tunnel option?

Thanks

Frank

[Richard Burts]

Frank

I am not clear whether there is some subtlety in what you are asking. So let me answer in this way and if it does not seem to answer your real question then perhaps you can clarify. When a packet from a remote user VPN is received the ASA will check the destination address and looks in the routing table for a match. If the match is to use the default route then the ASA will use this tunneled entry rather than the normal default route which is configured.

HTH

Rick 

[fsebera]

Hi Richard,

THANK YOU for responding!

We have been unable to determine - based on Cisco documentation - if the local route table is consulted or not. It's clear the normal 0/0 will not be used for "tunneled" traffic when this command is implemented. Based on your response; when a VPN packet arrives, if a route to the specified destination exist in the local route table, the "tunneled 0/0" will not be used.

Said another way, if a tunneled packet has a destination unknown to the local ASA VPN box, the ASA will resort to forwarding this packet to the "tunneled default" address.

Thank you

Frank

[Richard Burts · Accepted solution]

Frank

I believe that I now understand your question a bit better. Let me give a bit of background and then I will attempt another answer to your question. Normally the ASA will not allow two different routes for the same prefix. Using the tunneled parameter causes the ASA to accept a second route for a prefix (most often for a default route but I believe that it could be used for other routes if needed).

When the ASA has a packet that it needs to forward it looks into its route table. If there is a single entry for that destination then that is the route that is used (does not matter if the packet originated from a VPN or not). If the ASA finds that there are two entries for that destination then it uses one for normal traffic and the "tunneled" entry for forwarding packets that originated from VPN connections. 

HTH

Rick

[fsebera]

How the “tunnel” option works – When an AnyConnect VPN client makes a successful VPN connection to the ASA VPN appliance, the ASA VPN appliance dynamically installs that VPN hosts static host route into its global routing table; similar to    S   10.0.0.1 255.255.255.255 [1/0] via <public-IP-of-next-outbound-hop>, outside.    When a packet is received in from –say Cisco AnyConnect VPN client host-1-, the ASA VPN appliance performs (packet decryption and other magic) as-well-as a route lookup for the original non-encrypted packet’s destination – usually but not mandatory an RFC 1918 address.  If the specific destination IP address is found in the ASA VPN appliances global routing table, the packet is routed via that most specific route – as normal. If no specific route is found in the ASA VPN appliances global routing table, the Gateway of Last Resort or better known as Default Gateway of 0.0.0.0/0 is utilized to route the packet.  If the 0/0 route does not exist, the packet is dropped. When the ASA VPN appliance is configured in this manner (and split-tunnel is disabled on the AnyConnect VPN client), remote uses should be able to surf the public Internet through the corporate ASA VPN appliance connection – albeit at a much slower pace since each packet has a good number of extra hops. If we wanted to police and filter this public Internet base traffic we could apply an ASA VPN appliance based fix with an optional tunneled command.

When the optional command  route inside 0 0 <next-hop> tunneled  is configured on the ASA VPN appliance, the ASA VPN appliance still performs a standard next-hop route lookup for all packets. It’s when there is no specific next hop route configured in the ASA VPN appliance, the ASA VPN appliance must consider the least specific route provided by the Gateway of Last Resort or drop the packet. When the optional tunneled route command has been installed on the ASA VPN appliance, it no longer considers the standard Default Gateway for VPN tunneled packets, instead it routes these packets based on the newly configured “tunneled” Default Gateway next-hop.  This newly installed “tunneled” route will only be used for tunneled VPN packets where-as non-tunneled packets still use the standard Default Gateway as-well-as other more specific non-tunneled routes.  Now when host-1 tries to visit any public Internet based site, the ASA VPN appliance (that does not support the full Internet routing table ) will not find the requested public Internet site IP address in the routing table and thus will be forced to route the packet to the configured tunneled next-hop address.

Our plan is to configure the route inside 0 0 <Border-FW-Inside-Interface-IP> tunneled on the ASA VPN appliance. When traffic from a VPN user with a destination to the public internet, the 0/0 tunnel command will redirect this traffic to the inside interface of the border firewall. The border firewall will utilize WCCP to redirect ports 80/443 traffic to the Webcache proxy/filter application to enforce policy. All other Internet bound traffic with destinations other than TCP ports 80/443 will bypass WCCP/Websense but will still be subjected to the ACL policies configured on the border firewalls. Problem solved.

Note: The tunnel command is all inclusive.

Note: The route inside 0 0 <Next-hop> tunneled command also support non-default routes as-well.

Thanks for your assistance, we really appreciate your help!

Frank

[Richard Burts]

Frank

Thanks for posting back to the forum to let us know that you have this figured out. I am glad that my suggestions were helpful.

HTH

Rick

[fsebera]

Update:

The ASA VPN appliance interface that is being used to redirect the VPN traffic must not have the ip verify reverse-path command enabled. If this command is enabled, the ASA will drop these tunneled packets when attempting to route 'em.

In my example above, this would be the "inside" interface.

HTH Somebody!!!

Frank

[fsebera]

Another update:

Turns out you cannot enable the tunnel option on non-default routes on the ASA using IOS 9.6(1).

ASA# (config)# route inside 10.0.0.254 255.255.255.255 10.0.0.3 tunnel

ERROR: tunneled option cannot be specified for non-default routes

HTH Somebody

Frank

[Richard Burts]

Frank

Thanks for the update. It is interesting that the tunneled option can only be used for default route.

HTH

Rick

[jeronimo]

Yeah, that or you define static route(s) without "tunneled" option via inside interface for the concerned subnets.

(Oh and, actually, ASA would not drop the tunneled packets, but the replies)