Policy based routing for VPN traffic through Router to ASA

[slee]

Hello,

We have a topology thus:

2 different ISPs -> Router -> ASA

We also have a site to site VPN between our ASA and our remote ASA, and a remote access VPN.  Our goal is to have our VPNs go through our Sprint ISP, while our users go out through our Comcast.  On our router, we have the default route set to go through our Comcast, and a static IP to go to our remote site for the s2s VPN.  We have our Users PATed to a Comcast IP using route-maps. That all works fine.  However, I need to set up the remote VPN.  Because the default route is set to Comcast, it can't form a tunnel since the endpoint IP is a Sprint IP.  I have seen documentation on using PBR to route encrypted traffic to a specified nexthop, but does it still work when the tunnel is not being formed on the router, but on the VPN?  How would I implement this? 

[Richard Burts]

Scott

There are some aspects of your situation that are not clear to me. And knowing them might allow us to give better advice. For example I believe that you are telling us that site to site VPN works ok and the problem is with Remote Access VPN. Is that correct? And if so does the Remote Access VPN terminate on the ASA or on the router?

Based on what you have told us so far and on what I think I understand here is my first shot at an answer to your question. I would think that Policy Based Routing should be able to solve your problem. To implement PBR you should start by configuring an access list which will identify traffic that you want to be subject to PBR. Probably the easy way is for the access list to permit traffic with a source address from Sprint. But there are other ways to do it that you might want to try.

Once you have configured the access list then you configure a route map that will use the access list and will set the next hop. The route map might look something like this

route-map RAvpn permit 10

match ip address spring_source

set ip next-hop

Once you have the route map configured then you apply the route map to the interface on the router where the traffic arrives to do PBR.

HTH

Rick

[slee]

Yes, you are correct, site to site works fine but the remote access is not working.  The remove access vpn terminates on the ASA, same place as the site to site VPN. 

I had already tried what you have laid out, except for 1 thing.  On the match ip address, we specified the internal ip range that would need to send traffic out through the sprint line.  When you say sprint source, do you mean the ip of the client? We don't know the client IP address, since they could VPN in from anywhere.  Because of this, I was considering not setting up PBR for the VPN routing, and instead set a default gateway to the Sprint next hop, and have a PBR set up to route our workstations on the network to go through the Comcast interface.  So, I would set up an access-list and route-map thus:

access-list:

route-map: route-map RAvpn permit 10

match ip address

set ip default interface Comcast interface

I tried this however, and the users reported that they could not connect to the internet.  Do I need to set the next-hop, shouldn't the default interface option work?  Here are the route-maps we use now:

route-map NAT-T1-GUEST, permit, sequence 10

  Match clauses:

    ip address (access-lists): wv-guest-net

    interface Multilink1

  Set clauses:

  Policy routing matches: 0 packets, 0 bytes

route-map NAT-T1-SRV, permit, sequence 10

  Match clauses:

    ip address (access-lists): wv-srv-net

    interface Multilink1

  Set clauses:

  Policy routing matches: 0 packets, 0 bytes

route-map ISP, permit, sequence 10

  Match clauses:

    ip address (access-lists): T1

  Set clauses:

    default interface Multilink1

  Policy routing matches: 27455925 packets, 512656112 bytes

route-map NAT-COMCAST, permit, sequence 10

  Match clauses:

    ip address (access-lists): wv-net

  Set clauses:

    default interface GigabitEthernet0/0

  Policy routing matches: 0 packets, 0 bytes

route-map NAT-T1, permit, sequence 10

  Match clauses:

    ip address (access-lists): wv-inside-net

    interface Multilink1

  Set clauses:

  Policy routing matches: 0 packets, 0 bytes

Our router is a mess and still has old configs in place we no longer need, but the only route-map that is actually applied to the inside interface is the route-map ISP.  Since I'm directing packets coming from our internal network, I would need to apply the route-map to the inside interface as well, correct?  I added the new route-map as sequence 20 to that route-map ISP, and that's when users lost internet connectivity.

Edit:  BTW, the issue with the VPN is with packets being sent out to the remote client.  Internally, the routing is fine.  When I set the default gateway to the Sprint Interface, it works fine, but then the Users also access the internet using the Sprint line, which I do not want.  I want them to continue using the Comcast line.

[Richard Burts · Accepted solution]

Scott

The problem is trying to use the internal ip range in the access list. There is some simple logic that may help you to understand this. The remote client establishes the Remote Access VPN session to an address on the ASA. And then accesses internal resources through the VPN session. For response traffic going to the remote client the source address is not the internal resource but is the address used on the ASA. Try putting that into the access list for PBR and let us know how it works.

HTH

Rick

[slee]

I see what you mean, but 2 issues/questions:

1) How will that work with internal traffic going out to the internet through that same interface?

2) When I used the internal IP range, the goal was to direct the internal traffic through an interface, not the VPN traffic.  Why didn't that work?

[Richard Burts]

Scott

1) I do not understand your point. In your original post you said that you wanted user traffic to use the Comcast interface and the VPN traffic to use the Sprint interface. So what is the same interface that you are asking about now?

2) Your original post says pretty clearly that user traffic was going out the Comcast interface and that this was working fine. Are you now saying that it was not working?

Your original post says that user traffic is PATed but does not say whether the address translation is done on the ASA or on the router. Can you clarify this?

HTH

Rick

[slee]

Sorry, I'll clarify.

So our internal network is connected to a core switch, which is then connected to our ASA, which is connected to our router via a single interface (router on a stick).  Our prior configuration had a site 2 site VPN with a site set up the same way, terminated on both sides on ASAs.  The problem arose when the ISP (Comcast) that the IP we had the VPN NATed to started acting up, so we changed the IP to another ISP (Sprint).  Users normally used the Comcast to access the internet, as well as the VPNs.  Since the Sprint connection is a T1, whereas the Comcast was much faster, I want to segregate the traffic to conserve bandwidth.  The default route of the router is set to go to the Comcast next hop, and we have a static route for the site 2 site VPN.  This allows the s2s VPN to go through the Sprint lines, while the users are still routed through Comcast.  Now, since we cannot set a static route for the remote access VPN since the remote IP address will always be different, I wanted to use PBR to route the return VPN traffic to the remote users through the Sprint. 

Now, if we do as you say, which is to set the access list to the IP on the ASA, how will that affect the users on the internal network?  I'm showing my ignorance here, but are the packets coming from the internal users set with the source address as the ASA, since those packets also go through the interface to the router?  This is the part that's tripping me up.  This is why I tried to change up what I was doing, and instead of routing the VPN traffic, I set the default gateway to be the Sprint next-hop and set the access-list for the internal users, so that the PBR is not directing the VPN traffic, but rather the internal users who try to access the internet. This did not work, and instead cut their connection.   When I said "same interface", I was referring to the interface that is NATed to be the endpoint of the VPN, which is the interface that is connecting the ASA to the router.  All traffic goes through that interface, to the router.

The address translation is done on the Router.

[Richard Burts]

Scott

This explanation does help me to understand a bit better what is going on and what your questions really are. So let us try to take another step toward a solution.

It should be possible to do the alternative that you describe and set the default route to Sprint and then use PBR to send all user traffic through Concast. But I believe that this would turn out to be more complicated and I would suggest that you focus on the alternative in which PBR only has to recognize the Remote Access VPN traffic.

Just to make sure that I understand your situation, am I correct in understanding that the remote acceess VPN is terminated on the outside interface of the ASA (that the remote user VPN clients are configured to go to the ASA address that is the one that also connects the ASA to the router?

As I attempted to explain earlier for the Remote Access VPN traffic when it gets to the router the source address will be the VPN termination address (which I assume is the ASA interface address) and not the address of the inside resource that actually generated the packet).

Since the address translation is done on the router then the source address of traffic that is originated from inside (and that is not VPN traffic) will be the inside device address and not the address of the ASA. And this means that the access list should be able to check of the ASA address for PBR without impacting normal user traffic.

If you are concerned about it you have the option to have the access list for PBR to check more than just the source address (although that is what I would suggest since it is more simple). You could have the access list to also check for the protocol of traffic to check for things like ISAKMP and ESP to identify the VPN traffic.

HTH

Rick

[slee]

Richard,

Thank you so much.  Sorry for the late reply, got too excited that it started working.  Your advice was spot on.  I have another, related question.  What if we want to have that interface on another s2s tunnel?  In addition to our current s2s tunnel, we also want to set up a tunnel to the Amazon cloud service.  I would imagine since the source address would be the same for traffic for both tunnels, that this setup would not work?  Currently, we only need 1 machine to have VPN access to the Amazon cloud, would that simplify things?  Since the source address is not the internal IP, how would I go about this?

[Richard Burts]

Scott

I am not clear about your question. Are you asking if it is possible to have two site to site VPN and use the same interface on the ASA for both tunnels? If so the answer is that this should work with no problem.

If you are asking something different then please provide clarification of your question.

HTH

Rick

[slee]

We want to start using the Amazon Cloud service, and they have a VPN gateway that we can form a tunnel with.  We would like to have a tunnel from our ASA to the Amazon Cloud service.  Configuration on the Amazon side is no problem, but I'm not sure how I would go about configuring the ASA.  Can I just set up the tunnel group, crypto keys, and crypto map?  Is there additional configuration tha tneeds to be done?

Edit:  This is in reference to having 2 tunnels on the same interface.  It would be no problem if this was the only VPN that the interface would be a part of

[Richard Burts]

Scott

It is quite possible to have two site to site VPN tunnels on the ASA. You would set up a separate crypto key, and a separate tunnel group (and probably a different access list to use in the crypto map). You would not set up another crypto map. There can be only a single crypto map on an interface. But you can configure another instance within the crypto map for the Amazon tunnel. (if the existing tunnel is number 10 in the crypto map then Amazon might be number 20).

HTH

Rick

[jaime.pedraza]

Hello,

Finally did you make it work? I'm struggling with the same scenario, but the customer has multiple PBRs to manipulate the traffic.

Thanks,

James