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

Sat Aug 31 18:40:13 EDT 2013

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/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/
>
>> >
>  		 	   		
>
>