Forwarding for wider comments.
-Steve L.
----- Forwarded message from Tommy McNeely <[EMAIL PROTECTED]> -----
Date: Sun, 09 Nov 2008 20:56:45 -0700
From: Tommy McNeely <[EMAIL PROTECTED]>
Subject: [zones-discuss] using load balancers with zones
To: [EMAIL PROTECTED]
Errors-to: [EMAIL PROTECTED]
X-Mailer: Apple Mail (2.929.2)
Precedence: list
X-BeenThere: [EMAIL PROTECTED]
Delivered-to: [EMAIL PROTECTED]
X-PMX-Version: 5.4.1.325704
X-Brightmail-Tracker: AAAAAA==
X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on
oss-mail1.opensolaris.org
X-Original-To: [EMAIL PROTECTED]
X-Antispam: No, score=0.0/5.0, scanned in 0.081sec at (localhost [127.0.0.1])
by smf-spamd v1.3.1 - http://smfs.sf.net/
X-Mailman-Version: 2.1.9
List-Post: <mailto:[EMAIL PROTECTED]>
List-Subscribe: <http://mail.opensolaris.org/mailman/listinfo/zones-discuss>,
<mailto:[EMAIL PROTECTED]>
List-Unsubscribe: <http://mail.opensolaris.org/mailman/listinfo/zones-discuss>,
<mailto:[EMAIL PROTECTED]>
List-Archive: <http://mail.opensolaris.org/pipermail/zones-discuss>
List-Help: <mailto:[EMAIL PROTECTED]>
List-Id: Zones General Discussion <zones-discuss.opensolaris.org>
X-Spam-Status: No, score=0.1 required=5.0 tests=DNS_FROM_SECURITYSAGE
autolearn=no version=3.2.3
X-Spam-Level:
Continuing on my zones in different subnets theme, but starting a new
thread to improve readability...
The other problem I have been experiencing can be "solved" with the
right ipf.conf incantation (I think).
Lets pretend the host (zone) mail-fe-1 initiates a connection to
dirsrv-lb (load balancer) on port 389/tcp. The Load balancer decides
to send that connection (dnat) to host (zone) dirsrv-1, which happens
to be on the same physical server (global zone) as the mail-fe-1 zone...
(all networks below are /24)
So, according to mail-fe-1:
LOCAL: mail-fe-1 (172.16.1.51)
REMOTE: dirsrv-lb (172.16.1.30)
... and according to dirsrv-1:
LOCAL: dirsrv-1 (172.16.3.31)
REMOTE: mail-fe-1 (172.16.1.51)
If these are all separate physical machines (or at least one physical
machine per subnet), there would be no problems, because in order to
get back to mail-fe-1 (172.16.1.51), the host dirsrv-1 (172.16.3.31)
would use its default router (the load balancer), which would fix
(snat) the source address to be dirsrv-lb (172.16.1.30), and everyone
would be happy. Since they are on the same physical machine, even
though they are on separate physical interfaces, they "find" each
other as the packet is flowing out e1000g3, and comes back in e1000g1,
but never really gets back because the Local/Remote addresses don't
match, so mail-fe-1 never sees the S/A. The host based firewall (ipf)
gets scared and confused and blocks the packet, but I don't think that
it would even matter if IPF wasn't being used, because I had this
problem in the past without ipf or any firewall with everything on the
same subnet. Same issue, the packet was returned directly instead of
via the wire where it would have (presumably) flowed through the load
balancer and gotten fixed.
I can obviously workaround the issue by using source-nat in the load
balancer, causing dirsrv-1 to think that the connection came FROM the
load balancer (or one of its nat-pool IP addresses) to force the
packet onto the wire, but that makes logs useless on dirsrv-1 and
troubleshooting a who made what changes issue a nightmare.
I am sure there must be a way to tell ipf to force packets from the be-
net to the fe-net to go out on the wire, presumably using "dup-to" but
I was unable to make it work, so I am using source-nat at the moment.
I look forward to hearing that someone else has already figured this
out and here is how they did it, but for now I need to work on
installing software on "mail-fe-1" because it was supposed to be
working last Tuesday ;)
Thanks in advance,
Tommy
_______________________________________________
zones-discuss mailing list
[EMAIL PROTECTED]
----- End forwarded message -----
_______________________________________________
networking-discuss mailing list
[email protected]
