Solved! Go to Solution.
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.
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.
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.
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).