Broken communication between INSIDE and DMZ Zones

[Ricky Sandhu]

Good afternoon,  I've hit a bit of a wall so I'm requesting assistance from the experts.  I have a single router with interfaces Gi0/1.1 and Gi0/3 placed in IN-ZONE and DMZ-ZONE respectively.  The Zone-Pair with source as IN-ZONE and destination as DMZ-ZONE uses service policy POL-IN-DMZ.  This policy uses inspect type class-map called CLS-IN-DMZ and is configured to inspect the matching traffic.  The class-map calls an ACL that's basically permit IP any any.   So by doing this, I can forward packets from IN Zone to DMZ Zone.  This works as I am able to ping a webserver in DMZ from INSIDE.  Issue occurs when I try to load a webpage on a computer on my LAN (INSIDE) and try to connect to the same webserver mentioned above.  It just spins and spins and gets no where until it times out.  When I disable ZBFW from all interfaces,  the page loads fine.

I've been scratching my head for a while and was wondering if anyone has any other suggestions?  Please advise.

[Rob Ingram]

Hi @Ricky Sandhu can you provide the configuration for review please? you could enable logging on class-default which should provide a clue.

[Ricky Sandhu]

I have pasted the relevent configuration below.  Logging class-default doesn't show me anything be dropped.

class-map type inspect match-all CLS-IN-DMZ
match access-group name ACL-IN-DMZ
!
policy-map type inspect POL-IN-DMZ
class type inspect CLS-IN-DMZ
inspect
class class-default
drop log
!
zone security IN-ZONE
description Inside Zone
zone security DMZ-ZONE
description DMZ Zone
!
zone-pair security ZP-IN-DMZ source IN-ZONE destination DMZ-ZONE
service-policy type inspect POL-IN-DMZ
!
interface GigabitEthernet0/1
description LAN$FW_INSIDE$
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
ip flow monitor EXPMonitor input
ip flow monitor EXPMonitor output
duplex auto
speed auto
no snmp trap link-status
no mop enabled
!
interface GigabitEthernet0/1.1
encapsulation dot1Q 1 native
ip address 172.18.6.1 255.255.255.0 secondary
ip address 172.18.6.2 255.255.255.0
ip nat inside
no ip virtual-reassembly in
zone-member security IN-ZONE
ip tcp adjust-mss 1360
!
interface GigabitEthernet0/3
description $FW_DMZ$
ip address 10.10.7.1 255.255.255.0
ip flow egress
ip nat inside
no ip virtual-reassembly in
zone-member security DMZ-ZONE
ip tcp adjust-mss 1360
duplex auto
speed auto
no snmp trap link-status
!
interface GigabitEthernet0/0
desc $FW_WAN$
zone-member security OUT-ZONE
<CONFIGURATION REMOVED>
!
!
ip access-list extended ACL-IN-DMZ
permit ip any any

[Rob Ingram]

@Ricky Sandhu can you provide some outputs

show class-map type inspect
show policy-map type inspect
show zone-pair security
debug policy-firewall detail
debug policy-firewall events

show logging

[Ricky Sandhu]

Hi Rob,  I wanted to wait until after-hours to run the detailed debug commands.  I have been playing around and discovered that both my LAN port on the router (GE0/1.1) and DMZ port (GE0/3) are configured with ip nat inside.  When I ping a device in the DMZ, the packet simply gets routed (with it's real address as the source) rather than being subject to NAT (pat) behind GE0/3.  The device in the DMZ sees the packet coming from the real IP address of the client machine.  This DMZ device also has a leg directly in the LAN (don't ask), and it sends the reply over it's direct link.  You can see how this will cause an issue.  HOWEVER, what doesn't explain is why it works when disabling the firewall on the router.  It also works if I configure policy-maps in both direction to simply pass the traffic and not inspect it.

On the ASA you can configure source nat between two interfaces where packets sourced from one interface can use the IP address of the destination interface (overloading).  Is there a way to do that in IOS if both my ports are configured with ip nat inside?  Technically what I am trying to do is that packets coming from the LAN dynamically PAT behind GE0/3 even though GE0/3 is configured with ip nat inside.  Hope it makes sense.