Solved: How are my ASAs handling my traffic?

Scott Cannon · ‎03-22-2010

Hi Guys,

I'm wandering if you can help me solve a little problem I have....I have 2 DMZs on my ASA5510 (running ASA 7.0(6)), A & B.

Members of DMZ A are in the 172.19.10.0/24 subnet and members of DMZ B are in the 192.168.100.0/24 subnet.

When I review the firewall I find that access should be unfettered for users in DMZ B accessing DMZ A, with the following rule in place on the DMZ B interface of the firewall:

access-list dbavpn line 9 extended permit ip 192.168.100.0 255.255.255.0 any

Routing seems to be properly configure on the firewall, as indicated below:

C 172.19.1.0 255.255.255.0 is directly connected, inside
S 172.19.10.0 255.255.255.0 [1/0] via 172.19.1.1, inside

However when I do a packet capture on the FW I see packets coming in the DMZ B facing interface but not going out the DMZ A facing interface, see output below:

capture IN type raw-data access-list TO_172.19.10.12 interface DMZB circular-buffer[Capturing - 738 bytes]

capture OUT type raw-data access-list TO_172.19.10.12 interface DMZA circular-buffer[Capturing - 0 bytes]
NB: access-list TO_172.19.10.12 line 1 extended permit ip any host 172.19.10.12 (hitcnt=9)

I've checked, and there is no NAT configured for the DMZ B facing interface, and all NAT on the DMZ A facing interface is based on source addresses not aligned with the 192.168.100.0 subnet.

I'm new to ASA and I'm at a loss at to what the firewall is doing with this traffic. If you have any ideas I'd be glad to hear them.

Thanks in advance

Rgds

Scott

Kureli Sankar · ‎03-22-2010

This static route 172.19.10.0 255.255.255.0 [1/0] via 172.19.1.1, inside seems incorrect.

You said this network 172.19.10.0/24 lives behind the DMZ-A. Pls. remove that static route.

What is the security level for DMZ-A and DMZ-B?

Depending on that you need the static below. Let us say DMZ-A has a higher level security than DMZ-B then you need the following:

static (DMZ-A, DMZ-B) 172.19.10.0 172.19.10.0 net 255.255.255.0

You can remove the caputres configured

no cap IN

no cap OUT

Follow this link to collect fresh set of captures if needed:

https://supportforums.cisco.com/docs/DOC-1222;jsessionid=A11197443F5D79D04565C4331EFA5806.node0

-KS

View solution in original post

Kureli Sankar · ‎03-22-2010

This static route 172.19.10.0 255.255.255.0 [1/0] via 172.19.1.1, inside seems incorrect.

You said this network 172.19.10.0/24 lives behind the DMZ-A. Pls. remove that static route.

What is the security level for DMZ-A and DMZ-B?

Depending on that you need the static below. Let us say DMZ-A has a higher level security than DMZ-B then you need the following:

static (DMZ-A, DMZ-B) 172.19.10.0 172.19.10.0 net 255.255.255.0

You can remove the caputres configured

no cap IN

no cap OUT

Follow this link to collect fresh set of captures if needed:

https://supportforums.cisco.com/docs/DOC-1222;jsessionid=A11197443F5D79D04565C4331EFA5806.node0

-KS

Scott Cannon · ‎03-22-2010

Hi KS,

Sorry about the bumsteer with the routes, I should have edited that out before I posted (its correct for our environment, but not for the hypothetical I was posting to this discussion)

Thanks for your help. The static NAT rule did the job.

I am curious as to why it worked though.... both DMZs are configured to route traffic to each other, so why do I even need NAT at all? If it's unconfigured its not applied right?

Rgds

Scott

Kureli Sankar · ‎03-22-2010

May be next time you can edit it really good. We focus on all the lines that would pertain to the networks that you listed.

Anyway, the static rule worked because you probably had nat-control enabled.

You need

1. route

2. translation

3. permission

all three for any traffic to traverse the firewall. If you want to disable nat then you have to issue "no nat-control".

static 1-1 nat is birectional. You need this going high to low and automatically low to high (meaning traffic initiated from the lower security interface) will be allowed due to its bidirectional nature provided acl allows it.

-KS

Scott Cannon · ‎03-22-2010

Thanks for the heads-up, I had no idea.

Cheers

Scott