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

Tue Sep 3 19:35:21 EDT 2013

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.bilous at 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 <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/
>>
>
>