Split access on a single interface

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Title: Message

Hi you all,

I'm working on outbound load-balancing between multiple (actually 2) ISPs. Examples given in Policy Routing 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 SNAT 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

[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux