cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

Welcome to Cisco Firewalls Community


682
Views
0
Helpful
2
Replies
Highlighted
Beginner

ASA 8.4 - Static NAT configuration ignoring outside ACL

Hi,

I have an inside host configured with it's own external IP (not the outside IP), that seems to be ignoring the ACL configured for the outside interface. All traffic is passing.

My config looks like this:

interface Vlan1

nameif inside

security-level 100

ip address 172.16.33.253 255.255.255.0

interface Vlan2

nameif outside

security-level 0

ip address XXX.XXX.XXX.1 255.255.255.248

object network host-dunstable-blackberry

host 172.16.33.213

nat (inside,outside) static XXX.XXX.XXX.2

access-list acl-outside-in extended deny tcp any object host-dunstable-blackberry eq ssh

access-group acl-outside-in in interface outside

XXX.XXX.XXX.2 falls within XXX.XXX.XXX.1 255.255.255.248

Even so, I'm still able to SSH from an unrelated IP, to XXX.XXX.XXX.2, and access my server.

Does anybody have any ideas? Is this by design? If so, how can I restrict access to this machine?

Any help would be greatly appreciated,

John

Everyone's tags (4)
1 ACCEPTED SOLUTION

Accepted Solutions
Mentor

ASA 8.4 - Static NAT configuration ignoring outside ACL

Hi,

Can you provide us with the output of the following command (Naturally fill in the actual public IP)

packet-tracer input outside tcp 1.1.1.1 12345 x.x.x.2 22

This should probably tell us what is allowing the traffic.

- Jouni

View solution in original post

2 REPLIES 2
Mentor

ASA 8.4 - Static NAT configuration ignoring outside ACL

Hi,

Can you provide us with the output of the following command (Naturally fill in the actual public IP)

packet-tracer input outside tcp 1.1.1.1 12345 x.x.x.2 22

This should probably tell us what is allowing the traffic.

- Jouni

View solution in original post

Beginner

ASA 8.4 - Static NAT configuration ignoring outside ACL

Hi Jouni,

Thanks for taking the time to look at this. Performing the packet-trace shows that the traffic being blocked by the implicit deny on the outside interface.

Attempting to connect again showed that this was indeed the case.

I have no idea what was happening before, but everything seems to be working fine. It must be user error, but I'm certain I tested correctly initially... very confusing!

Thanks again,

John

CreatePlease to create content
Content for Community-Ad
FusionCharts will render here