Mangling the routing table with net balancer?

[MastusMember]

Hi,

I have 3xPPPoE connections via one ethernet card and the net balancer is working fine per se.

I have put up balancing rules to route https traffic via one gateway to get web banking and other https sites working.

Some http sites (for example rapidshare) still check downloads against the IP address and so rapidshare is broken if port 80 is not on the balancing rules. I don’t want to redirect all http traffic via one gateway, so some kind of conditional rule is needed.

I was thinking something like this:
– Somebody writes rapidshare.com:81 on web browser in a LAN
– Net balancer has a balancing rule to redirect all TCP traffic on port 81 to specific gateway, so the HTTP request hits this rule and certain gateway is used
– Use some kind of pre/postrouting method to change the destination port back to 80… AFTER the net balancer rule is hit.

Does this make any kind of sense, and if it does – how to do it?

[athelingMember]

Wouldn’t it just be easier to have a pre-routing rule that looks at the destination IP and port (80) and sets the fwmark associated with routing to your gateway of choice? If rapidshare uses more than on IP address and they are all in in a small range then you could open up that IP address to be a subnet.

[MastusMember]

@atheling wrote:

Wouldn’t it just be easier to have a pre-routing rule that looks at the destination IP and port (80) and sets the fwmark associated with routing to your gateway of choice? If rapidshare uses more than on IP address and they are all in in a small range then you could open up that IP address to be a subnet.

This list http://forums.peerblock.com/read.php?12,3963 seems to be quite valid.

It is possible to enter all ip ranges in net balancer config but even so, only rapidshare will work. Some forums will also need the ip address to be “static”. I think it would be smarter to have a way of choosing the gateway per request.

But is this even a iptables/routing question (as in “Can it do it”?) or do I need to consider somekind of proxying?

[athelingMember]

In another thread ppalias said he used a set of NetBalance rules to basically divide the IP address range into two halves when considering HTTP/S connections. One half he always routes through one interface, the other half through the other.

@ppalias wrote:

…snip…
Yup you are right, I had some issues with OpenVPN with the static routes, so I created 2 pairs of Netbalancer rules for the destination ports 80 and 443 for the 0.0.0.0/1 and destination 128.0.0.0/1.
…snip…

As long as the rules for HTTP are the same as for HTTPS then the site would see the same IP from you for both protocols.

You have three interfaces which does not work into powers of two very well. But maybe dividing things like this might work:

IP range: 0.0.0.0/2 use interface 1
IP range: 64.0.0.0/2 use interface 2
IP range: 128.0.0.0/2 use interface 3
IP range: 192.0.0.0/4 use interface 1
IP range: 208.0.0.0/4 use interface 2
IP range: 224.0.0.0/4 use interface 3
IP range: 240.0.0.0/4 pick an interface

(I hope I have those subnet ranges close.)

Anyway that would roughly spread your HTTP/S traffic equally among the three interfaces based on the destination address. (5/16s of the traffic on two interfaces and 6/16s of the traffic on the third).

Assuming that the HTTPS and HTTP servers are in the same general part of the IP address range, what ever route is picked for your HTTPS session would be the same route for the HTTP session.

I hope that we can figure out how to make routing decisions for destinations “sticky” which would solve this problem for everyone without resorting to this type of hack.

[MastusMember]

@atheling wrote:

In another thread ppalias said he used a set of NetBalance rules to basically divide the IP address range into two halves when considering HTTP/S connections. One half he always routes through one interface, the other half through the other.

As long as the rules for HTTP are the same as for HTTPS then the site would see the same IP from you for both protocols.

You have three interfaces which does not work into powers of two very well. But maybe dividing things like this might work:

IP range: 0.0.0.0/2 use interface 1
IP range: 64.0.0.0/2 use interface 2
IP range: 128.0.0.0/2 use interface 3
IP range: 192.0.0.0/4 use interface 1
IP range: 208.0.0.0/4 use interface 2
IP range: 224.0.0.0/4 use interface 3
IP range: 240.0.0.0/4 pick an interface

(I hope I have those subnet ranges close.)

Anyway that would roughly spread your HTTP/S traffic equally among the three interfaces based on the destination address. (5/16s of the traffic on two interfaces and 6/16s of the traffic on the third).

Assuming that the HTTPS and HTTP servers are in the same general part of the IP address range, what ever route is picked for your HTTPS session would be the same route for the HTTP session.

I hope that we can figure out how to make routing decisions for destinations “sticky” which would solve this problem for everyone without resorting to this type of hack.

Well, that would work but doesn’t it nullify the point of having a load balancer 😕 Except in that case that connections are spread evenly on 0.0.0.0-255.255.255.255 range.

I thought about adding a third NIC in the ZS box, which would have been statically routed to use a specific connection. But then I’d have to fiddle with gateway settings every time that I want to use this “sticky” connection. And then ALL traffic would have been routed through this connection. As far as I know, I can’t bind any web browser to use certain network interface…

But the manual gateway switching has some applications. If I could specify the target gateway from LAN, for example I could start 3 parallel downloads from certain services that don’t allow parallel downloads.

[MastusMember]

I could use some help with the iptables. As in can it do the routing I described on the first post on this thread.

I don’t know much about iptables, but I have some spare time so tinkering around with iptables is an option to pass the time…

Please point out the faults why this wouldn’t work:

– I type http://www.google.com:1235 on a web browser
– ZS receives the request (random source port, destination port 1235)
http://www.linuxhomenetworking.com/wiki/index.php/File:Iptables.gif
– Using above packet flow diagram, I’d suspect that first the packet is checked against mangle table’s prerouting chain.
– Prerouting chain jumps to NetBalancer chain
– NetBalancer chain marks the connection (source: LAN IP address, destination anywhere, protocol tcp, destination port 1235) to go out of specified gateway
– Next the packet is matched against nat table’s prerouting chain, which has a rule in the vein of:

iptables -t nat -A PREROUTING -p tcp -i ETH00 -s [lan ip address] –dport 1235 -j REDIRECT –to-ports 80

The HTTP request now should leave out as “www.google.com:80”

The above iptables command doesn’t work though… but why doesn’t it?

[athelingMember]

From the image you linked to it looks like you found one of the documents I have been learning from. 🙂

I haven’t played much with the nat tables so I don’t have personal experience with the REDIRECT target. I did find this however: http://www.linuxtopia.org/Linux_Firewall_iptables/x4508.html and it says

The REDIRECT target is used to redirect packets and streams to the machine itself.

So it would seem that filter target is not doing what you want. I am guessing, and I emphasize the word guessing, that you would need to NAT those packets to get them to your desired destination and also to have the returned packets get back to your original LAN client machine. Not sure if masquerade or SNAT is needed. (Like I wrote, I haven’t done much with NAT other than follow a couple of cookbooks.)

And I don’t see how using alternative ports actually fixes your problem.

[ppaliasMember]

I think that the usage of SNAT in POSTROUTING is much better than REDIRECT.

[MastusMember]

@atheling wrote:

From the image you linked to it looks like you found one of the documents I have been learning from. 🙂

I haven’t played much with the nat tables so I don’t have personal experience with the REDIRECT target. I did find this however: http://www.linuxtopia.org/Linux_Firewall_iptables/x4508.html and it says

The REDIRECT target is used to redirect packets and streams to the machine itself.

So it would seem that filter target is not doing what you want. I am guessing, and I emphasize the word guessing, that you would need to NAT those packets to get them to your desired destination and also to have the returned packets get back to your original LAN client machine. Not sure if masquerade or SNAT is needed. (Like I wrote, I haven’t done much with NAT other than follow a couple of cookbooks.)

And I don’t see how using alternative ports actually fixes your problem.

Thanks. I should practice my reading skills… the thing about the redirect target was clearly on the manual.

Using alternative ports MIGHT have an impact… I know it’s possible to have a some kind of redirector addon on Firefox. I click a link “www.zeroshell.net” and the redirector changes the address to “www.zeroshell.net:1235”. If the requests that have port 1235 as a destination port are matched to go out of a specific gateway and then destination port changed back to 80 -> I have a functionality to manually select static target gateway.

I think that SNAT in postrouting won’t work… because I don’t know the destination IP address and I have dynamic WAN IP addresses.

I only want to modify the outgoing IP packet’s destination port field.

[Author]

Posts