02-05-2014 04:28 AM - edited 03-07-2019 06:01 PM
Hi Community Team!
I have attached an example topology on this thread for explain what I want to do. The suppose that R2 is working as a ISP1 and R3 ISP2, and back of them is the Internet (loopback interfaces). R1 is doing NAT for R4 using the IP range of ISP1 and ISP2, but I want that return packets from packets coming from Internet using ISP2 be transmit to ISP2, and on the other hand, packets from packets coming from Internet using ISP1 be transmit to ISP1, but I can’t do this work.
I have tried to use default routes with the same AD, default routes with different AD, with CEF, without CEF, using CBAC, using ZBFW, but nothing worked. I would like if routers are able to do that when dynamic routing is not possible and only default routing is being used.
I could do this pretty easy with ASA, I only to create both NAT (using one public IP for each ISP) and create two default routes that do not need to have same AD, and ASA will know that packets came from XYZ ISP and that return packets must be transmitted for the same link/ISP. ASA is pretty much intelligent :-)
Imaging that R1 is doing NAT for R4 with those policies:
R1#sh ip int b
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 200.0.0.1 YES manual up up
FastEthernet0/1 201.0.0.1 YES manual up up
FastEthernet1/0 10.0.0.1 YES manual up up
NVI0 200.0.0.1 YES unset up up
!
R1#sh route-map
route-map ISP2, permit, sequence 10
Match clauses:
interface FastEthernet0/1
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map ISP1, permit, sequence 10
Match clauses:
interface FastEthernet0/0
Set clauses:
Policy routing matches: 0 packets, 0 bytes
!
R1#sh run | sec ip nat inside source
ip nat inside source static 10.0.0.2 200.0.0.100 route-map ISP1 extendable
ip nat inside source static 10.0.0.2 201.0.0.100 route-map ISP2 extendable
Is it possible to do what I'm trying to using only routers?
Tks!
02-05-2014 04:43 AM
Hi,
no ip nat inside source static 10.0.0.2 200.0.0.100 route-map ISP1 extendable
no ip nat inside source static 10.0.0.2 201.0.0.100 route-map ISP2 extendable
ip nat inside source route-map ISP1 interface f0/0
ip nat inside source route-map ISP2 interface f0/1
access-list 1 permit 10.0.0.0 0.0.0.255 I suppose f1/0 has a /24 subnet mask
route-map ISP1 p 10
match ip add 1
route-map ISP2 p 10
match ip add 1
So your route-maps should have match ip add 1 and match interface
do clear ip nat tra *
try again and it should work
Regards
Alain
Don't forget to rate helpful posts.
02-05-2014 04:49 AM
Hi Alain,
This do not work. You are thinking on NAT on outbound for users, for example, navigate on the Internet. But for servers this do not work. I want that the Internal server could be reacheble by both ISP IPs on the Internet at the same time.
The way you send you changed the NAT type and it is not what I want.
But thank you anyway. :-)
02-05-2014 05:22 AM
Hi rodrigo,
Sorry I misunderstood your request.
So you have inbound traffic destined for server that comes into ISP1 and some other traffic destined to same server that comes ingress on ISP2 link ?
Is that correct? And then you want return traffic to go out the same path it entered the NAT device ?
I don't think this is possible because CEF will decide which NAT outside interface it will send the return packets out based on its src/dst IP hash algorithm and if it chose the same path as inbound traffic then it is ok for you but if it chose the other then you don't achieve what you want to.
To bypass this you would have to use PBR and force all traffic back to outside source out ISP1 to be forwarded on ISP1 link and same for ISP2 return traffic
Regards
Alain
Don't forget to rate helpful posts.
02-05-2014 06:06 AM
So you have inbound traffic destined for server that comes into ISP1 and some other traffic destined to same server that comes ingress on ISP2 link ?
Is that correct? And then you want return traffic to go out the same path it entered the NAT device ?
Yes, it is correct.
But using PBR I could select some traffic but it is impossible catch the return traffic based on inbound traffic. Maybe if I was on a WAN connection I could do that based on the destination network or something like this, but for Internet it is impossible.
Any other sugestion? Even disabling CEF... and using fast switching or packet switching.
02-05-2014 06:14 AM
If using Process switching, then with 2 default routes you'll have one packet going one way then next packet going the other way and this is not what you want.
With Fast switching, the first packet is processed switched then the cache is used for other packets going to same destination but the first packet won't necessarily go the path that you want it to.
If you were in a real case unless you were using a firewall in between that doesn't support asymetric routing then it wouldn't be a problem if the return packets were taking another path as long as they arrive to destination, what would be inportant is that the same flow would use the same path and that's what CEF achieves.
Why exactly do you want this behavior to happen ?
Regards
Alain
Don't forget to rate helpful posts.
02-05-2014 06:18 AM
The problem is that IOS does not support NAT overload from outside to inside. Or it didn't when i last looked so if someone knows otherwise please let me know.
If it did you could NAT all source IPs from the ISPs to a different IP per ISP and then use PBR for the return traffic because from inside to outside PBR is done before NAT.
So the only solution i can think of is to use a NAT pool per ISP and then you NAT all incoming source IPs to a different IP from the relevant NAT pool. You then use PBR to send the return traffic to the right exit interface and the destination IPs are then changed back to their real IP.
Note if there were other L3 devices in the LAN they would need routes for the NAT pools pointing to the router LAN interface.
The problem is if you are receiving a lot of different source IPs from each ISP you have two issues -
1) you need a large NAT pool per ISP. Not a huge problem as you can use private addressing for this as they are only relevant within your LAN.
2) this could create a lot of NAT translations on your router. You could decrease the timeout which you would want to do but even then the router could easily get overloaded with NAT translations.
So it is not an ideal solution and may very well not work because of the amount of NAT entries needed.
Jon
02-05-2014 06:38 AM
@Alain
"it wouldn't be a problem if the return packets were taking another path as long as they arrive to destination, what would be inportant is that the same flow would use the same path and that's what CEF achieves."
- I can't send the return traffic to other ISP different from incomming packet, but as far as I use another ISP IP range, the communitcation willl not work, if you know what I mean.
@Jon
Using NAT it is the only solution I could think too, but I thought that I would be missing something I could get from someone something more clear. Even if I must use IOS Firewall to make routers to looks like the ASA and visualize flows instead of packets or hash and this way memorinzing the flow/session it could return packet to the same isp that it come from.
@all
Usually for small entrerprises I offer for my customer 2 routers conneect to ISPs duing NAT and IPSLA/PBR plus 2 ASA, and this work pretty well and the way I ask in this tread, but for some customers that do not have budget, I was thinkg to offer only the routers doing everything (including firewall). But the big problem is that some customers have servers that must be reacleble more both providers at the same time and doing very complex NAT for this to work would make customer to not want it, because for experts is very easy (or not), but for usually customer that sometimes even do know well what it is NAT would be very hard ou almost impossible to keep this as a professional solution.
I don't know why, but I think I already make this to work some years before what make thinkg if this depends of IOS/switching method.
Anyway, thank you guys!
02-05-2014 07:04 AM
"it wouldn't be a problem if the return packets were taking another path as long as they arrive to destination, what would be inportant is that the same flow would use the same path and that's what CEF achieves."
- I can't send the return traffic to other ISP different from incomming packet, but as far as I use another ISP IP range, the communitcation willl not work, if you know what I mean.
yes exactly I don't know why I replied such a stupidity but in this case the firewall feature won't do anything more for you( I suppose because I wrote so many stupid things in this thread that I'm not sure of nothing anymore right now if you see what I mean)
I really don't think that what you want to achieve is possible anyway .
Regards
Alain
Don't forget to rate helpful posts.
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