IPTables and MSCluster Service

Has anyone experienced this problem?

I have a MS Cluster Server in a DMZ that needs to talk across an
iptables firewall to an internal server. The internal server initiates
the session to the floating cluster name/floating ip, the cluster
server that has the instance then responds back on its non floating
ip, telling the internal server to continue the current session with
the non floating ip. Right sounds stupid, but I've captured the
network traffic where they establish that they should both use this
new ip to continue (thank you ethereal developers).
I've tried to get the MS box to take a static route to force its
traffic out the floating IP, but it won't accept that since it doesn't
really own that ip, the cluster does.

Obviously, if I pass the traffic through the nat table, the ips get
mangled and the server's carefully crafted negotiation gets bugger'd.
However, if I just enable routing between the subnets, they are both
happy.

Is there any way I can match their IPs and pass the traffic directly
to the routing table without altering the packets, yet still pass all
other traffic through iptables? OR (please the easy answer) has anyone
written a module that I could load to handle this?

Thanks for your time.
Angry Guy

On Thursday 04 September 2003 06:50, Angry Guy wrote:

[NAT between MS Cluster in DMZ and internal net]

> Obviously, if I pass the traffic through the nat table, the ips get
> mangled and the server's carefully crafted negotiation gets bugger'd.
> However, if I just enable routing between the subnets, they are both
> happy.

Why do you nat between the DMZ and your internal net in the
first place? This is only necessary in complicated and unusual
network setups. Normally you only do nat on the interface
attached to the Internet.

So, something like

iptables -t nat -A POSTROUTING -o ppp0 --src 192.168.0.0/24 \
-j MASQUERADE

Where ppp0 is the Internet interface and 1921.168.0.0/24 is
your internal net.

If you have in the DMZ also private IP addresses (eg.
10.0.0.0/24), then you must nat the traffic towards
the Internet also.

iptables -t nat -A POSTROUTING -o ppp0 --src 10.0.0.0/24 \
-j MASQUERADE


HTH

Ciao, Horst
--
»When pings go wrong (It hurts me too)« E.Clapton/E.James/P.Tscharn

This is an ASP setup where the inside network holds managment
server/DCs/SQL servers. Unfortunately, some of the forward facing DMZ
servers require access to a clustered file server. So the file server
has to be in the DMZ. The environment with the Linux server is a lab,
production has failover pix fire walls. The traffic between the DMZ
and Inside networks are heavily ACLd to control access to the inside
network from the DMZ.

If I use the MASQUERADE target between the two subnets iptables alters
the source IP on each side to look like the traffic is coming from the
linux box. This is ok for 99.999% of what passes through it. However,
MS Cluster service mid transmision tries to change it's source IP.
When the linux box sees the traffic it passes it back to the
management server as though this is a new connection instead of a
continuation of the conversation initiated on the first IP.
Eg of traffic:
1>Mgmt server 173.1.1.1:5555 -> virtual file server 173.1.2.6:4444
2>real file server 173.1.2.5:4444 -> 173.1.1.1:5555 Helo
3>173.1.1.1:5555 -> 173.1.2.5:4444 who are you
4>173.1.2.5:4444 -> 173.1.1.1:5555 I'm 173.1.2.6:4444 continue from
here
5>173.1.1.1:5555 -> 173.1.2.5:4444 ok

As you can see, the linux box would have no idea that these two are
surposed to be working out how to talk to each other, so when it sees
step 2, it is going to try to establish a connection to the managment
server as though this was a new session, throwing the management/file
servers out of sync thus they never finishing the negotiation and the
transmission times out.

So again, I need to aviod passing this traffic through the tables and
just route it as is between these two computers. I can live with these
2 servers in the lab being wide open to each other. Right now I have
two options, route with no tables between the subnets, which means I
have no acls between the DMZ and Inside, or enable iptables and break
the cluster. Neither is a usable situation.
I haven't been able to force the cluster to talk on just its virual
ip....so I'm running low on options. The last step is toss the linux
box and get a pix, but I'd like to keep Tux around




Horst Knobloch <(E-Mail Removed)> wrote in message news:<bj7751$15a1$(E-Mail Removed)>...
> On Thursday 04 September 2003 06:50, Angry Guy wrote:
>
> [NAT between MS Cluster in DMZ and internal net]
>
> > Obviously, if I pass the traffic through the nat table, the ips get
> > mangled and the server's carefully crafted negotiation gets bugger'd.
> > However, if I just enable routing between the subnets, they are both
> > happy.
>
> Why do you nat between the DMZ and your internal net in the
> first place? This is only necessary in complicated and unusual
> network setups. Normally you only do nat on the interface
> attached to the Internet.
>
> So, something like
>
> iptables -t nat -A POSTROUTING -o ppp0 --src 192.168.0.0/24 \
> -j MASQUERADE
>
> Where ppp0 is the Internet interface and 1921.168.0.0/24 is
> your internal net.
>
> If you have in the DMZ also private IP addresses (eg.
> 10.0.0.0/24), then you must nat the traffic towards
> the Internet also.
>
> iptables -t nat -A POSTROUTING -o ppp0 --src 10.0.0.0/24 \
> -j MASQUERADE
>
>
> HTH
>
> Ciao, Horst

On Thursday 04 September 2003 20:47, Angry Guy wrote:

> This is an ASP setup where the inside network holds managment
> server/DCs/SQL servers. Unfortunately, some of the forward facing DMZ
> servers require access to a clustered file server. So the file server
> has to be in the DMZ. The environment with the Linux server is a lab,
> production has failover pix fire walls. The traffic between the DMZ
> and Inside networks are heavily ACLd to control access to the inside
> network from the DMZ.
>
> If I use the MASQUERADE target between the two subnets iptables alters
> the source IP on each side to look like the traffic is coming from the
> linux box.

Right, but what is the reason why you use Masquerading
between internal net and DMZ in the first place?

If you need masquerading on another interface, use better
match criterias (see my previous posting). If you don't need
masquerading at all, just leave the masquerade rule off. In
this case you still can use iptables and filter traffic.


[Changing IP Addresses for a communication]

> So again, I need to aviod passing this traffic through the tables and
> just route it as is between these two computers. I can live with these
> 2 servers in the lab being wide open to each other. Right now I have
> two options, route with no tables between the subnets, which means I
> have no acls between the DMZ and Inside, or enable iptables and break
> the cluster. Neither is a usable situation.

See above, use iptables but avoid masquerading. Masquerading
breaks your communication for sure.


> I haven't been able to force the cluster to talk on just its virual
> ip....so I'm running low on options. The last step is toss the linux
> box and get a pix, but I'd like to keep Tux around

This would be a bad idea from my point of view. ;-)


Ciao, Horst
--
»When pings go wrong (It hurts me too)« E.Clapton/E.James/P.Tscharn