Andriy, I forgot to update the list, but I already figured out what you explained :) Once I made the class-maps more specific(for example specified that matching protocol is TFTP), the issues described in previous e-mails were resolved.
regards, Martin On Mon, Sep 2, 2013 at 2:57 PM, Andriy Bilous <andriy.bil...@gmail.com>wrote: > You need to match on the exact protocol to make ZBF work properly. In your > first example you match and inspect on access-list 102 which is IP and IP > header have not enough information to link echo with corresponding > echo-reply. TFTP is asymmetrical - ZBF should work with it though (again > with appropriate 'inspect'). As for 'debugging' ICMP types I'm not sure > you're going to get it working. > > PS. You might also want to consider CBAC which is the "predecessor" of ZBF > and often looks more tidy in tiny installations. > > > On Sun, Sep 1, 2013 at 12:40 AM, Martin T <m4rtn...@gmail.com> wrote: > >> I think I'll go with the reflective ACL option as it's supported on my >> Cisco 1841 and it does, with few exceptions explained below, what I >> need. >> >> As shown in my previous e-mail, ACL setup looks like this: >> >> ! >> interface Vlan5 >> description -> T42 eth0 >> ip address 192.168.1.1 255.255.255.0 >> ip access-group LAN->Wi-Fi in >> ip access-group Wi-Fi->LAN out >> ip nat inside >> ip virtual-reassembly in >> ! >> ! >> ip access-list extended LAN->Wi-Fi >> permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 reflect >> ALL-IP-TRAFFIC timeout 10 >> permit ip any any >> ip access-list extended Wi-Fi->LAN >> evaluate ALL-IP-TRAFFIC >> deny ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255 >> permit ip any any >> ! >> >> While I have not discovered any issues with TCP and ICMP, the UDP is >> somewhat problematic. For example if I run a TFTP server in >> 192.168.2.2 machine and want to get a file from this TFTP server using >> a TFTP client in 192.168.1.2, then UDP data packets from 192.168.2.2 >> do not get through and I see timeouts in 192.168.1.2 machine: >> >> T42 ~ # atftp 192.168.2.2 69 >> tftp> get RAID_BIOS_update.PNG >> timeout: retrying... >> timeout: retrying... >> timeout: retrying... >> timeout: retrying... >> timeout: retrying... >> timeout: retrying... >> tftp: aborting >> tftp> quit >> T42 ~ # >> >> >> Here is an IP ACL "Packet forwarding path debugging" log if I execute >> "get RAID_BIOS_update.PNG" command in TFTP client. TFTP client read >> request packet and first TFTP server data packet : >> >> R3# >> *Aug 31 22:44:45.696: IPACL-DP: Reflexive ACL: Punt the packet as we >> are in interrupt context >> *Aug 31 22:44:45.700: IPACL-DP: Pkt matched ACL: LAN->Wi-Fi seq: 30 >> Action: Deny >> *Aug 31 22:44:45.700: IPACL-DP: Pkt matched punt/drop it >> *Aug 31 22:44:45.700: IPACL-DP: Pkt is punted to process path from cef >> path: interface Vlan5 inbound direction >> *Aug 31 22:44:45.700: IPACL-DP: New Reflexive acl entry created for the >> flow >> *Aug 31 22:44:45.700: IPACL-DP: Pkt matched ACL: LAN->Wi-Fi seq: 30 >> Action: Permit >> *Aug 31 22:44:45.700: IPACL-DP: Pkt matched permit it >> *Aug 31 22:44:45.700: IPACL-DP: Pkt is permitted in process path: >> interface Vlan5 inbound direction >> R3# >> *Aug 31 22:44:45.712: IPACL-DP: Pkt matched ACL: Wi-Fi->LAN seq: 20 >> Action: Deny >> *Aug 31 22:44:45.712: IPACL-DP: Pkt matched punt/drop it >> *Aug 31 22:44:45.712: IPACL-DP: Pkt is punted to process path from cef >> path: interface Vlan5 outbound direction >> *Aug 31 22:44:45.716: IPACL-DP: Pkt matched ACL: Wi-Fi->LAN seq: 20 >> Action: Deny >> *Aug 31 22:44:45.716: IPACL-DP: Pkt matched punt/drop it >> *Aug 31 22:44:45.716: IPACL-DP: Pkt is dropped in process path: >> interface Vlan5 outbound direction >> R3# >> >> >> The 192.168.2.2 machine, where TFTP server is running, will receive >> ICMP "communication administratively filtered" error messages. In a >> nutshell, IOS reflective ACL is not able to associate TFTP client read >> request with TFTP server data packets sent back to TFTP client? >> >> >> Second example is with ICMP error messages explained in my previous >> e-mail: >> >> I do not have DNS server running in 192.168.2.2. Now if I execute "dig >> @192.168.2.2 www.google.com" in 192.168.1.2 machine, the ICMP "port >> unreachable" messages sent by 192.168.2.2 to 192.168.1.2 do not reach >> 192.168.1.2. In other words, looks like router is not able to >> associate those ICMP error messages with DNS queries. >> >> >> Are there such stateful firewalls out there which are able to make the >> associations explained in those examples? Probably not on IOS >> platform? Or are most of those stateful firewalls struggling with >> connectionless protocols? >> >> >> regards, >> Martin >> >> >> On 8/30/13, Darren O'Connor <darre...@outlook.com> wrote: >> > This is the expected behaviour with ICMP. But as noted you cna use a >> > standard ACP to only allow certain ICMP packets in either direction. >> inspect >> > only TCP and UDP and allow ICMP, but through ACL >> > >> > Thanks >> > Darren >> > http://www.mellowd.co.uk/ccie >> > >> > >> > >> > Date: Fri, 30 Aug 2013 18:14:14 +0000 >> > Subject: Re: [c-nsp] separate two directly connected networks on a Cisco >> > 1800 series ISR? >> > From: m4rtn...@gmail.com >> > To: darre...@outlook.com >> > CC: c...@marenda.net; cisco-nsp@puck.nether.net >> > >> > Darren, >> > >> > I only want to be able to ping from 192.168.1.0/24 to 192.168.2.0/24. >> In >> > more general, all the IP traffic from 192.168.1.0/24 to 192.168.2.0/24has >> > to be allowed, but all the IP traffic(except return traffic) from >> > 192.168.2.0/24 to 192.168.1.0/24 has to be denied. As I said, ZBFW >> works >> > fine, but as described above, it seems to have some limitations as for >> > example ICMP "session" statefull inspection does not work very well: >> > >> > For example at the time I send ICMP "echo request" messages with 1s >> interval >> > from 192.168.1.2 to 192.168.2.2, I'm also able to send ICMP "echo >> request" >> > messages(and receive replies) from 192.168.2.2 to 192.168.1.2. Once I >> stop >> > the ping in 192.168.1.2 machine, after few seconds(probably the session >> > between zones times out), I can not ping from 192.168.2.2 to >> 192.168.1.2. >> > >> > >> > As much as I tested, I didn't encounter such problems with UDP. TCP >> worked >> > fine as well. >> > >> > >> > regards, >> > Martin >> > >> > >> > On Fri, Aug 30, 2013 at 4:43 PM, Darren O'Connor <darre...@outlook.com> >> > wrote: >> > >> > >> > >> > >> > Do you want to be able to ping from both networks to both all the time >> or do >> > you only want to ever be able to ping from 192.168.1.0/24 to >> 192.168.2.0/24 >> > ? >> > >> > >> > If you simply want to allow ping you can set icmp traffic to 'pass' but >> you >> > will need to allow both ways as no session data is created. >> > >> > If you only want it one way, you could add an ACL that allows echo from >> one >> > side and echo-reply from the other. >> > >> > >> > Thanks >> > Darren >> > http://www.mellowd.co.uk/ccie >> > >> > >> > >> >> Date: Fri, 30 Aug 2013 19:09:53 +0300 >> >> Subject: Re: [c-nsp] separate two directly connected networks on a >> Cisco >> >> 1800 series ISR? >> > >> >> From: m4rtn...@gmail.com >> >> To: darre...@outlook.com; c...@marenda.net >> > >> >> CC: cisco-nsp@puck.nether.net >> >> >> >> Darren, >> >> >> >> thanks for this suggestion! I can't use this solution on live >> > >> >> equipment as this particular Cisco 1841 in remote location has only >> >> 128 MiB of RAM while according to "Zone-Based Policy Firewall Design >> >> and Application Guide" document and Cisco feature navigator, the ZBFW >> > >> >> feature was introduced in 12.4(6)T which requires at least 192MiB of >> >> RAM on Cisco 1841. However, I was able to add additional 128MiB memory >> >> module to test router which is also Cisco 1841 and installed >> > >> >> c1841-advipservicesk9-mz.151-4.M1.bin SW image. >> >> >> >> >> >> This zone-based setup works, with some exceptions. For example at the >> >> time I send ICMP "echo request" messages with 1s interval from >> > >> >> 192.168.1.2 to 192.168.2.2, I'm also able to send ICMP "echo request" >> >> messages(and receive replies) from 192.168.2.2 to 192.168.1.2. Once I >> >> stop the ping in 192.168.1.2 machine, after few seconds(probably the >> > >> >> session between zones times out), I can not ping from 192.168.2.2 to >> >> 192.168.1.2. When I open a TCP session from 192.168.1.2 to 192.168.2.2 >> >> port 22, then at the same time, I'm not able to open a TCP session >> > >> >> from 192.168.2.2 to 192.168.1.2 port 22. In a nutshell, it looks that >> >> ICMP session statefull inspection does not work very well? Or is my >> >> configuration faulty? >> >> >> >> Configuration is following: >> > >> >> >> >> ! >> >> class-map type inspect match-all 192.168.1.0/24->192.168.2.0/24 >> >> match access-group 102 >> > >> >> ! >> >> policy-map type inspect 192.168.1.0/24->192.168.2.0/24 >> >> class type inspect 192.168.1.0/24->192.168.2.0/24 >> > >> >> inspect >> >> class class-default >> >> drop >> >> ! >> >> zone security LAN >> >> description hosts in LAN network >> >> zone security Wi-Fi >> >> description hosts in Wi-Fi network >> >> ! >> > >> >> zone-pair security LAN->Wi-Fi source LAN destination Wi-Fi >> >> description all traffic from LAN zone to Wi-Fi zone is allowed >> >> service-policy type inspect 192.168.1.0/24->192.168.2.0/24 >> > >> >> ! >> >> interface Vlan5 >> >> description -> T42 eth0 >> >> ip address 192.168.1.1 255.255.255.0 >> >> ip nat inside >> >> ip virtual-reassembly in >> >> zone-member security LAN >> >> ! >> >> interface Vlan10 >> > >> >> description -> T60 >> >> ip address 192.168.2.1 255.255.255.0 >> >> zone-member security Wi-Fi >> >> ! >> >> access-list 102 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 >> >> ! >> >> >> >> Other odd behavior I encountered is that if I executed "dig >> > >> >> @192.168.2.2 www.google.com" in 192.168.1.2 machine, the ICMP "port >> >> unreachable" messages sent by 192.168.2.2 to 192.168.1.2 did not reach >> > >> >> 192.168.1.2. In other words, looks like router is not able to >> >> associate those ICMP error messages with DNS queries using UDP.. >> >> >> >> >> >> >> >> Juergen, >> >> >> >> reflective ACL seems to work great. I configured R3 in a way that >> > >> >> ingress packets to interface Vlan5(facing 192.168.1.0/24 LAN), which >> >> have src IP 192.168.1.* AND dst IP 192.168.2.*, will have reflection >> >> enabled. Now if host from 192.168.2.0/24 network replies, the >> > >> >> Wi-Fi->LAN ACL will check if the packet was reflected. If it was, then >> >> it's allowed, and if not, then ACL proceeds as usual: >> >> >> >> >> >> ! >> >> interface Vlan5 >> >> description -> T42 eth0 >> > >> >> ip address 192.168.1.1 255.255.255.0 >> >> ip access-group LAN->Wi-Fi in >> >> ip access-group Wi-Fi->LAN out >> >> ip nat inside >> >> ip virtual-reassembly in >> >> ! >> >> ! >> >> ip access-list extended LAN->Wi-Fi >> > >> >> permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 reflect >> >> ALL-IP-TRAFFIC timeout 300 >> >> permit ip any any >> >> ip access-list extended Wi-Fi->LAN >> >> evaluate ALL-IP-TRAFFIC >> >> deny ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255 >> > >> >> permit ip any any >> >> ! >> >> >> >> >> >> While I have not jet done extensive testing, based on those >> >> configurations, the reflective ACL seems to understand the >> >> statefulness better than ZBFW.. >> > >> >> >> >> >> >> regards, >> >> Martin >> >> >> >> >> >> On 8/28/13, Darren O'Connor <darre...@outlook.com> wrote: >> >> > You could use ZBF on the firewall. Create two zones. One zone is >> >> > allowed >> > >> >> > access to another, including return traffic. Traffic originated from >> >> > the >> >> > other side is denied. >> >> > >> >> > Thanks >> >> > >> >> > Darren >> >> > http://www.mellowd.co.uk/ccie >> > >> >> > >> >> > >> >> >> Date: Wed, 28 Aug 2013 14:20:33 +0300 >> >> >> From: m4rtn...@gmail.com >> >> >> To: cisco-nsp@puck.nether.net >> > >> >> >> Subject: [c-nsp] separate two directly connected networks on a Cisco >> >> >> 1800 series ISR? >> >> >> >> >> >> Hi, >> >> >> >> >> >> I have a network setup where networks 192.168.1.0/24 and >> > >> >> >> 192.168.2.0/24 are served by same router(Cisco 1841, >> >> >> c1841-spservicesk9-mz.124-7a.bin) and while addresses in >> >> >> 192.168.1.0/24 are NAT -ed to inside global address 10.10.10.1, the >> > >> >> >> 192.168.2.0/24 network is not NAT-ed: >> >> >> http://s10.postimg.org/dsn73dzm1/test.png >> > >> >> >> >> >> >> I would like to deny access from 192.168.2.0/24 network to >> >> >> 192.168.1.0/24. For this reason I have "deny ip 192.168.2.0 >> 0.0.0.255 >> > >> >> >> 192.168.1.0 0.0.0.255" ACL in inbound direction on interface facing >> >> >> the 192.168.2.0/24 network: >> >> >> >> >> >> R3#sh ip access-lists 100 >> > >> >> >> Extended IP access list 100 >> >> >> 10 deny ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255 (456 >> >> >> matches) >> >> >> 20 permit ip any any (90 matches) >> >> >> R3# >> >> >> >> > >> >> >> >> >> >> However, at the same time, one should have access from >> 192.168.1.0/24 >> >> >> network to 192.168.2.0/24 network. Because of the ACL described >> above, >> > >> >> >> this obviously does not work as returning packages from >> 192.168.2.0/24 >> >> >> network will have src IP from 192.168.2.0/24 network and dst IP >> from >> > >> >> >> 192.168.1.0/24 network and will be dropped by ACL. What are the >> >> >> options here? I tried to add second NAT setup which should change >> the >> >> >> src address of those packets which are from 192.168.1.0/24 AND >> > >> >> >> destined to 192.168.2.0/24. Configuration for this was following: >> >> >> >> >> >> interface Vlan5 >> >> >> description -> T42 eth0 >> > >> >> >> ip address 192.168.1.1 255.255.255.0 >> >> >> ip nat inside >> >> >> end >> >> >> ! >> >> >> interface Vlan10 >> >> >> description -> T60 >> >> >> ip address 192.168.2.1 255.255.255.0 >> > >> >> >> ip access-group 100 in >> >> >> ip nat outside >> >> >> end >> >> >> ! >> >> >> ip nat inside source list 102 interface Vlan10 overload >> >> >> ! >> >> >> access-list 102 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 >> 0.0.0.255 >> > >> >> >> ! >> >> >> >> >> >> Such approach seems to work. If I send an ICMP "echo request" >> package >> >> >> from 192.168.1.2 to 192.168.2.2, then it's NAT -ed and for >> 192.168.2.2 >> > >> >> >> host this ICMP "echo request" appears to be from 192.168.2.1. >> >> >> >> >> >> >> >> >> In addition, I tried few setups with policy based routing, but >> >> >> eventually none of those worked. >> > >> >> >> >> >> >> >> >> >> What is the best approach here? Stick with this NAT solution >> described >> >> >> above? Something completely different to separate two networks >> behind >> >> >> the same router? >> > >> >> >> >> >> >> >> >> >> >> >> >> regards, >> >> >> Martin >> >> >> _______________________________________________ >> >> >> cisco-nsp mailing list cisco-nsp@puck.nether.net >> > >> >> >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> >> >> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> > >> >> > >> > >> > >> > >> _______________________________________________ >> cisco-nsp mailing list cisco-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> > > _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/