Re: PREVENTING INTERVLAN ROUTING IN SWITCH L3

Leo.Herrera007 · ‎08-19-2019

Hello,

I have to migrate from 2 swithces multilayer to 1, each switch has a different configuration and you have the following SVI

SW1
Vlan100 interface
description << VLAN WAN INTERNET >>
ip address 189.206.125.253 255.255.255.248
standby 10 ip 189.206.125.252
standby 10 timers 30 90
standby 10 priority 110
standby 10 preempt
standby 10 track 1 decrement 15
standby 10 track 2 decrement 15
!
Vlan666 interface
description <<VLAN-GESTION-INT-SIGMA>>
ip address 10.150.40.3 255.255.255.0
!
Vlan700 interface
description BB: INTERNET CONNECTION TO CHECKPOINT: 0
ip address 189.206.125.242 255.255.255.248
standby 0 ip 189.206.125.241
standby 0 timers 30 90
standby 0 priority 110
standby 0 preempt
standby 0 track 1 decrement 15
!
Vlan800 interface
ip address 189.206.97.68 255.255.255.240
standby 10 ip 189.206.97.65
standby 10 priority 110
standby 10 preempt

SW2
Vlan69 interface
ip address 192.168.1.1 255.255.255.0
!
Vlan277 interface
description <<<< FW_CHECKPOINT_HA >>>>
ip flow ingress
ip flow egress
ip address 192.168.132.5 255.255.255.240
ip accounting output-packets
ip wccp 63 redirect in
standby 77 ip 192.168.132.1
standby 77 timers 30 90
standby 77 priority 110
standby 77 preempt
!
Vlan288 interface
ip address 192.168.132.18 255.255.255.240
standby 3 ip 192.168.132.17
standby 3 priority 110
standby 3 preempt

So I need the SVI traffic of each switch not to see each other and since they will be on a single switch, I don't want them to see each other.

I have been seeing options like VRF, Private vlans but since WCCP is run in some interfaces it is not compatible with these protocols, so I have the option of ACLs.

In my opinion, since I don't have so much expertise with ACLs, I think something like this could be left.

Access-list extended VLAN69-277-288
deny ip 192.168.1.0 (SVI VLAN69) 0.0.0.255 189.206.125.0 (SVI VLAN100)
deny ip 192.168.1.0 (SVI VLAN69) 0.0.0.255 10.150.40.0 (SVI VLAN666)
deny ip 192.168.1.0 (SVI VLAN69) 0.0.0.255 189.206.97.0 (SVI VLAN800)
deny ip 192.168.132.0 (SVI VLAN277) 0.0.0.15 189.206.125.0 (SVI VLAN100)
deny ip 192.168.132.0 (SVI VLAN277) 0.0.0.15 10.150.40.0 (SVI VLAN666)
deny ip 192.168.132.0 (SVI VLAN277) 0.0.0.15 189.206.97.0 (SVI VLAN800)

And it only applies to each SVI.

Vlan69 interface
ip address 192.168.1.1 255.255.255.0
ip access-group VLAN69-277-288 in
!
Vlan277 interface
description <<<< FW_CHECKPOINT_HA >>>>
ip access-group VLAN69-277-288 in
ip flow ingress
ip flow egress
ip address 192.168.132.5 255.255.255.240
ip accounting output-packets
ip wccp 63 redirect in
standby 77 ip 192.168.132.1
standby 77 timers 30 90
standby 77 priority 110
standby 77 preempt
!
Vlan288 interface
ip address 192.168.132.18 255.255.255.240
ip access-group VLAN69-277-288 in
standby 3 ip 192.168.132.17
standby 3 priority 110
standby 3 preempt

I hope and understand so much information, can you please confirm if I am on the right way.

Thanks.

Giuseppe Larosa · ‎08-23-2019

Hello Leo,

VRF lite would be the best solution but if it is not compatible with WCCP you need to use IP extended ACL.

The following considerations apply:

When applying an ACL in inbound direction the legitimate source IP addresses are those of the IP subnet of the corresponding vlan.

The SVI can be seen as an host connected to the corresponding L2 VLAN broadcast domain that end user devices use as their default gateway.

So actually SVI inbound would mean traffic that should be routed to another Vlan sourced in local IP subnet.

For this reason it would be better to split the ACL in two ACLs each of them dedicated to a single SVI/ IP subnet.

The second important consideration when using ACLs is that an implicit deny ip any any is present so at least one permit statement is needed.

So I would suggest the following:

Access-list extended VLAN69-IN
deny ip 192.168.1.0 0.0.0.255 189.206.125.248 0.0.0.7
deny ip 192.168.1.0 0.0.0.255 10.150.40.0 0.0.0.255
deny ip 192.168.1.0 0.0.0.255 189.206.97.60 0.0.0.15

permit ip 192.168.1.0 0.0.0.255 any

access-list extended VLAN277-IN

deny ip 192.168.132.0 0.0.0.15 189.206.125.248 0.0.0.7
deny ip 192.168.132.0 0.0.0.15 10.150.40.0 0.0.0.255
deny ip 192.168.132.0 0.0.0.15 189.206.97.60 0.0.0.15

permit ip 192.168.132.0 0.0.0.15 any

int vlan 69

ip access-group VLAN69-IN

exit

int vlan277

ip access-group VLAN277-IN

This is a better solution with more granular control that avoids to accept any source (it stops spoofed IP attacks)

Note: The subnets need to use the correct base address, when the prefix length is > 24 the last byte may be zero or not zero.

Hope to help

Giuseppe

Leo.Herrera007 · ‎08-23-2019

Hi Giuseppe

first of all thank you very much for the answer,

I have some questions:

* On the ACL suggestion:
Extended access list VLAN69-IN
deny ip 192.168.1.0 0.0.0.255 189.206.125.248 0.0.0.7
deny ip 192.168.1.0 0.0.0.255 10.150.40.0 0.0.0.255
deny ip 192.168.1.0 0.0.0.255 189.206.97.60 0.0.0.15

In the destination subnet 189.206.125.248 and 189.206.97.60 it was a finger error because there is denying host traffic but it would be from a subnet, it was just a mistake, right?

* Does applying these ACLs not interfere with the HSRP protocol?

I share diagrams of the current topology and how it should be with the new teams.

CURRENT TOPOLOGY

DESIRED TOPOLOGY

* When approving 4 switches in 2, how would the static routing that is configured in each switch work?

Thanks for your time.

Best regards

Leo.

Giuseppe Larosa · ‎08-23-2019

Hello Leo,

these should be the correct subnets as the subnet masks are more specific then 255.255.255.0 so the the last byte should reflect the base address of each subnet.

For example 189.206.125.248 0.0.0.7 allows to cover IP addresses 189.206.128.248 to 189.206.125.255 that should be the correct subnet. 0.0.0.7 is a wildcard mask and it is equivalent to mask 255.255.255.248

to find the wildcard mask you need to do for each byte / octet

255-subnet-mask-byte so you get 255-255.255-255.255-255.255-248 = 0.0.0.7 it is just binary math made with decimal digits.

>>* Does applying these ACLs not interfere with the HSRP protocol?

You need the last permit entry

permit ip 192.168.1.0 0.0.0.255 any

HSRP messages are originated by an IP address in 192.168.1.0/24 with destination 224.0.0.2 all routers on subnet and this is not blocked if the last permit statement is not forgotten !!!!!

>> * When approving 4 switches in 2, how would the static routing that is configured in each switch work?

Nice question. I would suggest you to keep two additional switched of the old ones, otherwise you would need a complex configuration using VRF lite (Virtual Routing Forwarding) multiple VRFs to avoid to have the firewalls bypassed.

I see ASA FWs Palo Alto Firewalls and Blue Coat.

Hope to help

Giuseppe

Leo.Herrera007 · ‎08-24-2019

Hi Guiseppe,

Thanks again for the time.

It is impossible to keep old switches as new switches will be purchased for the performance and throughput.

And then I can't use vrf because of the incompatibility with wccp.

Question:

As I said, I have 4 switches and I have to migrate to 2 switches.

Only in the 2 switches on the side of the firewalls handling wccp, in that case I can use only ACLs to prevent routing intervlan with the other SVIs that are on the side of the WAN and I make a vrf instance to create a virtual routing table to the SVIs ??

So I would have 2 virtual routing tables (where I don't have wccp) and the default one of the switch (where I have wccp configured)

Summing up, I create an instance of VRF on the switches on the WAN side and for the switches on the firewall side I only prevent the routing with ACL (although I could not see the routing of the VRF instance)

Is this idea valid?

I don't know if he explains to me with the idea I have.

Thanks for all.