IDS 4215 Inline VLAN Pair

[wasanthak]

I am trying to configure IDS 4215 to do inline vlan pair with a Cisco 3750 Layer 3 switch.

We have 4 vlans in the 3750, vlan 100 for workstations,vlan 200 for servers, vlan 250 for ip phones and vlan 150 for firewalls.

All vlans have corresponding SVI with that ip been the default gateway for each vlan.

interface Vlan1

no ip address

!

interface Vlan100

description Workstation VLAN

ip address 192.0.0.5 255.255.255.0 secondary

ip address 192.0.0.254 255.255.255.0

!

interface Vlan150

description WatchGuard FW VLAN

ip address 192.168.150.254 255.255.255.0

!

interface Vlan200

description Servers

ip address 192.168.200.254 255.255.255.0

!

interface Vlan250

description VOICE

ip address 192.168.250.254 255.255.255.0

ip helper-address 192.168.200.30

!

interface Vlan254

description Management VLAN

ip address 192.168.254.254 255.255.255.0

My question is how do i monitor the traffic going to firewall vlan from server/workstation vlans ?

I read a quite a bit of old topics here in this forum but could not find anything matching though there were few coming close.

So my idea is to configure new vlan say 151 and move the firewalls to the new vlan.Then do inline vlan pair on old firewall vlan 150 and new fw vlan 151.

Any idea its going to work ? or can i simply do 2 vlan inline pairs for fw-server and fw-workstation vlans ? Also i understand that i have to configure trunking on switch ports ?

would appriciate any comments.

[m.sir]

I have just found flash course about Vlan pairs on Cisco Learning Connection

http://www.cisco.com/E-Learning/bulk/public/celc/IPS_5/default.htm#

M.

hope that helps rate if it does

[wasanthak]

Thank You.

I have already went through that flash course and unfortunatly it does not address the specific issues like having SVI for each vlan and L3 switch doing intervlan routing.

My thinking is based on the CCSE IPS study guide scenario.I am going to try this out tonight and guess i have to find out if it works or not.

[marcabal]

I would recommend you proceed with your first suggestion of creating vlan 151, moving the firewall ports to vlan 151, and then placing the sensor inline between vlans 150 and 151.

There are 2 options for placing the sensor between vlans 150 and 151: inline interface pairing, or inline vlan pairing.

With inline interface pairing you would need the 4FE card in the IDS-4215. Create an inline interface pair using Fe2/0 and Fe2/1.

Create an access port on vlan 150 of your switch and connect Fe2/0.

Create an access port on vlan 151 of your switch and connect Fa2/1.

Allow spanning-tree to run (generally between 30 and 40 seconds).

With InLine Vlan Pairing you can do this with an IDS-4215 without needing the 4FE card.

Create an inline vlan pair subinterface on Fe0/1 that will pair vlans 150 and 151.

Creat an 802.1q trunk port on your switch that will trunk just vlans 150 and 151 (leave the native vlan of the trunk as vlan 1, but do not place vlan 1 in the list of allowed vlans on the trunk)

Connect Fe0/1 to your trunk port.

Now this will cause All traffic between your internal networks and the firewall to have to pass through the sensor. This includes your voice traffic that goes through the internet.

The other option you mentioned of creating inline vlan pairs on your workstation vlan and your server vlans, I would not recommend with IPS 5.1.

The inline vlan pairs would have to be created similar to the inline vlan pair I described above using vlans 150 and 151.

You would have to create vlan 101 and pair 100 and 101.

As well as create 201 and pair 200 and 201.

If the workstations ONLY have connections out through the Firewall and NOT to the servers then it would be OK.

BUT if the workstations also have connections to the servers then it will cause problems. The packets will have to pass through both the vlan 100 and 101 pair as well as the vlan 200 and 201 pair.

When the sensor sees the same packet again after having been routed (by the switch in this case) it causes issues. The sensor sees that the packet has changed and believes that a hacker is modifying packets on the network.

This is being addressed in IPS version 6.0 (still under development) so that vlan pair 100 and 101 can be monitored independant of vlan pair 200 and 201.

So until IPS 6.0 is released I would suggest staying with the single vlan pair approach using vlan pair 150 and 151.

[wasanthak]

Thank you marcabal for the reply.

Your detailed explanation makes me confident.Also thanks for the tip on individual vlan pairs.I am going to give it a try with inline vlan pairs.

The only other thing i forgot to mention is the default gw of the L3 switch is in the FW Vlan , hope this is will not make any problems.

Will keep you updated.

[rmt777666]

Concerning this topic of inline interface pairs and inline vlan pairs:

one thing that I can't understand is what is to prevent a L3 switch from simply routing a packet from one vlan/SVI to another and the packet bypassing the path through the sensor?

A

firewall>sensor>switch

wiring scheme I can readily comprehend.

Packets HAVE to go thru the sensor

A

firewall>switch_VLAN_A>sensorPORT1--sensorPORT2>switchVLAN_B

just doesn't seem to register with me,and yet Cisco documentation and forum posts refer to it so it must be possible.

Perhaps it is something obvious,but I don't see it.

As I asked earlier, what's to keep the switch from directly routing the packet across it's backplane?

[marcabal]

A better representation would be:

Internet->FW->VlanA->sensorport1->sensorport2->VlanB->SVIB->SVIC->VlanC->InternalNet

So you will see that switch contains vlans A, B, and C (could also have additional vlans). BUT the switch does NOT have an SVI on vlan A. It has SVI (switch virtual interfaces) only on B and C in this example (and could have it on other vlans as well).

So packets coming in from the Firewall to Vlan A do not get considered by the switch for Routing. This is because the switch does not have an IP Address assigned to Vlan A. The only available path is through the sensor into Vlan B. Now the switch Does have an SVI IP Address on Vlan B, so once it comes in on Vlan B then it can be considered for Routing out through an SVI on Vlan C, or any other Vlan with an SVI.

A properly operating switch can Only route packets in and out of vlans where the switch has an SVI IP Address. If the Vlan does Not have an SVI, then the switch can only switch the packet between ports in that same vlan.

Some things to be aware of:

Some older switches have a bug where the switch tries to route packets even on vlans without an SVI. This is a bug. On the older switches the software is no longer being supported, and so the bug is not being addressed. And so this method won't work with those older switches.

Some of the newer switches also originally had a similar bug, but the bug was discovered a little over a year ago and has since been addressed in newer versions of the switch code. So if you start seeing weird things you might be running into the old bug, and would just need to upgrade to a more recent software version on your switch.

[wasanthak]

I have configured the IDS in inline vlan pair mode as we discussed in this topic.

Unfortunatly it did not work according to the plan.Here is what i did in details.

1)Created a new VLAN 151 in core L3 switch

2)Moved Firewalls from VLAN 150 to new VLAN 151

3)Created a trunk link with allowed VLAN 150 and 151.Encapsulation dot1q and native vlan 1.

4)Connected the switch trunk port to IDS 4215's fe2_1

5)Configured IDS for new VLAN pair with sub interface number 1 and vlan pair 150,151

6)Enabled the FE2_1 port on IDS and assighed the vlan pair to the virtual sensor.

7)Wait untill both link lights solid green and start testing to see if traffic get brdiged by the IDS.Tried to ping firewall IP 192.168.150.1 from the switch but failed.Checked IDS interface stats for packets/bytes, none were seen.

So i had to configure promiscuous mode for now.The cisco 3750 runs IOS 12.2(25)SEA and IDS 5.1-3

Any clue to what i did wrong ?

[garreri]

Thanks for in information. We have had a similar situation with inline vlan pairs. What our packet captures showed were multiple tcp resets that quickly slowed the sensor to a crawl. We have had to go to promiscuous mode until there is a fix.

[wpetherbridge]

Hi,

I have a similar senario to the one you mentioned in this post. I was wondering if you ever got a solution to this problem?

thanks.