Cisco ASA Policy-Based Routing

[NETWORK OIT]

We have five network connections; Inside, Outside1, Outside2, Outside3, & DMZ.

Outside1, 2 and 3 are different networks for backup routes.  Because Outside1 is now becoming over utilized,and Outside 2 and 3 is not being utilized much at all, we wanted to route traffic based on several aspects.  one the source & two destination port.  We also wanted to throttle the bandwidth on outgoing traffic.

is there Policy Based Routing available on the ASA 5510 as of yet?  and if not, is there any plans for it in the near future?

Thanks,

Daniel

[Aniket Rodrigues]

The ASA 5510 does not support PBR. It is very likely that a feature request for PBR has been placed already, but no announcements have been made yet. There is a workaround which lets you send all email and/or web traffic through one ISP and rest of the traffic through the other. The workaround however does not apply to your requirement

Thanks

AR

[Groupe NOEVA]

What is your workaround ?

Thanks

David

[vilaxmi]

If you want all your web traffic to go over your primary ISP link (x.x.x.x) and mail (smtp) traffic to go over the backup link (y.y.y.y), then please proceed with the following workaround on ASA:-

route outside 0.0.0.0 0.0.0.0 x.x.x.x 1
route backup 0.0.0.0 0.0.0.0  y.y.y.y 2

nat (inside) 1 0 0
global (outside) 1 interface
global (backup) 1 interface

static (outside,inside) tcp 0.0.0.0 www 0.0.0.0 www netmask 0.0.0.0
static (backup,inside) tcp 0.0.0.0 smtp 0.0.0.0 smtp netmask 0.0.0.0

HTH

Vijaya

[srdjankatic]

Hi,

i have same problem with my ASA since there is no PBR. My asa has two internet interfaces and one LAN if. I have following requirement

Internet if 01: for default route and backup for Internet if 02

Internet if 02: VPN traffic,  but VPN clients are coming from unknown addresses, from various locations.

My problem is when CISCO VPN client initiate VPN  session to if02 ASA respond through if01 since if01 holds default route. Is there any way to work around this without waiting PBR and without using transparent mode? I am desperate since this is one month old problem.

Any Help is appreciated

tnx

[ahalwani]

I tried your workaround but It didn't work. I think beause the AD on the backup link is higher than the outside link so the ASA is always choosing the outside path. Am I right?

[Aniket Rodrigues]

Even though the metric is higher on the backup route, the firewall will still use it to route smtp traffic over that link, since the static nat [ static (backup,inside) ...] is applied to the packets before the routing decision is made. As a result, when the destination matches the static NAT, the firewall will look for a route pointing out of the backup interface, which exists.

Can you paste the output of 'show run static, show run route and show route' ?

AR

[homer]

This is helpful, thank you Vijaya. As a newbie operating in ASDM, I think we've figured out the routes. Can you tell me where we do the following in ASDM?

nat (inside) 1 0 0
global (outside) 1 interface
global (backup) 1 interface

static (outside,inside) tcp 0.0.0.0 www 0.0.0.0 www netmask 0.0.0.0
static (backup,inside) tcp 0.0.0.0 smtp 0.0.0.0 smtp netmask 0.0.0.0

[andyirving]

Vijaya, your suggestion unfortunately will not work as the selection of a NAT rule is taken after the internal routing decision.  Therefore the use of multiple NAT translations does not influence the way the traffic is forwarded.  The route with the lowest metric is always used if eligible.

The only way to do this is with multiple contexts, each one can use a different IP default gateway, each context can handle traffic from internal sources and direct it out of the seperate gateways.

The only other way of doing this is to have an external router connected to the outside of the ASA running PBR, traffic would hit this router and be forwarded out of either interface based on policy.

[Aniket Rodrigues]

Andy, that is not true. While the routing decision is taken first, that holds true only for source NAT. When performing destination nat, the Nat decides the routed interface. As a result, the packet is sent to the natted interface for routing and the firewall checks its asp table to see if a route to the destination exists in the table out that interface. Based on this asp entry, the packet is routed. Therefore, in this configuration, you are essentially creating and matching a destination NAT rule for all web and smtp traffic. The static nat rule then decides the next hop interface as 'outside' in the first case and 'backup' in the other static. Once these natted interfaces are selected, the asp table would be checked for routing entries.

HTH,

AR

[andyirving]

Aniket, thanks for that, I was not aware of the destination NAT forwarding flow, that is a neat way of utilising both links assuming it is split based on a service such as web or email.  Not true load sharing but will at least utilise both external interfaces.  Have Cisco ever expressed a view to add PBR to the ASA feature set?

[keith.voelker]

I hate to hijack this thread...

I'm looking to do something similar.

I'd like to send all traffic from one inside host out the second ISP (backup interface in this example)

Is there a workaround for this?

[Dan Jay]

Has someone already accomplished this on 8.3 or newer ?

[gregbeifuss]

I'm looking for this under 8.3 or newer as well.

[Ditmar Tavares]

Aniket, I believe you are wrong, as I'm having this issue and I have contacted cisco TAC, and as per cisco the routing table is checked, so even if we have static mapping, the traffic will always leave to the default route,

with this configuration you will creat asymetric routing, cusing the secondary link not to work.

[bbiandov]

Ok so posting opinions at this point is useless. Hard evidence would be useful.

However there does NOT appear to be a single case where this has been tested successfully.

What does that tell us? IMHO it tells us that the theory of using static as a vehicle to split translation into separate outside interfaces is flawed. That's because even after the translation takes place as a result of the static into the proper public IP we are back to square zero which is that the lack of PBR prevents us from properly routing that translated traffic out of the desired Internet connection.

Therefore unless PBR is implemeted into the ASA image this issue is still open....