09-10-2011 08:02 PM - edited 03-04-2019 01:34 PM
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.
Solved! Go to Solution.
09-11-2011 12:20 AM
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
09-10-2011 08:36 PM
It seems like I might be looking for something like:
ip nat inside source route-map foo interface Dialer 1 overload
Any comments?
09-10-2011 09:46 PM
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.
09-11-2011 12:20 AM
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
09-11-2011 01:11 AM
hi ,
as marvans suggetion,instead of matching the dialer interface in route map set to the exit interface of each ISPs .
09-11-2011 05:59 AM
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).
09-11-2011 06:04 AM
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
09-11-2011 06:18 AM
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!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide