• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 250
  • Last Modified:

Preventing some subnets from seeing others

I am sure this is a simple one, and I am missing something obvious.

This router sits between our main facility and our new DR site.  We have some traffic that must pass between our production LANs at each location (10.10.1.0/24 and 10.10.3.0/24) and also traffic that must pass between our iSCSI vlans at each site (10.10.100.0/24 and 10.10.103.0/24).

My goal is simple.  I want to prevent the production subnets from seeing the iSCSI subnets and vice versa.  As the config stands now, everybody can see everybody else.  I've tried to implement access lists and apply them to the subinterfaces for the iSCSI subnets, but to no avail.

Can someone assist?

Many thanks in advance.

version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname (removed)
!
boot-start-marker
boot system flash:c1841-advsecurityk9-mz.124-21.bin
boot-end-marker
!
enable secret 5 (removed)
enable password 7 (removed)
!
no aaa new-model
ip cef
!
!
ip auth-proxy max-nodata-conns 3
ip admission max-nodata-conns 3
!
!
!
!
!
!
!
! 
!
!
!
interface FastEthernet0/0
 no ip address
 duplex auto
 speed auto
 no mop enabled
!
interface FastEthernet0/0.1
 encapsulation dot1Q 1 native
 ip address 10.10.1.200 255.255.255.0
!
interface FastEthernet0/0.2
 encapsulation dot1Q 4
 ip address 10.10.100.5 255.255.255.0
!
interface FastEthernet0/1
 no ip address
 duplex auto
 speed auto
!
interface FastEthernet0/1.1
 encapsulation dot1Q 1 native
 ip address 10.10.3.5 255.255.255.0
!
interface FastEthernet0/1.2
 encapsulation dot1Q 4
 ip address 10.10.103.5 255.255.255.0
!
interface Serial0/0/0
 no ip address
 shutdown
!
router rip
 version 2
 network 10.0.0.0
 no auto-summary
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 10.10.1.5
!
ip http server
no ip http secure-server
!
!
!
control-plane
!
!
line con 0
line aux 0
line vty 0 4
 password 7 (removed)
 login
!
scheduler allocate 20000 1000
end

Open in new window

0
grv
Asked:
grv
  • 3
1 Solution
 
H_HarryCommented:
There are a few ways to do what you want - one way would be to set up ACL's to stop the traffic hopping the VLAN:
 
Create the ACL
# ip access-list extended BLOCKED_VLANS
# permit ip any any established
# permit ip IP RANGE NET MASK any
# deny ip any any  
Where IP RANGE is the range of IP's that you DO want to allow to traverse the VLAN.
Then apply the ACL on the interface:
# ip access-group Block-Vlans in  
Where 'in' will inspect the traffic coming into the interface.
Note - anything no explicitly permitted in the ACL will not be allowed to jump the VLAN - usually a fair bit of design work goes into it to ensure there is absolutley no need for traffic to cross the VLAN.
0
 
Don JohnstonInstructorCommented:
This sample config assumes the iSCSI nets should see each other and the production nets should see each other.

access-list 1 permit 10.10.1.0 0.0.0.255
access-list 1 permit 10.10.3.0 0.0.0.255
access-list 2 permit 10.10.100.0 0.0.0.255
access-list 2 permit 10.10.103.0 0.0.0.255
 
interface f0/0.1
 ip access-group 1 out
interface f0/0.2
 ip access-group 2 out
interface f0/1.1
 ip access-group 1 out
interface f0/1.2
 ip access-group 2 out

Open in new window

0
 
grvAuthor Commented:
Thanks for the response.  This is what I've been attempting, but I am clearly not thinking about this correctly.
Do I need an access list for each of the 4 sub ints, or would it be ok just to lock down the storage sub ints (the .2's)?
For example, with the access list for fa0/0.2, would it like this?
# ip access-list extended BLOCKED_VLANS
# permit ip any any established
# permit ip 10.10.103.0 0.0.0.255 any
# deny ip any any
I'm OK with the mechanics of creating and applying access lists, I'm just not locking down the right subnets on the right interfaces, I think.
 
Thanks again.
0
 
grvAuthor Commented:
Hi donjohnston - didn't see your post before I posted the above.  Looking at it now...
0
 
grvAuthor Commented:
donjohnston,
That was what I needed.  I changed it a little so that traffic from the remote production subnet 10.10.3.0/24 could get to the web via 10.10.1.0/24, and now my storage is safe from production.
Thanks!
 
0

Featured Post

Nothing ever in the clear!

This technical paper will help you implement VMware’s VM encryption as well as implement Veeam encryption which together will achieve the nothing ever in the clear goal. If a bad guy steals VMs, backups or traffic they get nothing.

  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now