Outside NAT to internal machines - 2 ISPs

[Darren Spezio]

I have 2 ISP links,  69.74.x.x and a second new one that I just added 108.162.x.x to our Cisco 2900 to increase our overall speed, which is working.

Can the outside NAT connections that are on the 69.74.x.x  be affected by adding the new link? I have a few users reporting that they can't get into internal machines from outside that have NAT through the ASA starting about the time I added this link, while others have no issue at all.

NAT on ASA = 69.74.x.x > 10.8.x.x

interface GigabitEthernet0/0

description Outside-LightPath

ip address 173.251.x.x 255.255.255.252 duplex auto speed auto ! interface

GigabitEthernet0/1

description To Firewall

ip address 69.74.x.x 255.255.255.240

IP nat inside

duplex auto speed auto !

interface GigabitEthernet0/2

description To Cable WAN

108.162.x.x 255.255.255.252

IP nat outside

access-list 50 permit 69.74.x.x 255.255.255.240

IP nat inside source list 50 interface 108.162.x.x 255.255.255.252

overload duplex auto speed auto

! ip forward-protocol N ! no ip http server no ip http secure-server ip http timeout-policy idle 60 life 86400 requests 10000 !

ip route 0.0.0.0 0.0.0.0 173.251.x.x

ip route 0.0.0.0 0.0.0.0 108.162.x.x  

[Darren Spezio]

should I attach the output file or is that not advised because of all of the IP addresses?

[Jon Marshall]

You probably don't want to attach anything with your public IPs.

What happens if you just create an acl with a different number and then modify your NAT statement to use the new acl number ?

When you do modify it you need to clear an existing NAT translations ie.

"clear ip nat translations *"

but don't do that in core hours.

Jon

[Darren Spezio]

I cleaned up the output file and attached.

[Jon Marshall]

Okay you have missed the host keyword ie.

"access-list 50 permit host 62.x.x.211"

ie. you do not use a wildcard mask because if you do it just works out the correct subnet which is 69.x.x.208.

So delete acl 50 and enter the above.

Note I made a mistake in one of my posts where I said -

"access-list 50 permit ip host 62.x.x.211"

which is not valid because of the "ip" part so that may have caused some confusion.

Sorry about that :)

Jon

[Darren Spezio]

Taking off for the day but when I added access-list 50 permit host 69.x.x.211 it appeared that youtube stopped working - Can we pick this up again tomorrow?

[Jon Marshall]

No problem.

Jon

[Darren Spezio]

Added access-list 50 permit host 69.xx.211 and users are reporting that they are not able to remote into internal servers, it appears on the config file as   "access-list 50 permit 69.xx.211" with out the word host, not sure if that is relevant.

[Jon Marshall]

Perhaps you should post full configuration.

All that acl should do is make sure only that IP is translated which is what you want.

You can try using an extended acl eg.

"access-list 101 permit ip host 69.x.x.211 any"

and then update your NAT statement to reference that acl.

Jon

[Darren Spezio]

attached

[Jon Marshall]

As far as I understand your setup the firewall does all the 69.x.x.x translations.

And I think the original problem was that because you were translating all 69.x.x.x IPs if they went out the backup link the 69.x.x.x server IPs were being changed and that is why some users couldn't connect.

And it all depended on which default route the router chose as it will alternate between them.

By changing the acl to only NAT 69.x.x.211 which is the general internet access IP then the server IPs should remain unchanged and it shouldn't really matter whether traffic comes in via the primary link to the server and the return traffic goes via the backup link because the return traffic is being routed back to the client ie. the source IP of 69.x.x.x does not come into it.

Or it shouldn't do unless your ISP is doing something which they shouldn't be.

Your acl is fine although if you want you can try using the acl example I gave but I suspect that won't change anything.

Are you saying no users can now connect to the internal servers ?

Jon

[Darren Spezio]

The users are connecting using IE or RDP to 69.x.212

Some users can connect and others can not.                                                       When I remove ip route 0.0.0.0 0.0.0.0 108.162.x.x all users can connect again.

[Jon Marshall]

When you remove that route it means that the 69.x.x.212 IP is never translated which is why it then works.

However by only allowing the 69.x.x.211 IP to be translated, which is what we tried, that should have had the same effect and it should have worked ie. even if the return traffic back to the client went via the backup link the 69.x.x.212 IP would not be translated.

I'm not sure why that didn't work but the only thing I can suggest is you try the PBR solution I posted and see if that works ie. make sure all traffic to and from the servers uses the primary link only.

Jon

[Darren Spezio]

Was I supposed to run clear IP translations, could that be why?

Okay I will try the PBR, this is not recommended during core hours correct? 

[Jon Marshall]

It could be there were existing translations for the server IPs if you did not clear the translation table.

Whenever you change NAT it is always a good idea to check existing translations.

You can clear specific translations ie. you don't need to clear all translations so you wouldn't want to clear any translations for 69.x.x.211.

That may be why some users still weren't connecting so I think it is worth checking the translation table and if there are any 69.x.x.x server IPs translated to the 108.162.x.x IP try clearing them and retesting.

As for PBR if you implement it correctly then it should only effect the server IPs and as you don't have them currently working correctly then it isn't really going to break anything or shouldn't.

However I would recommend doing it outside core hours just in case you make a mistake or it has an unintended effect on current traffic.

Jon

[Darren Spezio]

Would it have cleared on it's own, since I made this change 3 days ago? Maybe I should have some users try again today?