Remove Inspect from Interface

dennylester · ‎06-04-2007

We have a 1720 router with FW feature set. We currently have it inspecting traffic exiting INT S0.

Now that we have a Pix behind this router we want to remove the inspection on this 1720 to free up CPU resources and hopefully improve the MLPPP problems we are running into (dropped packets due to high CPU load).

I added the following line to the Inbound ACL on the S0 interface

access-list 103 permit tcp any any gt 1023 established

Then I removed the IP Inspect from that interface. At that point I was no longer able to access the Internet (I believe the return traffic was being blocked).

Are there any temp ACL's that might still be attached to the S0 interface left over from the IP Inspect?

Any theories?

Denny

sundar.palaniappan · ‎06-04-2007

Denny,

Can you check whether the access list entry you had added 'permit tcp any any gt 1023 established' isn't entered sequentially after the explicit 'deny any' statement.

HTH

Sundar

dennylester · ‎06-04-2007

Hello,

Thank you for the reply.

Yeah, I checked. Here is the access list

access-list 103 permit tcp any host x.x.x.28 eq domain

access-list 103 permit udp any host x.x.x.28 eq domain

access-list 103 permit tcp any host x.x.x.29 eq domain

access-list 103 permit udp any host x.x.x.29 eq domain

access-list 103 permit tcp any host x.x.x.29 eq ftp

access-list 103 permit tcp any host x.x.x.29 eq ftp-data

access-list 103 permit tcp any host x.x.x.35 eq smtp

access-list 103 permit tcp any host x.x.x.35 eq pop3

access-list 103 permit tcp any host x.x.x.35 eq www

access-list 103 permit tcp any host x.x.x.11 eq www

access-list 103 permit tcp any host x.x.x.37 eq www

access-list 103 permit tcp any host x.x.x.37 eq 443

access-list 103 permit tcp any host x.x.x.38 eq www

access-list 103 permit tcp any host x.x.x.38 eq 443

access-list 103 permit tcp any host x.x.x.39 eq www

access-list 103 permit tcp any host x.x.x.39 eq 443

access-list 103 permit tcp any host x.x.x.40 eq www

access-list 103 permit tcp any host x.x.x.40 eq 443

access-list 103 permit tcp any host x.x.x.41 eq www

access-list 103 permit tcp any host x.x.x.41 eq 443

access-list 103 permit tcp any host x.x.x.42 eq www

access-list 103 permit tcp any host x.x.x.42 eq 443

access-list 103 permit icmp any x.x.x.0 0.0.0.255 unreachable

access-list 103 permit icmp any x.x.x.0 0.0.0.255 echo-reply

access-list 103 permit icmp any x.x.x.0 0.0.0.255 packet-too-big

access-list 103 permit icmp any x.x.x.0 0.0.0.255 time-exceeded

access-list 103 permit icmp any x.x.x.0 0.0.0.255 administratively-prohibited

access-list 103 permit tcp any x.x.x.0 0.0.0.255 gt 1023 established

access-list 103 deny ip 127.0.0.0 0.255.255.255 any

access-list 103 deny ip any any

I know the final deny deny isn't really needed, I just like having it there so I can see the counters..

I'm wondering if the problem may be with my NAT setup.

When I drop the inspect is seems like I can access a webpage or two, then is just stops working. I can see the counters incrementing on the permit though..

The version in this router is a little old (12.1(21)), so that may be part of the problem.

sundar.palaniappan · ‎06-04-2007

Are you still doing NAT on the router even with the PIX in place? If you are still doing NAT on the router have the PIX do the NAT. Then try removing the access list from the router and test. I don't think the access list is the problem.

Perhaps if you can clarify the setup a little bit more and post the sanitized PIX and router configuration that would help.

dennylester · ‎06-04-2007

That does sound like the ideal solution.

Prior to the Pix this 1720 was doing all of our NAT as well as FW. The Pix was configured completely off-line then put in place. For a few years now we've had double NAT going. The Pix would NAT the Internal machines to one address, then the 1720 would NAT that to our public addresses. This worked/works perfectly fine. Because of this I don't think the issue is with the Pix or it's configuration

We just added a second Internet T1 and bundled them using MLPPP. Our connectivity is still working but the CPU is running high during peak traffic periods on the 1720 and it's dropping fragments/packets. I was hoping to just disable the FW on the 1720 without going through the hassle of reconfiguring our Pix to see if that would free up the CPU enough to run MLPPP properly. I guess disabling all that NAT would also free up CPU cycles too, so I'm sure that would be the proper way to do it.

I realize my configuration is more complicated this way but one of the benefits is if this Pix ever died, we could quickly switch back to this 1720 and suffer very minimal downtime.

I will review my Pix configuration and see how much work would be involved in making all the NAT changes and just have this 1720 route the Internet traffic.

Thank you for the suggestion.

Denny