09-09-2011 04:41 AM - edited 03-11-2019 02:22 PM
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?
Solved! Go to Solution.
09-12-2011 07:36 AM
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
09-12-2011 07:44 AM
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
09-12-2011 08:11 AM
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
09-12-2011 08:55 AM
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 ?
09-12-2011 09:08 AM
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
09-12-2011 09:26 AM
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?
09-12-2011 09:39 AM
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
09-13-2011 01:13 AM
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?
09-13-2011 01:23 AM
Hi Wez,
Is it fine if the dmz interface machines have access to the internet???
Thanks,
Varun
09-13-2011 01:42 AM
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.
09-13-2011 03:24 AM
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
09-13-2011 03:38 AM
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
09-13-2011 03:46 AM
Yes you would definitely need the command:
same-security-traffic permit inter-interface
09-13-2011 03:56 AM
All systems are go!
Thanks for all your help, you're a real asset to this community =)
09-13-2011 04:11 AM
Hey!!!!!!
Thats great news.....Thanks a lot and kudos to you as well in nailing down the issue so well.
Cheersss
Varun
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide