Microsoft Clustering and Firewalls

When we installed our first Exchange 2003 Cluster at work our firewall group was very mad, they called screaming about how we had set it up. They did not like the fact that ingress (inbound) traffic was to the Virtual IP (VIP) and egress (outbound) traffic was via which ever node was controlling the Exchange Virtual Server (EVS) at the time. “This will simply not do”, they said. “We want you to use the same IP for inbound and outbound traffic”. “You are making our firewall rules very difficult to maintain and manage!


Hmm, I see the point our firewall group was trying to make. Why was the traffic pattern this way?


Simple answer – that is how Microsoft wrote the clustering code. No, that would not do, they are pretty smart and would want a better answer.


Longer answer – You can’t send traffic on a network that does not really exist. Think about what the VIP is, it’s not real. A VIP by definition is not real. Because of this fact, nothing can leave it. The only direction traffic moves via the VIP is inbound. The VIP is bound to a physical network interface (on the controlling node), thus allowing it to interact with the real world. All outbound or return traffic has to come from a real network interface. So, traffic is allowed to come into the VIP, which is bound to a real network interface. That real network interface is then the one that replies or send out information. This makes rules in the firewall very interesting (because the inbound is static – always the VIP, but outbound is from which ever node is controlling at that moment and can change over time), hence why they were so mad!


The Virtual is for inbound traffic only. Outbound traffic is via the controlling node at that time. After I explained this, my firewall team was still not happy, but at least they fully understood J Did I mention that this is how other clustered services like SQL Server 2000 handle traffic too?

2 thoughts on “Microsoft Clustering and Firewalls

Leave a Reply

Your email address will not be published. Required fields are marked *