InterVLAN Isolation/Blocking problem

jason_leong7

Hi Guys,

Im facing a problem in my network design. I have about 30 to 40 Layer 3 VLANs in the Cat 6500 switch. All of these VLANs are broken into different Departments for a large company. Since ip routing is enabled (routing is needed for other networks) all inter VLAN routing for all these departments are allowed.

For obvious reasons, all inter VLAN routing should be blocked except to the server VLAN and other subnets such as the internet and other networks through the company's own IP VPN Cloud.

For explanation purposes, the 3rd octet for any IP address i stated below is the VLAN ID. I.e 10.0.100.X --> VLAN 100, 10.0.123.X --> VLAN 123

I know how to use the ACLs for each interface VLANs, by denying traffic to every destination vlan from a source vlan.. i.e

ip access-list extended Block_VLAN_100_to_all
deny 10.0.100.0 0.0.0.255 10.0.101.0 0.0.0.255
deny 10.0.100.0 0.0.0.255 10.0.102.0 0.0.0.255
|
|
***repeat 29 times until deny 10.0.100.0 0.0.0.255 10.0.0 10.130 0.0.0.255
permit ip any any

and then

interface vlan 100
ip access-group Block_VLAN_100_to_all in



well, I would have to repeat those ACLs thirty times for every VLAN. That would cause the Core Switch to have a very very long line of ACL entries.

Just imagine if I were to add in another VLAN, then I have to repeat all 30 VLANs with the ACLs for the 31st time.

Does anyone have a simpler way of accomplishing this problem?

networker050184

Check out Securing Networks with Private VLANs and VLAN Access Control Lists.

You can have the server VLAN communicate with the all other VLANs but not have them communicate with each other. Make sure you read the known limitations section though because there are some limitations.

Also, I'm not sure about the scalability of this solution so you will probably want to do some testing first before deploying. Maybe someone with more experience with PVLANs and VACLs will chime in.

jason_leong7

networker050184 wrote:

You can have the server VLAN communicate with the all other VLANs but not have them communicate with each other. Make sure you read the known limitations section though because there are some limitations.

Also, I'm not sure about the scalability of this solution so you will probably want to do some testing first before deploying. Maybe someone with more experience with PVLANs and VACLs will chime in.

Thanks for your reply, but I have read about that possibility,however, PVLANs and VACLs are used for DMZ or networks behind the firewall to isolate segments in the Server Segment.Essentially, using PVLANs would mean isolating a one VLAN in separate segments which is not my objective. VACLs are used for filtering within a VLAN (using Layer 2 ACLs).

However, my problem is about Inter VLAN in the Inside/Trusted Network portion. My objective is separate/isolate/block Inter VLAN communications between Layer 3 VLANs which normally uses Layer 3 ACLs....i know how to use them, but my method mention in the earlier post is too long.

Anyone have another method to reduced the amount of Layer 3 ACLs used?

Thanks!!!

xwesleyxwillisx

Just going to second what networker suggested with VACLs. Check this link:

http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/122sx/swcg/vacl.pdf

You could create 1 ACL to deny traffic to all the VLANs which should not be able to communicate with one another and apply it to each VLAN. This way any traffic leaving the VLAN to be routed would be blocked but whatever you don't deny (ie internet/server vlan) would pass through.

Again, someone with more experience with VACLs/PVLANs please chime in.

networker050184

The only application is not for a DMZ that is just an example.

You should really read the whole document as it covers the limitation you stated about layer 3 and how to work around it.

jason_leong7

You could create 1 ACL to deny traffic to all the VLANs which should not be able to communicate with one another and apply it to each VLAN. This way any traffic leaving the VLAN to be routed would be blocked but whatever you don't deny (ie internet/server vlan) would pass through.

Creating the *1* ACL seems to be a problem for me. Like in my earlier example, just say VLAN 100 till VLAN 130.

VLAN 100 must block traffic to/from VLAN 101 to VLAN 130,
VLAN 120 have to block traffic to/from VLAN 100 to VLAN 130 except VLAN 120 itself and so on so forth.

Identifying the least amount of ACL used in a traffic flow seems to be a problem for me.

Sorry networker, I could use VACL for this purpose, by blocking the traffic going out from the VLAN..its true. But identifying the range of VLANs that it shouldn't go through is still too long. What i mean is to match an ACL to the access-map. The ACL that it have to match still needs to define every single VLAN that would take approx 29 ACL lines multiply 30 VLANs (870 ACL lines !!).


If im getting the wrong idea you're trying to convey, please lend me an example of your concept. I really appreciate your ideas.

xwesleyxwillisx

It seems to me you could create 1 ACL to block all VLANs you do not want to be able to communicate with one another. You would then apply this ACL to EACH VLAN you want to limit. My thought is that the 1 ACL would allow traffic to the server vlans/the internet and allow traffic inside the vlan (traffic remaining on the vlan would never touch the acl).

Here's an example:

You do not want hosts in VLANs 100, 200, or 300 to be able to talk to hosts in another VLAN. The exception is VLAN 400 which is the server VLAN. Also, you want all other traffic to be able to go through (ie Internet traffic).

VLAN 100 = 192.168.100.0 /24
VLAN 200 = 192.168.200.0 /24
VLAN 300 = 192.168.300.0 /24
VLAN 400 = 192.168.400.0 /24

access-list 100 deny ip any 192.168.100.0 0.0.0.255
access-list 100 deny ip any 192.168.200.0 0.0.0.255
access-list 100 deny ip any 192.168.300.0 0.0.0.255
access-list 100 permit ip any any

int vlan 100
ip access-group 100 in

int vlan 200
ip access-group 100 in

int vlan 300
ip access-group 100 in

Is my thought correct that traffic destined to hosts inside the same subnet would not hit this ACL and thus be permitted?

svo4dot6

I believe Jason really means intra-vlan and not inter-vlan. For example, traffic from VLAN 100 or 10.0.100.x destined to any of the other vlans should be filtered unless it is to specific hosts.

What I have done in a similiar case is to add a permit for necessary intra-vlan communication and deny all else on the block. IE say you have servers on VLAN 20:


ip access-list extended block_vlan_100_to_all
permit 10.0.100.0 0.0.0.255 10.0.20.0 0.0.0.255
deny 10.0.100.0 0.0.0.0.255 10.0.0.0 0.0.255.255
permit ip any any


Of course for my setup I only have 10 VLANs and its on a pix

mikearama

I have a similar type of network, though with only a dozen divisions... 30? That's nuts.

I do not understand the business case for having to block traffic from one vlan to all others. The first thing you need to do is get that list shortened. In our company, we've taken steps to protect accounting and hr. What possible reason could there be to do what you need to do for other, less important divisions. So what if manufacturing can see the advertising range... they still need to authenticate against shares/files.

If you can get it down to a couple vital vlans, then writing your acl's isn't such a big deal... it's exactly what we had to do as well.

jason_leong7

xwesleyxwillisx wrote:

VLAN 100 = 192.168.100.0 /24
VLAN 200 = 192.168.200.0 /24
VLAN 300 = 192.168.300.0 /24
VLAN 400 = 192.168.400.0 /24

access-list 100 deny ip any 192.168.100.0 0.0.0.255
access-list 100 deny ip any 192.168.200.0 0.0.0.255
access-list 100 deny ip any 192.168.300.0 0.0.0.255
access-list 100 permit ip any any

int vlan 100
ip access-group 100 in

int vlan 200
ip access-group 100 in

int vlan 300
ip access-group 100 in

Is my thought correct that traffic destined to hosts inside the same subnet would not hit this ACL and thus be permitted?

Looks possible ...but i im afraid if there are traffic flows that hits that ACL belonging within the VLAN. Ill let u know when i try it. Thanks for the idea.

Any other ideas anyone?

jason_leong7

svo4dot6 wrote:

I believe Jason really means intra-vlan and not inter-vlan. For example, traffic from VLAN 100 or 10.0.100.x destined to any of the other vlans should be filtered unless it is to specific hosts.

What I have done in a similiar case is to add a permit for necessary intra-vlan communication and deny all else on the block. IE say you have servers on VLAN 20:


ip access-list extended block_vlan_100_to_all
permit 10.0.100.0 0.0.0.255 10.0.20.0 0.0.0.255
deny 10.0.100.0 0.0.0.0.255 10.0.0.0 0.0.255.255
permit ip any any


Of course for my setup I only have 10 VLANs and its on a pix

I think Inter VLANs means "between VLANs" and Intra VLAN means "within a VLAN".

What i mean is between Layer 3 VLANs / SVI interfaces. Similiar to routed ports but using VLANs in a Multilayer Switch.

Actually I did not mention the entire IP Addressing scheme and VLAN assignment because i didnt want to make my post lengthy, but VLAN 1-100 cannot be used because it is used in their existing network and some of them needs interconnectivity. Thus my ACLs have to avoid 10.0.1.0 till 10.0.99.255. Ur deny statement denied those networks. I have thought of that ACL but in my case, it would fail for my design. Moreover for the "ip access-list extended block_vlan_100_to_all" have to be repeated 30 times till "ip access-list extended block_vlan_130_to_all"...

Thanks for your ideas

jason_leong7

mikearama wrote:

I have a similar type of network, though with only a dozen divisions... 30? That's nuts.

I do not understand the business case for having to block traffic from one vlan to all others. The first thing you need to do is get that list shortened. In our company, we've taken steps to protect accounting and hr. What possible reason could there be to do what you need to do for other, less important divisions. So what if manufacturing can see the advertising range... they still need to authenticate against shares/files.

If you can get it down to a couple vital vlans, then writing your acl's isn't such a big deal... it's exactly what we had to do as well.

I know it is totally nuts....been telling them about the implications during the design workshop. I've tried cutting down their VLANs. The company apparently have networks from their partners (outsourcing partners), subsidiary companies and other departments which requires total isolation from each other.

I wished if they purchased a FWSM for the Cat 6500, then at least i could terminate the VLANs in the firewall and let it do the Inter VLAN filtering there....however, that is not the case.

cisco_trooper

jason_leong7 wrote:

ip access-list extended Block_VLAN_100_to_all
deny 10.0.100.0 0.0.0.255 10.0.101.0 0.0.0.255
deny 10.0.100.0 0.0.0.255 10.0.102.0 0.0.0.255
|
|
***repeat 29 times until deny 10.0.100.0 0.0.0.255 10.0.0 10.130 0.0.0.255
permit ip any any

With your current addressing you can simplify this a LITTLE to something like this:
ip access-list extended Block_VLAN_100_to_all
deny 10.0.100.0 0.0.0.255 10.0.101.0 0.0.0.255
deny 10.0.100.0 0.0.0.255 10.0.102.0 0.0.1.255
deny 10.0.100.0 0.0.0.255 10.0.104.0 0.0.7.255
deny 10.0.100.0 0.0.0.255 10.0.112.0 0.0.15.255
deny 10.0.100.0 0.0.0.255 10.0.128.0 0.0.1.255
deny 10.0.100.0 0.0.0.255 10.0.130.0 0.0.0.255

BUT, I would recommend using a better addressing scheme so you don't have to screw with all your access lists every time you bring in a new VLAN. Perhaps all your LAN segments can be in 10.1.0.0 rather than 10.0.0.0 where your server VLAN resides. Then you can do this AND you don't have to rewrite the ACL if you add a new VLAN to 10.1.0.0:

ip access-list extended Block_VLAN_100_to_all
deny 10.0.100.0 0.0.0.255 10.1.0.0 0.0.255.255

jason_leong7

cisco_trooper wrote:

With your current addressing you can simplify this a LITTLE to something like this:
ip access-list extended Block_VLAN_100_to_all
deny 10.0.100.0 0.0.0.255 10.0.101.0 0.0.0.255
deny 10.0.100.0 0.0.0.255 10.0.102.0 0.0.1.255
deny 10.0.100.0 0.0.0.255 10.0.104.0 0.0.7.255
deny 10.0.100.0 0.0.0.255 10.0.112.0 0.0.15.255
deny 10.0.100.0 0.0.0.255 10.0.128.0 0.0.1.255
deny 10.0.100.0 0.0.0.255 10.0.130.0 0.0.0.255

BUT, I would recommend using a better addressing scheme so you don't have to screw with all your access lists every time you bring in a new VLAN. Perhaps all your LAN segments can be in 10.1.0.0 rather than 10.0.0.0 where your server VLAN resides. Then you can do this AND you don't have to rewrite the ACL if you add a new VLAN to 10.1.0.0:

ip access-list extended Block_VLAN_100_to_all
deny 10.0.100.0 0.0.0.255 10.1.0.0 0.0.255.255

Thanks for the idea, it really greatly reduced it. From 870 lines to (6 multiply 30 = 180 lines).
If im not mistaken that ACL can be shorten by using a prefixlist....Anyone knows how to use it and reduce the number of lines further?

Btw guys....i read this somewhere...think this will work?...im not sure if it could be used or not..comments will be appreciated

---

first create an ACL

ip access-list extended Block-Vlans
?permit ip any any established
?permit ip 172.16.9.0 0.0.0.255 any ---> permiting Server VLAN
?deny ip any any

On each VLAN interface you wish to block inter-vlan traffic add the following line.

ip access-group Block-Vlans in

??? The keyword "in" tells the interface to apply the ACL to incoming traffic to the VLAN

now to explain the ACL.

?permit ip any any established
??? ?? Allows packets that were established from inside the vlan
?permit ip 172.16.9.0 0.0.0.255 any
??? ?? Only traffic from the specified subnet is allow

?deny ip any any
??? ?? Deny everything else.

---

If you understand the above, please help explain to me...i dun understand how his idea works..but it looks short! which is good..... but it looks wrong because the direction should be outbound..right?

cisco_trooper

jason_leong7 wrote:

Thanks for the idea, it really greatly reduced it. From 870 lines to (6 multiply 30 = 180 lines).
If im not mistaken that ACL can be shorten by using a prefixlist....Anyone knows how to use it and reduce the number of lines further?

I'm not an expert with prefix-lists, but my initial thought is that they probably won't help you much more than the access-list I provided because of where your network boundaries lie. Your server VLAN is only one bit away from the rest of your LAN segments.....I'll look into those later since I need to anyway...

jason_leong7

cisco_trooper wrote:

I'm not an expert with prefix-lists, but my initial thought is that they probably won't help you much more than the access-list I provided because of where your network boundaries lie. Your server VLAN is only one bit away from the rest of your LAN segments.....I'll look into those later since I need to anyway...

I think one of the earlier post assume my server VLAN is in VLAN 120. Actually my server VLAN is somewhere between VLAN 1-99 which is not defined yet. Just assume my server VLAN is vlan 51.

VLAN 100 and above is purely for user segments. (100 to 130 is only an example...im not surprise if they hit 140).

APA

VACL's via VLAN access maps?

Filter the traffic within the vlan to permit only what is necessary and then will drop everything else....

Then apply the VLAN access map to the associated VLANs.......

Can't elaborate now will try to when I get home... but even with many VLANs you may come up with the same scenarios in terms of administrative overhead.....

cisco_trooper

jason_leong7 wrote:

cisco_trooper wrote:

I'm not an expert with prefix-lists, but my initial thought is that they probably won't help you much more than the access-list I provided because of where your network boundaries lie. Your server VLAN is only one bit away from the rest of your LAN segments.....I'll look into those later since I need to anyway...

I think one of the earlier post assume my server VLAN is in VLAN 120. Actually my server VLAN is somewhere between VLAN 1-99 which is not defined yet. Just assume my server VLAN is vlan 51.

VLAN 100 and above is purely for user segments. (100 to 130 is only an example...im not surprise if they hit 140).

It isn't the VLAN Number that matters, so much as the address space given to that VLAN.

tech-airman

jason_leong7 wrote:

Hi Guys,

Im facing a problem in my network design. I have about 30 to 40 Layer 3 VLANs in the Cat 6500 switch. All of these VLANs are broken into different Departments for a large company. Since ip routing is enabled (routing is needed for other networks) all inter VLAN routing for all these departments are allowed.

For obvious reasons, all inter VLAN routing should be blocked except to the server VLAN and other subnets such as the internet and other networks through the company's own IP VPN Cloud.

For explanation purposes, the 3rd octet for any IP address i stated below is the VLAN ID. I.e 10.0.100.X --> VLAN 100, 10.0.123.X --> VLAN 123

I know how to use the ACLs for each interface VLANs, by denying traffic to every destination vlan from a source vlan.. i.e

ip access-list extended Block_VLAN_100_to_all
deny 10.0.100.0 0.0.0.255 10.0.101.0 0.0.0.255
deny 10.0.100.0 0.0.0.255 10.0.102.0 0.0.0.255
|
|
***repeat 29 times until deny 10.0.100.0 0.0.0.255 10.0.0 10.130 0.0.0.255
permit ip any any

and then

interface vlan 100
ip access-group Block_VLAN_100_to_all in



well, I would have to repeat those ACLs thirty times for every VLAN. That would cause the Core Switch to have a very very long line of ACL entries.

Just imagine if I were to add in another VLAN, then I have to repeat all 30 VLANs with the ACLs for the 31st time.

Does anyone have a simpler way of accomplishing this problem?

jason_leong7,

It seems like you're getting confused because you're trying to do everything at once. For access lists, you have to separate the traffic into two types: 1) Inbound to the router 2) Outbound from the router. Let's work on the "Inbound to the router" part first.

Inbound to the router would be the traffic from your VLANs. You want the traffic from say VLAN 100 to be allowed to VLAN 51. Since the destination is specific, in this case VLAN 51, you'll need to use an extended access list instead of a standard access list. So let's say that VLAN 100 is 10.0.100.0 255.0.0.0 and VLAN 51 is 10.0.51.0 255.0.0.0. So the single line ACL would be...

Router(config)#access-list 100 permit ip 10.0.100.0 0.0.0.255 10.0.51.0 0.0.0.255

Then you apply that access-list to VLAN 100 with a direction of "in." By default, there's a "deny any any" after that permit statement which would save you typing "deny 10.0.101.0, deny 10.0.102.0, deny 10.0.103.0, etc."

Does this proposed solution help?

jason_leong7

By doin that...how do you allow the traffic to the internet? normally, i need to permit ip 10.0.100.0 0.0.0.255 any. and then denying wat is not needed.... there is no specific permit statement to allow traffic to the internet right?

tech-airman

jason_leong7 wrote:

By doin that...how do you allow the traffic to the internet? normally, i need to permit ip 10.0.100.0 0.0.0.255 any. and then denying wat is not needed.... there is no specific permit statement to allow traffic to the internet right?

jason_leong7,

Is the Internet access through a port on the 6500 Layer 3 switch in question or another networking device?

jason_leong7

Two ASA 5550 running Active - Standby, one ASA is connected to an edge router (internet) and another connects to an edge router (IP VPN router to their company network). Between the FW and Core Switch, I used Layer 3 interface (VLAN 5) running HSRP. A default route pointing towards the Firewall interface in the same subnet.

ip route 0.0.0.0 0.0.0.0 10.0.5.4.

Network between the Core switch and Firewall is a 10.0.5.0/ 28 network

10.0.5.1 - Core 1
10.0.5.2 - Core 2
10.0.5.3 - Virtual IP
10.0.5.4 - ASA 1 (Active)
10.0.5.5 - ASA 2 (Passive) --> not in used because 5.4 is always active even if passive fails.

I tried following the access list that was sugested by permit traffic 10.0.5.0 /28 but traffic from internet is dropped.

access-list 100 permit ip 10.0.100.0 0.0.0.255 10.0.51.0 0.0.0.255
access-list 100 permit ip 10.0.100.0 0.0.0.255 10.0.5.0 0.0.0.15

** Internet traffic is dropped... Hope you could help

rossonieri#1

hi jason,

ip access-list extended Block_VLAN_100_to_all
deny 10.0.100.0 0.0.0.255 10.0.101.0 0.0.0.255
deny 10.0.100.0 0.0.0.255 10.0.102.0 0.0.0.255
|
|
***repeat 29 times until deny 10.0.100.0 0.0.0.255 10.0.0 10.130 0.0.0.255
permit ip any any

and then

interface vlan 100
ip access-group Block_VLAN_100_to_all in

your method actually is the safest one - even though you have to type it 29 times

in case you are wondering - how about this :

deny 10.0.100.0 0.0.0.255 10.0.101.0 0.0.29.255 ?

i have not tested though

jason_leong7

rossonieri#1 wrote:

your method actually is the safest one - even though you have to type it 29 times

in case you are wondering - how about this :

deny 10.0.100.0 0.0.0.255 10.0.101.0 0.0.29.255 ?

i have not tested though

0.0.29.255 does not mean 29 times.... ><

rossonieri#1

0.0.29.255 does not mean 29 times.... ><

come on ... what is this???
i know it did not mean 29 times!!!

its the inverse mask range from subnet 10.0.101.0/24 subnet to 10.0.130.0/24

but its not safe!!! - try do the binary and check the result yourself.

cisco_trooper

rossonieri#1 wrote:

0.0.29.255 does not mean 29 times.... ><

come on ... what is this???
i know it did not mean 29 times!!!

its the inverse mask range from subnet 10.0.101.0/24 subnet to 10.0.130.0/24

but its not safe!!! - try do the binary and check the result yourself.

Don't care what the subnet range is, 0.0.29.255 is NEVER a valid wildcard mask...

jason_leong7

rossonieri#1 wrote:

0.0.29.255 does not mean 29 times.... ><

come on ... what is this???
i know it did not mean 29 times!!!

its the inverse mask range from subnet 10.0.101.0/24 subnet to 10.0.130.0/24

but its not safe!!! - try do the binary and check the result yourself.

I tried it out...it didnt work...some vlans are blocked...ur second bit is 0 which fixes it...so for certain vlans, it doesnt take effect.

rossonieri#1

@ jason,

I tried it out...it didnt work...some vlans are blocked...ur second bit is 0 which fixes it...so for certain vlans, it doesnt take effect.

i have told you so - sometimes doing the manual thing is the safest way.

the 0.0.29.255 came from 130 - 101 subtraction - as used by many other networkers, but they do admit that sometimes it just doesnt work - the bits dont match

besides - we use notepad/gedit to create the list - so just edit, copy and paste

edit :

are you sure it did not work? those are contiguous subnets - i think it should worked.
which VLAN are being blocked?

tech-airman

jason_leong7 wrote:

Two ASA 5550 running Active - Standby, one ASA is connected to an edge router (internet) and another connects to an edge router (IP VPN router to their company network). Between the FW and Core Switch, I used Layer 3 interface (VLAN 5) running HSRP. A default route pointing towards the Firewall interface in the same subnet.

ip route 0.0.0.0 0.0.0.0 10.0.5.4.

Network between the Core switch and Firewall is a 10.0.5.0/ 28 network

10.0.5.1 - Core 1
10.0.5.2 - Core 2
10.0.5.3 - Virtual IP
10.0.5.4 - ASA 1 (Active)
10.0.5.5 - ASA 2 (Passive) --> not in used because 5.4 is always active even if passive fails.

I tried following the access list that was sugested by permit traffic 10.0.5.0 /28 but traffic from internet is dropped.

access-list 100 permit ip 10.0.100.0 0.0.0.255 10.0.51.0 0.0.0.255
access-list 100 permit ip 10.0.100.0 0.0.0.255 10.0.5.0 0.0.0.15

** Internet traffic is dropped... Hope you could help

jason_leong7,

I've been pondering this issue ever since my last post. I had an idea of reassigning the IP addresses for VLANs 1 ~ 99 as part of the 172.16.x.x range and keep the user end at 10.x.x.x. That way, you can simplify the access lists on each user VLAN to the following...

access-list 100 deny ip 10.0.x.0 0.0.0.255 10.0.0.0 0.255.255.255
access-list 100 permit ip any any

Where x is the VLAN number system that you wanted. That way, you can block traffic trying to go TO any other user VLAN but the permit ip any any would let them have access to the server vlan as well as the Internet. What do you think of this solution?

jason_leong7

tech-airman wrote:

jason_leong7,

I've been pondering this issue ever since my last post. I had an idea of reassigning the IP addresses for VLANs 1 ~ 99 as part of the 172.16.x.x range and keep the user end at 10.x.x.x. That way, you can simplify the access lists on each user VLAN to the following...

access-list 100 deny ip 10.0.x.0 0.0.0.255 10.0.0.0 0.255.255.255
access-list 100 permit ip any any

Where x is the VLAN number system that you wanted. That way, you can block traffic trying to go TO any other user VLAN but the permit ip any any would let them have access to the server vlan as well as the Internet. What do you think of this solution?

I wish it was that easy....i've thought of that before, the 10.0.100.0 till 10.0.254.0 are the new subnets. They are assigned to me to use for the users. Btw, most of thier servers are already configured in that range.

i also though of using the 172 and 192 subnets, but it seems it is already used in their IP VPN network. Meaning that if those users want to use the IP VPN, the ip address might clash...

tech-airman

jason_leong7 wrote:

tech-airman wrote:

jason_leong7,

I've been pondering this issue ever since my last post. I had an idea of reassigning the IP addresses for VLANs 1 ~ 99 as part of the 172.16.x.x range and keep the user end at 10.x.x.x. That way, you can simplify the access lists on each user VLAN to the following...

access-list 100 deny ip 10.0.x.0 0.0.0.255 10.0.0.0 0.255.255.255
access-list 100 permit ip any any

Where x is the VLAN number system that you wanted. That way, you can block traffic trying to go TO any other user VLAN but the permit ip any any would let them have access to the server vlan as well as the Internet. What do you think of this solution?

I wish it was that easy....i've thought of that before, the 10.0.100.0 till 10.0.254.0 are the new subnets. They are assigned to me to use for the users. Btw, most of thier servers are already configured in that range.

i also though of using the 172 and 192 subnets, but it seems it is already used in their IP VPN network. Meaning that if those users want to use the IP VPN, the ip address might clash...

jason_leong7,

For the 10.x.x.x range of IP addresses, are you using fixed length subnet masking?