cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
7192
Views
31
Helpful
29
Replies

Firewall blocking traffic between VLANS/subnets

KingPrawns
Level 1
Level 1

Here's the problem we've encountered, was hoping you guys could help me debug what the heck is going on:


In the below diagram, computers on 10.20.1.x cannot ping anything on the 10.20.3.x subnet (Including Firewall B).
However, Firewall A can ping Firewall B and the .3.x server so it's not a VLAN routing problem.

The strange thing is that according to the ASDM Packet trace on Firewall A (Screenshot), packets are allowed to travel freely between the internal pc's and the .3.x subnet servers.

I'm positive the fault lies with Firewall A, but the running config file is way too big to post here so I'll try dig out what looks relevant.

We have the following NAT rule which I would have though was the solution but that doesn't seem to help:

     static (inside,bt_dmz) 10.20.1.0 10.20.1.0 netmask 255.255.255.0

(bt_dmz is the interface on Firewall A that runs through to the 10.20.3.x subnet)

We also have icmp permitted:

     icmp permit 10.20.1.0 255.255.255.0 inside

     icmp permit 10.20.2.0 255.255.255.0 dmz

     icmp permit 10.20.3.0 255.255.255.0 bt_dmz

Access list rule:

     access-list outside_access_in_dmz extended permit icmp any any

If Firewall A can ping Firewall B and the server, it feels like routing between VLANS is ok but why then can I not ping the server on that VLAN from my internal PC? Could there be a conflicting rule?

29 Replies 29

Hi Wez,

doubt a few things, can you plz delete the statement:

static (inside,dmz) 10.20.1.0 10.20.1.0

and try again, if it does not work, i would need the output of:

packet-tracer input inside icmp 10.20.1.161 0 8 10.20.3.151 detailed

taken from the cli and not the wizard.

Thanks,

Varun

Thanks,
Varun Rao

I'm a little worried about deleting static (inside,dmz) 10.20.1.0 10.20.1.0 since I'm sure that relates to our existing servers (10.20.2.x) which we use on a regular basis. Would removing it stop us from connectiong between inside and dmz ?

Here is the output before removing the rule:

# packet-tracer input inside icmp 10.20.1.161 0 8 10.20.13.151 detailed

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xd555a118, priority=1, domain=permit, deny=false

        hits=34883336, user_data=0x0, cs_id=0x0, l3_type=0x8

        src mac=0000.0000.0000, mask=0000.0000.0000

        dst mac=0000.0000.0000, mask=0000.0000.0000

Phase: 2

Type: FLOW-LOOKUP

Subtype:

Result: ALLOW

Config:

Additional Information:

Found no matching flow, creating a new flow

Phase: 3

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   0.0.0.0         0.0.0.0         outside

Phase: 4

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group inside_access_in_1 in interface inside

access-list inside_access_in_1 extended permit ip any any

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xd5662268, priority=12, domain=permit, deny=false

        hits=1025011, user_data=0xd5662228, cs_id=0x0, flags=0x0, protocol=0

        src ip=0.0.0.0, mask=0.0.0.0, port=0

        dst ip=0.0.0.0, mask=0.0.0.0, port=0

Phase: 5

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xd555c2e0, priority=0, domain=permit-ip-option, deny=true

        hits=1028573, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0

        src ip=0.0.0.0, mask=0.0.0.0, port=0

        dst ip=0.0.0.0, mask=0.0.0.0, port=0

Phase: 6

Type: INSPECT

Subtype: np-inspect

Result: ALLOW

Config:

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xd555b5e8, priority=66, domain=inspect-icmp-error, deny=false

        hits=3541, user_data=0xd553c368, cs_id=0x0, use_real_addr, flags=0x0, pr                                                                              otocol=1

        src ip=0.0.0.0, mask=0.0.0.0, port=0

        dst ip=0.0.0.0, mask=0.0.0.0, port=0

Phase: 7

Type: NAT

Subtype: host-limits

Result: ALLOW

Config:

static (inside,dmz) 10.20.1.0 10.20.1.0 netmask 255.255.255.0

  match ip inside 10.20.1.0 255.255.255.0 dmz any

    static translation to 10.20.1.0

    translate_hits = 561088, untranslate_hits = 18184

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xd5619e40, priority=5, domain=host, deny=false

        hits=1027904, user_data=0xd56198c0, cs_id=0x0, reverse, flags=0x0, proto                                                                              col=0

        src ip=10.20.1.0, mask=255.255.255.0, port=0

        dst ip=0.0.0.0, mask=0.0.0.0, port=0

Phase: 8

Type: NAT

Subtype:

Result: DROP

Config:

nat (inside) 101 0.0.0.0 0.0.0.0

  match ip inside any outside any

    dynamic translation to pool 101 (82.20.64.129 [Interface PAT])

    translate_hits = 463950, untranslate_hits = 118304

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xd5616e00, priority=1, domain=nat, deny=false

        hits=788736, user_data=0xd5616d60, cs_id=0x0, flags=0x0, protocol=0

        src ip=0.0.0.0, mask=0.0.0.0, port=0

        dst ip=0.0.0.0, mask=0.0.0.0, port=0

Result:

input-interface: inside

input-status: up

input-line-status: up

output-interface: outside

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule

Hi Wez,

I see that the traffic is hitting the static statement instead of the nat statement. and if you remember my first post:

Varun Rao wrote:

I was answering to your thread but I guess you moved it by then

Well  I woudl say take captures and analyse, thats the best thing. Check  where the packets are getting dropped. Also you woudl need a nat  statement for translating the source traffic On firewall 1, something  like this:

nat (inside) 10 10.20.1.0 255.255.255.0

global (dmz) 10 interface

On the firewall 2, you shoudl have the following: static (inside,dmz) 10.20.1.0 10.20.1.0

I  would request you to kindly try it and take captures. On firewall 2 as
well you need the access-list going from dmz to inside, so plz make  sure.

So I had suggested you this, so I think thats when you added it. Correct me if I am wrong.

Thanks,

Varun

Thanks,
Varun Rao

Sorry, I should have mentioned that I tweaked that to:

          static (inside,bt_dmz) 10.20.1.0 10.20.1.0 netmask 255.255.255.0

However, removing that seems to have done the trick! I can rdp and ping that server absolutely fine now.

Second tickbox is getting servers on 10.20.2.x to be able to ping 10.20.3.x.

The packet trace is failing on

Phase: 4

Type: ACCESS-LIST

Subtype:

Result: DROP

Config:

Implicit Rule

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xd55366e8, priority=110, domain=permit, deny=true

        hits=14, user_data=0x0, cs_id=0x0, flags=0x3000, protocol=0

        src ip=0.0.0.0, mask=0.0.0.0, port=0

        dst ip=0.0.0.0, mask=0.0.0.0, port=0

Does that mean I need to add something like access-list dmz_to_bt_dmz extended permit ip any any to the access list?

Also, would I need static (dmz,bt_dmz) 10.20.2.0 10.20.2.0 netmask 255.255.255.0 ?

Excellent!!!!!!!!! So one issue has been knocked out

Coming to the next, you need to just add this:

nat (dmz) 102 0.0.0.0 0.0.0.0

global (bt_dmz) 102 interface

and

access-list dmz_to_inside extended permit icmp any any
same-security-traffic permit inter-interface

and it should work.

If it does, I would need the complete packet-tracer output.

Thanks,

Varun

Thanks,
Varun Rao

Trying to add the global rule and getting the error : global for this range already exists

I think it'd be conflicting with the one we put in earlier ( global (bt_dmz) 101 interface ). Do we have to make that dynamic in some way?

Hi Wez,

Be careful this time, I changed the nat ID's. It using 102 now:

nat (dmz) 102 0.0.0.0 0.0.0.0

global (bt_dmz) 102 interface

If i used 101, then your dmz would also be able to access the internet, so i changed it, so that it is only able to access the bt_dmz machines.

Thanks,

Varun

Thanks,
Varun Rao

I follow what you're saying but still get the global already exists error:

gw(config)# sho run global

global (outside) 101 interface

global (BT_Outside) 103 interface

global (bt_dmz) 101 interface

gw(config)# sho run nat

nat (inside) 0 access-list inside_nat0_outbound

nat (inside) 101 0.0.0.0 0.0.0.0

nat (dmz) 102 0.0.0.0 0.0.0.0

gw(config)# global (bt_dmz) 102 interface

global for this range already exists

Is it because we already have a global (bt_dmz) in there?

Hi Wez,

Is it fine if the dmz interface machines have access to the internet???

Thanks,

Varun

Thanks,
Varun Rao

The DMZ machines already have access to the internet via line 1, and the bt_dmz machines have access to the internet on line 2 (referring to the picture I posted when starting the thread).

Ideally I dont want this to change, but out backup server will still be on 10.20.2.x so I want to be able to backup machines from the 10.20.3.x subnet.

Hi Wez,

well if that is the case then we would not need these two statements:

nat (dmz) 102 0.0.0.0 0.0.0.0

global (bt_dmz) 102 interface

Intsead just add:

nat (dmz) 101 0.0.0.0 0.0.0.0

And test the ping after that.

Thanks,

Varun

Thanks,
Varun Rao

Hi Varun,

I changed the nat rule from 102 to 101, but still not able to ping through.

Here's the result of the packet trace:

     Phase: 1

     Type: FLOW-LOOKUP

     Subtype:

     Result: ALLOW

     Config:

     Additional Information:

     Found no matching flow, creating a new flow

     Phase: 2

     Type: ROUTE-LOOKUP

     Subtype: input

     Result: ALLOW

     Config:

     Additional Information:

     in   10.20.3.0       255.255.255.0   bt_dmz

     Phase: 3

     Type: ACCESS-LIST

     Subtype:

     Result: DROP

     Config:

     Implicit Rule

     Additional Information:

      Forward Flow based lookup yields rule:

      in  id=0xd55366e8, priority=110, domain=permit, deny=true

             hits=23, user_data=0x0, cs_id=0x0, flags=0x3000, protocol=0

             src ip=0.0.0.0, mask=0.0.0.0, port=0

             dst ip=0.0.0.0, mask=0.0.0.0, port=0

     Result:

     input-interface: dmz

     input-status: up

     input-line-status: up

     output-interface: bt_dmz

     output-status: up

     output-line-status: up

     Action: drop

     Drop-reason: (acl-drop) Flow is denied by configured rule

Do I still need to include this?

same-security-traffic permit inter-interface

Yes you would definitely need the command:

same-security-traffic permit inter-interface
Thanks,
Varun Rao

All systems are go!

Thanks for all your help, you're a real asset to this community =)

Hey!!!!!!

Thats great news.....Thanks a lot and kudos to you as well in nailing down the issue so well.

Cheersss

Varun

Thanks,
Varun Rao
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: