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 <[email protected]> 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: [email protected] >> To: [email protected] >> 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 [email protected] >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
