ASA security levels

Answered Question
Apr 1st, 2009

Probably just something I am overlooking, but how do I allow return traffic from a lower security level interface to a higher one. My setup has E0/1 as the inside interface, then E0/2 is sub interfaced with 3 vlans, all at different security settings, 2 At 50 1 at 25. I setup nat (inside) 2 with an access list to nat the inside network to anything to the 10.0.0.0 network which goes out interface E0/2.2, a global (voice) 2 interface, using the IP of the voice e0/2.2 interface for PAT. I see translations, I see the router respond when I ping, but I dont see return traffic, obviously the ASA is dropping them. I verified this by setting security to 100 on the E0/2.2 interface and I can hit everything I need to. How can I do this with a lower security and ACL's?

I have this problem too.
0 votes
Correct Answer by Jon Marshall about 7 years 8 months ago

Todd

Could you do a quick schematic of your topology.

What is the default-gateway of clients on vlan 47 - is it the ASA subinterface ?

Before any of that could you change -

access-list Nat2Voip extended permit ip 10.10.48.0 255.255.252.0 10.0.0.0 255.0.0.0

to

access-list Nat2Voip extended permit ip 10.10.48.0 255.255.252.0 10.15.124.0 255.255.255.0

and retest.

Jon

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
Loading.
Jon Marshall Wed, 04/01/2009 - 08:35

Todd

TCP/UDP traffic return traffic will automatically be allowed back in because that is what a stateful firewall does.

However testing with ping is different because ICMP is not stateful in the same way. Have a look at this doc which explains how to allow ping through firewalls -

https://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a0080094e8a.shtml#topic2

Jon

tahequivoice Wed, 04/01/2009 - 09:17

Well, I have run into a very frustrating problem here, I have 3 subinterfaces on the E0/2 interface, the first one, the VOICE insterface, I can ping through and everything, 10.15.120.x, no problem I see the debugs both ends. However, I have another VLAN, 47, setup the same way, I have a WLC 4402 on this vlan, It seems none of the traffic for this subnet is hitting the ASA, I see no ICMP responses, but I can ping the WLC, nothing else on that VLAN though. Very frustrating. If I try to ping something on 10.1.3.x which I have routed via a static route on the ASA to the router on e0/2.2, I dont even see it hit the ASA.

interface Ethernet0/2.2

vlan 2

nameif Cisco-Voice

security-level 100

ip address 10.15.124.254 255.255.255.0

!

interface Ethernet0/2.47

vlan 47

nameif WLC-Management

security-level 100

ip address 10.10.47.254 255.255.255.0

access-list Nat2Voip extended permit ip 10.10.48.0 255.255.252.0 10.0.0.0 255.0.0.0

access-list Nat2WLC extended permit ip 10.10.48.0 255.255.252.0 10.10.47.0

255.255.255.0

global (outside) 1 interface

global (Cisco-Voice) 2 interface

global (WLC-Management) 3 interface

nat (inside) 2 access-list Nat2Voip

nat (inside) 3 access-list Nat2WLC

nat (inside) 1 10.10.48.0 255.255.252.0

nat (Guest) 1 192.168.168.0 255.255.255.0

route inside 10.1.3.0 255.255.255.0 10.15.124.1 1

S 10.1.3.0 255.255.255.0 [1/0] via 10.15.124.1, inside

C 10.10.47.0 255.255.255.0 is directly connected, WLC-Management

C 10.10.48.0 255.255.252.0 is directly connected, inside

C 10.15.124.0 255.255.255.0 is directly connected, Cisco-Voice

ICMP echo request from inside:10.10.48.10 to Cisco-Voice:10.15.124.1 ID=512 seq=10752 len=32

ICMP echo request translating inside:10.10.48.10/512 to Cisco-Voice:10.15.124.254/23852

ICMP echo reply from Cisco-Voice:10.15.124.1 to inside:10.15.124.254 ID=23852 seq=10752 len=32

ICMP echo reply untranslating Cisco-Voice:10.15.124.254/23852 to inside:10.10.48.10/512

There is a 3750 switch stack in between all this, the router and ASA is trunked into it. Could this be the switch causing this? For some reason the ASDM fails to launch as well. I get unnconnected sockets not implemented.

Correct Answer
Jon Marshall Wed, 04/01/2009 - 09:28

Todd

Could you do a quick schematic of your topology.

What is the default-gateway of clients on vlan 47 - is it the ASA subinterface ?

Before any of that could you change -

access-list Nat2Voip extended permit ip 10.10.48.0 255.255.252.0 10.0.0.0 255.0.0.0

to

access-list Nat2Voip extended permit ip 10.10.48.0 255.255.252.0 10.15.124.0 255.255.255.0

and retest.

Jon

tahequivoice Wed, 04/01/2009 - 09:40

:banging head:

It is always the simplest things. Changing the ACL seemed to work I can ping 10.10.47.1 now. I can pull up the WLC interface now. Thanks, too many days on this project have clouded my mind. Now to get the AP's working with guest access and I can install all this stuff on Friday! :)

Thanks again.

Edit, I reduced the security levels to 50 on those interfaces and they are working as they should now, damned ACL's get me every time. :)

Jon Marshall Wed, 04/01/2009 - 10:01

"Edit, I reduced the security levels to 50 on those interfaces and they are working as they should now, damned ACL's get me every time. :)"

It's always something. For me on a pix/asa i setup the NAT, acl's etc.. fine every time and then forget about routes and spend a good half an hour rechecking statics/acls :-)

Glad you got it working.

Jon

Yudong Wu Wed, 04/01/2009 - 08:37

If traffic is inspected, the reture traffic will be permitted automatically.

Check if icmp packet is inspected. If not, you can add it or use ACL to permit the return packet.

John Blakley Wed, 04/01/2009 - 08:41

If the packet is in the default inspection, would you still need to permit the return icmp packet inbound on the outside interface? And if so, would you only need to allow the echo-reply and not echo?

Thanks,

John

Jon Marshall Wed, 04/01/2009 - 08:47

John

"If the packet is in the default inspection, would you still need to permit the return icmp packet inbound on the outside interface?"

No you wouldn't, the above would be enough. But bear in mind that prior to v7.x code you didn't have this capability so you would need to allow the echo-reply back in with an acl.

Jon

Jon Marshall Wed, 04/01/2009 - 08:52

Well yes kind of.

The tcp inspect in CBAC is equivalent to the generic stateful firewall ie. TCP and UDP connections although strictly speaking the UDP connections don't have state so the firewall uses timers.

The more detailed inspects on CBAC and on the ASA have additional logic that allows them to "understand" part of the actual application protocol. Not all of it but enough to securely allow it through a firewall.

Just for your reference prior to v7.x the inspect features on pix firewalls were referred to as "fixups".

Jon

Actions

This Discussion