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

Fri Aug 30 14:14:14 EDT 2013

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/24 has
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 <darrenoc at 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: 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/
> > >
>