[c-nsp] separate two directly connected networks on a Cisco 1800 series ISR?

Fri Aug 30 12:43:27 EDT 2013

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: m4rtntns at gmail.com
> To: darrenoc at outlook.com; cnsp at marenda.net
> CC: cisco-nsp at 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 <darrenoc at 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: m4rtntns at gmail.com
> >> To: cisco-nsp at 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 at puck.nether.net
> >> https://puck.nether.net/mailman/listinfo/cisco-nsp
> >> archive at http://puck.nether.net/pipermail/cisco-nsp/
> >