From: Patrick Zwahlen <Patrick.Zwahlen@eu.didata.com>
To: lartc@vger.kernel.org
Subject: [LARTC] Split access on a single interface
Date: Mon, 03 Feb 2003 10:36:31 +0000 [thread overview]
Message-ID: <marc-lartc-104426847715541@msgid-missing> (raw)
Hi you all,
I'm working on outbound load-balancing between multiple (actually 2) ISPs.
Examples given in docs/articles are perfectly working, but I would like to
go a bit further.
My idea would be to have a "cheap" LinkProof (from Radwar) box, and the
major difference between this box and a Linux solution is that a LinkProof
can be installed without changing the IP addressing.
Basically, both ISP routers are connected to a shared hub, together with the
LinkProof and the box connecting the internal network (Firewall, Router...)
The LinkProof is then doing what they call SmartNAT (for outbound only.
Inbound is handled by DNS)
My major problem is the NATting decision for outgoing connections:
On Linux, I have two default routes in a routing table, and depending on the
routing decision, I can match the OUTGOING INTERFACE (-o ethX) to take a NAT
decision in the NAT POSTROUTING chain. If I now have a single interface for
both providers, this obviously doesn't work anymore...
The box obviously still acts as a router, and thus it HAS to have multiple
IP interfaces. I'v tried to setup alias interfaces, but "eth0:1" CANNOT be
matched in a NAT rule :-(
Any clue if (and how) I could solve this ?
PS1: The fact that the internal Router/Firewall is also connected to this
same shared network is just an extension to the problem described above. I
think we can forget about it for the moment.
PS2: I'm planning to make some tests with "keepalived" to have two such
boxes in VRRP failover. Anyone with some bad/encouraging results with that ?
Am I completely crazy to just think about it ? ;-)
______________________________________________
DISCLAIMER
This email and any files transmitted with it, including replies and forwarded copies (which may contain alterations) subsequently transmitted from the Company, are confidential and solely for the use of the intended recipient. It may contain material protected by attorney-client privilege. The contents do not represent the opinion of Dimension Data Switzerland except to the extent that it relates to their official business.
If you are not the intended recipient or the person responsible for delivering to the intended recipient, be advised that you have received this email in error and that any use is strictly prohibited. If you are not the intended recipient, please advise the sender by return e-mail, then delete this message and any attachments.
Dimension Data Switzerland : http://www.ch.didata.com
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
reply other threads:[~2003-02-03 10:36 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-lartc-104426847715541@msgid-missing \
--to=patrick.zwahlen@eu.didata.com \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.