How do I route transit traffic via Dialer1 instead of Dialer0 when using NAT?

[dtbullock]

I have 2 routes to my ISP (over separate ATM PVC's, each with their own dialer).  I want traffic for DNS and VoIP to go via dialer 1 to the ISP's private network (10.204.x.y), and generic data to go via dialer 0 (58.108.x.y).

At the moment, since I can identify traffic for dialer 1 via its destination IP address, I'm approaching this task using static routing.  (eg. ip route 198.x.x.x 255.255.255.255 Dialer 1)

This works fine when I (for example) force a DNS request from the router.  The router correctly selects dialer 1 to send a packet with dialer 1's IP address. 

However, it does not work for transit traffic which is subject to NAT - the router receives the packet from the LAN and then NATs the source address to dialer 0's IP address and sends it over dialer 1.  The ISP wisely drops the packet.  The highlighted line from the following debug ip packet tells the tale:

IP: s=10.9.9.254 (BVI1), d=198.142.0.51, len 75, input feature, Stateful Inspection(4), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

IP: s=10.9.9.254 (BVI1), d=198.142.0.51, len 75, input feature, Ingress-NetFlow(17), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

IP: s=10.9.9.254 (BVI1), d=198.142.0.51, len 75, input feature, Virtual Fragment Reassembly(21), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

IP: s=10.9.9.254 (BVI1), d=198.142.0.51, len 75, input feature, Virtual Fragment Reassembly After IPSec Decryption(32), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

IP: s=10.9.9.254 (BVI1), d=198.142.0.51, len 75, input feature, MCI Check(64), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE 

IP: s=10.9.9.254 (BVI1), d=198.142.0.51, len 75, input feature, TCP Adjust MSS(66), rtype 0, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

IP: s=10.9.9.254 (BVI1), d=198.142.0.51 (Dialer1), len 75, output feature, CCE Output Classification(5), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

IP: s=58.108.162.121 (BVI1), d=198.142.0.51 (Dialer1), len 75, output feature, Post-routing NAT Outside(17), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

IP: s=58.108.162.121 (BVI1), d=198.142.0.51 (Dialer1), len 75, output feature, Stateful Inspection(20), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

IP: s=58.108.162.121 (BVI1), d=198.142.0.51 (Dialer1), len 75, output feature, Firewall (NAT)(33), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

IP: s=58.108.162.121 (BVI1), d=198.142.0.51 (Dialer1), len 75, output feature, Firewall (inspect)(38), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

IP: s=58.108.162.121 (BVI1), d=198.142.0.51 (Dialer1), len 75, output feature, TCP Adjust MSS(40), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

IP: s=58.108.162.121 (BVI1), d=198.142.0.51 (Dialer1), len 75, output feature, Post-Ingress-NetFlow(52), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

IP: s=58.108.162.121 (BVI1), d=198.142.0.51 (Dialer1), len 75, output feature, Dialer idle reset(66), rtype 1, forus FALSE, sendself FALSE, mtu 0, fwdchk FALSE

IP: s=58.108.162.121 (BVI1), d=198.142.0.51 (Dialer1), g=198.142.0.51, len 75, forward

IP: s=58.108.162.121 (BVI1), d=198.142.0.51 (Virtual-Access3), len 75, sending full packet

Clearly, my NAT configuration is at fault. The above is unsurprising, since I have

   ip nat inside source list 1 interface Dialer0 overload

and access list 1 has the line:

    30 permit 10.9.9.0, wildcard bits 0.0.0.255

... but how would I tell NAT to behave differently when the destination IP is one of those I want routed to Dialer1?

thanks!

David.

[dtbullock]

It seems like I might be looking for something like:

   ip nat inside source route-map foo interface Dialer 1 overload

Any comments?

[dtbullock]

Largely based on information in NAT Support for Multiple Pools Using Route Maps, I'm contemplating a configuration like the following:

ip nat inside source route-map ROUTE-MAP-VOICE interface Dialer 1 overload

ip nat inside source route-map ROUTE-MAP-DATA interface Dialer 0 overload

route-map ROUTE-MAP-VOICE permit 10

match ip address ROUTE-VOICE

route-map ROUTE-MAP-DATA permit 10

match ip address ROUTE-DATA

ip access-list extended ROUTE-VOICE

permit ip 10.9.0.0 0.0.255.255 211.29.132.12 0.0.0.0

permit ip 10.9.0.0 0.0.255.255 198.142.0.51 0.0.0.0

permit ip 10.9.0.0 0.0.255.255 211.29.144.0 0.0.7.255

ip access-list extended ROUTE-DATA

permit ip 10.9.0.0 0.0.255.255 0.0.0.0 255.255.255.255

However, with the above configuration, a packet from 10.9.9.254 to 198.142.0.51 could match either ROUTE-VOICE or ROUTE-DATA.  Since there are apparently no rules ordering which ip nat inside source route-map gets evaluate first, it is ambiguous which route-map will be applied.  (?!)

Conceptually, if only the route-map could feedback to the NAT process via a 'set' command (eg. via "set interface"), I could do this instead:

ip nat inside source route-map ROUTE-MAP overload

route-map ROUTE-MAP permit 10

match ip address ROUTE-VOICE

set interface Dialer 1

set default interface Dialer 0

ip access-list extended ROUTE-VOICE

permit ip 10.9.0.0 0.0.255.255 211.29.132.12 0.0.0.0

permit ip 10.9.0.0 0.0.255.255 198.142.0.51 0.0.0.0

permit ip 10.9.0.0 0.0.255.255 211.29.144.0 0.0.7.255

... but unfortunately it would seem that ip nat inside source route-map really wants me to specify a pool or interface, and it is difficult to imagine that it would allow this to be overridden because of a route-map's execution.

So I think I'm going to have to do this:

ip nat inside source route-map ROUTE-MAP-VOICE interface Dialer 1 overload

ip nat inside source route-map ROUTE-MAP-DATA interface Dialer 0 overload

route-map ROUTE-MAP-VOICE permit 10

match ip address ROUTE-VOICE

route-map ROUTE-MAP-DATA permit 10

match ip address ROUTE-DATA

ip access-list extended ROUTE-VOICE

permit ip 10.9.0.0 0.0.255.255 211.29.132.12 0.0.0.0

permit ip 10.9.0.0 0.0.255.255 198.142.0.51 0.0.0.0

permit ip 10.9.0.0 0.0.255.255 211.29.144.0 0.0.7.255

ip access-list extended ROUTE-DATA

deny ip 10.9.0.0 0.0.255.255 211.29.132.12 0.0.0.0

deny ip 10.9.0.0 0.0.255.255 198.142.0.51 0.0.0.0

deny ip 10.9.0.0 0.0.255.255 211.29.144.0 0.0.7.255

permit ip 10.9.0.0 0.0.255.255 any

... to ensure that ip nat inside source route-map can only choose 1 route-map or the other.  Seems a little bit ugly, but I'll let y'all know how it works.

Message was edited by: David Bullock ... fixes to some ACL masks.

Message was edited by: David Bullock ... fixes to some bad syntax.

[Marwan ALshawi · Accepted solution]

Are those links terminating on in the same router if yes then you need to match the exit interface in the nat route-map

Please refer to the bellow document which I think it might be helpful to your case

https://supportforums.cisco.com/docs/DOC-8313

HTH

If helpful rate

[shehinpm1]

hi ,

as marvans suggetion,instead of matching the dialer interface in route map set to the exit interface of each ISPs .

[dtbullock]

Verdict!  This works:

    ip nat inside source route-map ROUTE-MAP-DATA interface Dialer0 overload

    ip nat inside source route-map ROUTE-MAP-VOICE interface Dialer1 overload

    ip access-list extended ROUTE-DATA

     deny   ip 10.9.0.0 0.0.255.255 host 211.29.132.12

     deny   ip 10.9.0.0 0.0.255.255 host 198.142.0.51

     deny   ip 10.9.0.0 0.0.255.255 211.29.144.0 0.0.7.255

     permit ip 10.9.0.0 0.0.255.255 any

    ip access-list extended ROUTE-VOICE

     permit ip 10.9.0.0 0.0.255.255 host 211.29.132.12

     permit ip 10.9.0.0 0.0.255.255 host 198.142.0.51

     permit ip 10.9.0.0 0.0.255.255 211.29.144.0 0.0.7.255

    route-map ROUTE-MAP-DATA permit 10

     match ip address ROUTE-DATA

   route-map ROUTE-MAP-VOICE permit 10

    match ip address ROUTE-VOICE

It is not as neat as marwanshawi's solution, which uses policy-based routing on the ingress interface to set the egress interface, and then uses the match interface selector to discriminate between NAT route-maps.  (Which is v.nice).

For the moment I'm sticking with my solution because I'm not yet ready to leap headfirst from my routing table with policy-based routing!  (And because I've already got it working ... ).  However, I will definitely follow the marwanshawi zen when I need to choose a link based on criteria other than destination address (such as whether the route is up, or load-balancing concerns, or protocol, etc).

[Marwan ALshawi]

Hi David,

Glad to help and thanks fornthe rating

By the way this policy nat work even without the policy based routing as the router will check the routing and exit interface before performing the inside to outside nat

HTH

[dtbullock]

Yes, I was just thinking about that ... the output interface has already been chosen by the time the inside source NAT is applied, so selecting the NAT route-map via match interface is the best approach!  Thanks!