HSRP on multilayer switches

fred.damstra@gmail.com · Guest

I have a gigabit MAN connection between two buildings that acts like an
ethernet bridge. Connected to each end of this gigaman are Catalyst
3750's. Hanging off the catalysts are a primary Host (AS/400) and a
"High Availability" host which journals off the primary (one host at
each physical location). With the MAN connection, these hosts appear
on the same ethernet segment, so we can swap a virtual IP between the
two hosts, making rollovers very easy.

Also connected to each catalyst is a checkpoint firewall which serves
as the gateway device to the rest of our networks and the Internet.

So, simplified ascii connection diagram (not sure if this helps):

[LAN1]<->[Firewall1]<->[3750 #1]<-MAN->[3750 #2]<->[Firewall
2]<->[LAN2]

Host1 is connected to 3750 #1, and host2 is connected to 3750#2.

The default gateway of the each host is currently the interface on FW1.
Which works great for LAN1, but breaks for LAN2. Explanation:

Syn packet comes from LAN2 destined for host1, is evaluated by FW2
which allows the connection to host1. The Syn-Ack for lan2 is sent out
the default gateway, which is FW1. FW1 never saw the initial syn, so
drops the connection as "out of state".

In the current situation, the problem is easily solved by putting
static routes to LAN2 on each of the hosts.

However, now, we want to add some redundant WAN links to both
facilities. Preferably with automatic failover using a routing
protocol (probably OSPF). This means the static routes on the hosts
are no longer sufficient.

The hosts don't run OSPF, though they can run RIPv2 and we could
redistribute the routes.

Alternatively, we believe we could put two routers next to the hosts
that participate in the OSPF area and run HSRP to share an IP. That
VIP could be the default gateway for the hosts. Then, the syn-ack will
go to one of those routers which will forward it along to the
appropriate firewall.

So then we go one step further, and realize those are multilayer
switches. Can we have both switches run OSPF and still use HSRP?

Is this possible?
Can you think of a better solution?

Thanks,
Fred

Merv · Guest

Guest · Posted: Fri Apr 21, 2006 3:12 pm Post subject: Re: HSRP on multilayer switches

Your connection diagram seems to indicate a flat layer 2 network - in
this situation you should be using vlan segmentation.
Go one better and sync the firewalls, making one firewall primary, one
standby and using a virtual ip for the default route on the user vlan.
i.e.
1) Connect all hosts physically into the switches
2) Put all hosts in the 'user' vlan (including 1 interface on each
firewall plus the virtual ip which will be the default route)
3) The firewalls should have a dedicated failover/sync vlan (most
implementations require this anyway)
4) The link between switches should be a trunk carrying the user and
failover vlans.

The reason this works is that all non-local traffic will be routed
through the firewalls. Your current setup breaks this basic design
principle.

Routing is not required, except that provided by the firewalls between
vlans. No ip configuration will be needed on the switches, however if
you have PIX firewalls you can use HSRP.

You then have more of a 'tree' diagram. The firewalls are one device
for all intents and purposes:

Hosts -> Switch1 ->
Firewall -> whatever
Hosts -> Switch2 ->

fred.damstra@gmail.com · Guest

ben.carbery@gmail.com wrote:

fred.damstra@gmail.com · Guest

Subject AKA "Is this stupid from a security standpoint"?

I know the mantra: "Don't use VLAN's for security", but I'm clearly
having trouble understanding when it applies. In the original thread
(HSRP on multilayer switches), I was proposing a solution to my problem
that didn't involve VLAN's, to which somebody responded, "You should be
using VLAN's".

The basics: We just added a second facility and want to increase our
redundancy. We have two hosts that are considered the end-all-be-all
of our business, without these, we're down. We have a nice high
availability configuration in place that requires they be on the same
IP subnet. We have a nice high speed ethernet link between the two
facilities that accomplishes this goal, but it's caused a number of
issues as far as adding further redundancy to our network.

So, I have the following solution in mind. The advantages are
plentiful, but we have a major concern about it: It somewhat relies on
VLAN's to separate traffic before it enters the firewall.

A diagram would probably help, and ASCII is insufficient, so I threw
this together:
http://www.monkeybox.org/cisco/Visio-VLAN-Proposal.pdf

Let me point out a couple things:
(1) The top left and top right areas are two distinct physical
locations. The gigabit ethernet line between the two is all we have to
work with.
(2) The colored lines indicate vlan separation. Over the gigabit
connection, this would be a trunk, but the other links would likely be
individual fastethernet connections in a 'switchport mode access' type
of setup either to other links or the firewalls.
(3) This isn't everything on our network, though it shows the important
stuff. We like to control access as much as we can at the firewalls.
(4) The firewalls would share state over a dedicated sync vlan which
isn't pictured. They'd be in a cluster configuration.

The scariest part of this diagram is that the Internet traffic coming
in on one vlan would enter the same switch as the protected traffic.
Additionally, we're of the opinion that you can't really trust your
lan's, and they do the same thing. So if VLAN hopping is a realistic
problem, both Internet and LAN traffic could conceivably bypass the
firewalls.

If it can be mitigated to the point of "no known attacks", then the
advantages are many. There are cost savings, and really easy ways to
add further redundancy. It scales pretty well, and our single points
of failure actually go down compared to most alternate solutions.

Is this a bad idea from a security standpoint? Any obvious problems
I'm overlooking? Is this sound from a security, stability, and
scalability point of view?

Any input would be appreciated.

Fred