+ Reply to Thread
Results 1 to 22 of 22
  1. Senior Member
    Join Date
    Mar 2011
    Posts
    431
    #1

    Default Zone-Based Firewall Problem

    I can't seem to get my HTTP traffic through the Zone-Based Firewall; think the NAT might be confusing me. Here is my configuration on GNS3:

    Code:
    R1#show run
    Building configuration...
    
    Current configuration : 1773 bytes
    !
    version 12.4
    service timestamps debug datetime msec
    service timestamps log datetime msec
    no service password-encryption
    !
    hostname R1
    !
    boot-start-marker
    boot-end-marker
    !
    no aaa new-model
    ip cef
    !
    ip domain name lab.local
    ip name-server 194.168.4.100
    ip name-server 194.168.8.100
    !
    multilink bundle-name authenticated
    !
    class-map type inspect match-all INSIDE-TO-OUTSIDE-CLASS
     match access-group name INSIDE-TO-OUTSIDE
    !
    policy-map type inspect INSIDE-TO-OUTSIDE-POLICY
     class type inspect INSIDE-TO-OUTSIDE-CLASS
      inspect
     class class-default
      drop log
    !
    zone security INSIDE
    zone security OUTSIDE
    zone-pair security INSIDE-TO-OUTSIDE source INSIDE destination OUTSIDE
     service-policy type inspect INSIDE-TO-OUTSIDE-POLICY
    !
    interface FastEthernet0/0
     no ip address
     shutdown
     duplex half
    !
    interface FastEthernet1/0
     ip address 192.168.0.254 255.255.255.0
     ip nat outside
     ip virtual-reassembly
     zone-member security OUTSIDE
     duplex half
    !
    interface FastEthernet2/0
     ip address 172.16.0.254 255.255.255.0
     ip nat inside
     ip virtual-reassembly
     zone-member security INSIDE
     duplex half
    !
    ip route 0.0.0.0 0.0.0.0 192.168.0.1
    no ip http server
    no ip http secure-server
    !
    ip nat inside source list NAT interface FastEthernet1/0 overload
    !
    ip access-list standard NAT
     permit 172.16.0.0 0.0.0.255
    !
    ip access-list extended INSIDE-TO-OUTSIDE
     permit tcp 172.16.0.0 0.0.0.255 any eq www
     permit tcp 172.16.0.0 0.0.0.255 any eq domain
    !
    logging alarm informational
    !
    control-plane
    !
    gatekeeper
     shutdown
    !
    line con 0
     exec-timeout 0 0
     privilege level 15
     logging synchronous
     stopbits 1
    line aux 0
     exec-timeout 0 0
     privilege level 15
     logging synchronous
     stopbits 1
    line vty 0 4
     login
    !
    end
    I'm NATing the internal network (172.16.0.0/24) to 192.168.0.254 as that is private network configured on my home router. There is a default route to my home router (192.168.0.1), and that is obviously going to be NATed again (which I have no control over) before traffic leaves.

    My permit statements in the class-map is for the internal 172.16.0.0/24 network... is that correct? I'm not exactly sure how Zone-Based Firewall works with NAT. Logs are showing that DNS traffic is being dropped:

    Code:
    *Jul 20 01:32:41.183: %FW-6-DROP_PKT: Dropping Other pkt 192.168.0.254:44646 => 208.67.222.222:53 with ip ident 27112 due to DROP action found in policy-map
    Why would DNS be dropped? I thought 192.168.0.254 would be considered to be in the self zone, and therefore be permitted anyway?
    Reply With Quote Quote  

  2. SS -->
  3. Senior Member
    Join Date
    Mar 2013
    Location
    .
    Posts
    319

    Certifications
    .
    #2
    It's not coming from "self," as your router is not originating the traffic, and it is not traffic for a daemon running on your router. The packet appears sourced from your router, only because it was translated to 192.168.0.254.

    You just need to add the NAT'd to address (192.168.0.254) to your INSIDE-TO-OUTSIDE access-list. On that external interface, inbound filtering occurs 'pre-nat' while outboud occurs 'post-nat'
    Last edited by powmia; 07-22-2013 at 11:57 AM.
    Reply With Quote Quote  

  4. Senior Member
    Join Date
    Mar 2011
    Posts
    431
    #3
    Quote Originally Posted by powmia View Post
    It's not coming from "self," as your router is not originating the traffic, and it is not traffic for a daemon running on your router. The packet appears sourced from your router, only because it was translated to 192.168.0.254.

    You just need to add the NAT'd to address (192.168.0.254) to your INSIDE-TO-OUTSIDE access-list. On that external interface, inbound filtering occurs 'pre-nat' while outboud occurs 'post-nat'
    I did try that but it didn't seem to make a difference... I'll try again to be sure and post back. Thank you.
    Reply With Quote Quote  

  5. Senior Member
    Join Date
    Mar 2013
    Location
    .
    Posts
    319

    Certifications
    .
    #4
    Oh, didn't look at that close enough. DNS uses TCP for zone-transfers, UDP is for queries. Use UDP.
    Reply With Quote Quote  

  6. Senior Member
    Join Date
    Mar 2013
    Location
    .
    Posts
    319

    Certifications
    .
    #5
    And I think you can disregard my previous post... statefulness of your setup should just need the internal addresses in the ACL. Sorry about that... in need of coffee.
    Reply With Quote Quote  

  7. Senior Member
    Join Date
    Mar 2011
    Posts
    431
    #6
    I've put in everything just to be sure but it still doesn't seem to work...

    Standard IP access list NAT
    10 permit 172.16.0.0, wildcard bits 0.0.0.255 (127 matches)
    Extended IP access list INSIDE-TO-OUTSIDE
    10 permit tcp 172.16.0.0 0.0.0.255 any eq www (49 matches)
    20 permit tcp 172.16.0.0 0.0.0.255 any eq domain
    30 permit udp 172.16.0.0 0.0.0.255 any eq domain (209 matches)
    40 permit udp 192.168.0.0 0.0.0.255 any eq domain
    50 permit tcp 192.168.0.0 0.0.0.255 any eq domain
    60 permit tcp 192.168.0.0 0.0.0.255 any eq www

    Everything else is exactly the same as before. I'm no longer getting log messages so I guess the traffic is going out but the return traffic isn't getting back to the host? :S
    Reply With Quote Quote  

  8. Senior Member
    Join Date
    Mar 2011
    Posts
    431
    #7
    Wireshark shows that 192.168.0.254 is ARPing for 192.168.0.1 but never seems to get a response... not sure why that would be.
    Reply With Quote Quote  

  9. Senior Member
    Join Date
    Mar 2013
    Location
    .
    Posts
    319

    Certifications
    .
    #8
    gns3???
    Reply With Quote Quote  

  10. Senior Member
    Join Date
    Mar 2011
    Posts
    431
    #9
    Yes GNS3 ...makes doing even the most simplest of tasks a pain in the bottom.
    Reply With Quote Quote  

  11. Senior Member
    Join Date
    Mar 2013
    Location
    .
    Posts
    319

    Certifications
    .
    #10
    Yeah, before you go on a troubleshooting fit... I would save the configs and rebuild your topology.
    Reply With Quote Quote  

  12. Senior Member
    Join Date
    Mar 2011
    Posts
    431
    #11
    Did that multiple times... anyway not to worry -- thanks mate.
    Reply With Quote Quote  

  13. Senior Member
    Join Date
    Mar 2010
    Location
    Los Angeles, California
    Posts
    200

    Certifications
    A+, Project+, Network+, Security+, CCNA: Security, CCNP R&S, CCDP, CCNP Security
    #12
    Have you tried to make sure if it works with out the ZBF configuration?
    Quote Originally Posted by Eildor View Post
    Did that multiple times... anyway not to worry -- thanks mate.
    Reply With Quote Quote  

  14. Senior Member
    Join Date
    Mar 2011
    Posts
    431
    #13
    As far as I can remember (I've redone everything like 5 times so I could be wrong) it worked fine without ZBF. Anyway no worries I don't want to spend any more time on it. Cheers!
    Reply With Quote Quote  

  15. Senior Member
    Join Date
    Mar 2010
    Location
    Los Angeles, California
    Posts
    200

    Certifications
    A+, Project+, Network+, Security+, CCNA: Security, CCNP R&S, CCDP, CCNP Security
    #14
    lol don't give up!. run some debug policy-firewall commands and see what is happening.
    Quote Originally Posted by Eildor View Post
    As far as I can remember (I've redone everything like 5 times so I could be wrong) it worked fine without ZBF. Anyway no worries I don't want to spend any more time on it. Cheers!
    Reply With Quote Quote  

  16. Senior Member
    Join Date
    Mar 2011
    Posts
    431
    #15
    It's set to log dropped packets... nothing is showing up at all so I guess the traffic is going out but not being allowed back in. I'll look into it when I get the chance one last time.
    Reply With Quote Quote  

  17. Senior Member
    Join Date
    Mar 2011
    Posts
    431
    #16
    Could the problem be the fact that I am using Linux on the VMs? I'm going to download Windows XP and see if that helps.
    Reply With Quote Quote  

  18. Senior Member Mrock4's Avatar
    Join Date
    Nov 2004
    Posts
    2,327

    Certifications
    CCDA, CCNA, CCNP, CCIE R&S, Security+, CISSP, SCP #2235, CCNA: DC
    #17
    I labbed up your almost exact config (except interface names), and was successful in reaching the end device. I connected the devices in a series, such as: R2 ----- R3 ----- R10 .....I utilized an existing topology I had for this, so that's why the hostnames are not in order. R3 was doing the ZBF and NAT. R10 had the IP of 192.168.0.1, and R2 had the IP of 172.16.0.1. .254 resides on the R3 interfaces.

    See screenshots:

    http://www.sgtccie.com/images/ZBF_issue.png (Shows successful telnet from R2 to R10)
    http://www.sgtccie.com/images/ZBF_issue2.png (Shows config of R3)
    Reply With Quote Quote  

  19. Senior Member
    Join Date
    Mar 2011
    Posts
    431
    #18
    Argh this is doing my head in... feel like I'm wasting my time. Thanks for all the help, I'll get there eventually...
    Reply With Quote Quote  

  20. Senior Member Mrock4's Avatar
    Join Date
    Nov 2004
    Posts
    2,327

    Certifications
    CCDA, CCNA, CCNP, CCIE R&S, Security+, CISSP, SCP #2235, CCNA: DC
    #19
    No worries. Have you run a wireshark capture at the host to see if traffic is reaching it? I know you said you saw .254 ARPing, but does the .1 address see those ARP requests? I'd be willing to venture if you solve the unanswered ARP you will solve your problem (big surprise, right?)

    Best of luck!
    Reply With Quote Quote  

  21. Senior Member
    Join Date
    Mar 2011
    Posts
    431
    #20
    Everything now seems to be working... don't ask me why because I have absolutely no clue as I tried over 9000 different things, including: changing software firewall (Comodo and GNS3 do NOT get along), using Windows XP on VMs instead of Linux, pulling my hair out, etc.

    Hopefully I don't have this much trouble setting up ASA on GNS3... thanks again.
    Reply With Quote Quote  

  22. Senior Member
    Join Date
    Mar 2010
    Location
    Los Angeles, California
    Posts
    200

    Certifications
    A+, Project+, Network+, Security+, CCNA: Security, CCNP R&S, CCDP, CCNP Security
    #21
    Sounds like the 9001 try was it...

    Quote Originally Posted by Eildor View Post
    Everything now seems to be working... don't ask me why because I have absolutely no clue as I tried over 9000 different things, including: changing software firewall (Comodo and GNS3 do NOT get along), using Windows XP on VMs instead of Linux, pulling my hair out, etc.

    Hopefully I don't have this much trouble setting up ASA on GNS3... thanks again.
    Reply With Quote Quote  

  23. Senior Member
    Join Date
    Mar 2011
    Posts
    431
    #22
    I'm just glad it's working now... ASA is up and running as expected too
    Reply With Quote Quote  

+ Reply to Thread

Social Networking & Bookmarks