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

Mon Sep 2 10:57:05 EDT 2013

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 <m4rtntns at 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 <darrenoc at 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: m4rtntns at gmail.com
> > To: darrenoc at outlook.com
> > CC: cnsp at marenda.net; cisco-nsp at 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 <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/
> >
> >> >
> >
> >
> >
> _______________________________________________
> 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/
>