cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
944
Views
0
Helpful
3
Replies

Serious Issue - ACL's not working on ASA5540

cbeswick
Level 1
Level 1

Hi,

I am running software version 7.2(1) on an ASA5540.

I have an inside interface configured on security level 100 and an outside interface configured with security level 0.

no nat-control has also been configured to permit traffic to flow through the device without the need for NAT configuration.

So in theory a client on the inside interface should be able to browse to a device on the outside interface, without NAT, it should just simply route to outside subnet. No additional ACL configuration should be required as the traffic is going from a high security level to a lower one.

This does not work. All TCP sessions time out with a SYN timeout.

Also, when trying to just carryout a simple ping to the device I am trying to connect to I get request timeouts on the client. This is particular interesting.

I have configured the inside interface to permit echo from the client source address as an inbound ACL. I have also configure echo-reply for the device on the outside / internet interface as an inbound ACL on the outside interface.

Even though I can see the icmp connections being built and torn down in the Logging window, the client machine on the inside keeps getting requests timeout.

No packet filtering is workin on the device. Has anyone encountered this or could perhaps explain to me why this is happening ?

I have attached the configuration of the ASA - albeit with a lot of ommissions.

1 Accepted Solution

Accepted Solutions

jgervia_2
Level 1
Level 1

Hello,

I don't see anything overly wrong with your config. I'd check the following:

1) Make sure the 217.x.x.x server knows about the 172.x RFC 1918 network and that it's routing back to the firewall correctly (not sure how many hops that is away from your firewall).

2) Run captures on both interfaces to see if you see the packet entering one interface and leaving the other interface.

3) try running a packet-trace to verify that the rules allow for everything to go through the firewall.

--Jason

Please rate this message if it solved some or all of your question/issue.

View solution in original post

3 Replies 3

jgervia_2
Level 1
Level 1

Hello,

I don't see anything overly wrong with your config. I'd check the following:

1) Make sure the 217.x.x.x server knows about the 172.x RFC 1918 network and that it's routing back to the firewall correctly (not sure how many hops that is away from your firewall).

2) Run captures on both interfaces to see if you see the packet entering one interface and leaving the other interface.

3) try running a packet-trace to verify that the rules allow for everything to go through the firewall.

--Jason

Please rate this message if it solved some or all of your question/issue.

Hi,

I think you have given me the answer. When I NAT the internal 172 address onto the outside subnet the connection works. This means that the ISP router doesn't have a route back to the inside network.

alanajjar
Level 1
Level 1

Hi,

I investigate your configuration on the fly,

i saw some thing that could cause this problem , that is in your configuration you secify a global (outside) , and you dont specify any NAT(interface) command, so i think this will prevent any translation.

Review Cisco Networking products for a $25 gift card