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

Fri Aug 30 12:09:53 EDT 2013

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