Broken Pat/Overload after upgrade from 1711 to 891

[jcopelandghs]

Hey All

So I had this remote site with an old 1711 that was being used for their internet/VPN endpoint back into our corp network here over a comcast business cable modem.

I ordered a new 891 got it here, pretty much just put the config from one over to the other (changing interface names and such and acls that were labeled with interface names) and sent it on its way to them.

The vpn tunnel back to our corporate offices comes up and they can access all of our internal stuff fine with no issues.

However the normal stuff where they nat directly out to the internet isnt working.

I can "sh ip nat translations" and see the nats being built but they dont seem to get any traffic passing as far as I can tell. When I "debug ip nat" I also notice that the nats translations being built up seem to timeout/die relatively quickly like there was no active traffic going through them to keep them up.

My overload nat statement uses a route-map that points to an ACL that just has multiple deny lines through the top to keep VPN destined traffic from getting natted but the last line is an allow from the internal subnet so that it will get natted.

I was thinking if that was messed up that I wouldnt be seeing my nat entries, so that must be partially correct I guess. Drawing a blank here. Any help would be greatly appreciated. I will attach a sanitized version of the config from the 1711 that I pretty much copied over to the 891.

I am wondering if there is something syntax wise that less this function on the 1711 but not on the 891.

Thanks for taking a look!

-J

[Juan Perez · Accepted solution]

Hi,

Your NAT configuration looks fine. Have you tried removing IP INSPECT and ACLs?

Regards.

[jcopelandghs]

Juan Thanks for the response.

I actually remember now, that I did not put the inspect lines/related config into the 891.

When you say the ACLS's are you just talking about all of them, as they related to the external interface. Pretty much removing everything except for the ACL tied to my routemap for the nat?

I have not tried that as of yet, would be a simple thing to rule out. I will definitely put that at the top of my list for the next time I am able to get access to the device.

Thanks,

Jamie

[Juan Perez · Accepted solution]

Hi Jamie,

You are welcome! What I mean is removing the ACLs applied under WAN interface.

Regards.

[jcopelandghs]

I suppose I could also go back and put log entries on those, or put a explicit deny at the end with log to replace the implied deny, that would let me see what may be blocking some of the traffic perhaps. I may try that as well.

[Juan Perez · Accepted solution]

Hi Jamie,

That will work as well.

[jcopelandghs]

I put in the log line for the end/implicit deny on that incoming ACL for my wan interface which is now GE0 on the new 891 and I see any kind of return traffic getting dropped.

So my nat is working and the traffic/requests are going outbound but when those various services/servers on the inet reply back it gets dropped.

I thought there was some kind of implicit way that natted traffic that was allowed out was allowed to have its replies come back in and still allow one to have a fairly locked down external wan interface acl.

Is there something different on the newer IOS/architecture where i have to let this traffic get identified in a different manner?

I want to dynamically allow replies to things active in my nat table without allowing any kind or unmatched traffic that is originating externally attempt to come in.

That may not have come across as clearly as I hoped but I think youll get the idea of what I am asking.

Thx!

-Jamie

[jcopelandghs]

Ok so on my wan interface I have added to the incoming ACL that..

'permit tcp any any established' and that seems to do what I was mentioning in the previous post. I guess Ill run with this and see what applications the users may have that wont work (most things are over the VPN anyways).

Thx

Jamie