Posts Tagged ‘ADSL’

Multihomed routing (split access load balancing) and OpenVPN

Sunday, June 25th, 2006

We have one connection via ATM like interface and we have one PPP connection via xDSL (described here), and we want load balancing for this whole party.

Following this specific part of guide, we’ve managed to get this to work. The idea goes like this (Centos 4.3):

1. Do not state default route for the machine. Not in /etc/sysconfig/network and not in /etc/sysconfig/network-scripts/ifcfg-ethX

2. Using adsl-setup, we’ve defined our ADSL connection. Verify you have an entry DEFROUTE=no in your /etc/sysconfig/network-scripts/ifcfg-ppp0

3. find a way to start the following script after your network interfaces are up. I assume, in this script, that your ATM interface is eth1. multiroute.txt

The reason for specifically stating SERVER is that our DNS server requires recursive DNS for its settings, and I can use my ISP’s DNS Server only when using the corresponding link. Since both links are for different ISPs, I need to “bind” SERVER to a specific route.

Note that this solution is only temporary. At the moment, it is far from being complete, and many tests should be done yet, before I can call it a working solution. I might combine it with /etc/ppp/ip-up.local script, or I might add it as a seperated service in /etc/init.d, which would start after all interfaces are up and running. Not final yet.

With all this working like charm, we’ve had a huge issue – our OpenVPN server, which worked correctly just until then failed to work smoothly. Sometimes clients were able to connect, and sometimes they were unable to do so…

I got the following error message in my logs: “x.y.z.m:2839 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

The cause, as it seemed to me, was that OpenVPN’s UDP packets were routed via alternate route for each target client. Being UDP, they were not part of an active session, but were stateless, which resulted in a different routing descision each time they were directed at the OpenVPN client. I’ve searched for it, although I was not optimistic, because multihomed routing, with multiple ways out wasn’t very common. I was suprised to find this post, with it’s follow-up, which dealt exactly with my case.

Since I cannot bind it to an internal IP address (although I’ve tried – it didn’t work), I will test TCP based configuration tomorrow morning.




I don’t usually update posts but add new posts with links. However, in this case it was important enough for me to update this hot topic so I’ve decided to just add the new stuff.

First – I’ve failed. Since I do not have too much time here, I did not feel confident to leave a system yet untested. Especially when such a router is an essential link in this company.

I’ve tried using TCP based connection, but, still again, one client was able to connect, while the 2nd one did so for only a short while, and failed maintaining a working connection. I went back to UDP…

I came up with the following idea – if I can use some sort of tagging to differentiate the UDP packets sourced at the router, at the OpenVPN application, I could try and set a routing rule which will force them into a specific routing chain, and force them through my interface.

It didn’t work quite well. I was able to do the followin trick, but for no avail:

iptables -t mangle -A OUTPUT -p udp –sport 5001 -j MARK –set-mark 1

and then, using “ip” command:

ip rule add fwmark 1 table T1

which should have redirected all outbound UDP with source port 5001 (this is the one I use for my OpenVPN, due to legacy considerations), to the T1 routing table – a table directed outside with default route via eth1.

I don’t know why it failed. Almost seemed to work, but no…

I returned the system to a single-path setup, with PPP0 only acting as a manual alternate path in case where the primary path is down. Would work for now.

Software Suspend 2, a success story

Wednesday, July 20th, 2005

Owning a laptop, you try to get the best out of it. you want it to be the strongest it can, you want it to be fast, reliable, useful, and cunning. My Fujitsu is cunning, I can say. Not a day passes without me hearing someone saying "Wow, it is so small". I didn’t get it for the audiance, though, I got it because traveling to end users and customer sites could be frustrating when you have no connectivity, and you cannot relay on the customers environment. I once, few years ago, had the paradox I call "The Ez paradox", where I got to a customer who just arranged a brand new ADSL line, had a network card with me, but I forgot the drivers. There was no way I could connect using her computer, nor did I have my laptop then. It consumed few extra hours just finding someone around who could allow me to use his computer to download the NIC drivers. Never again, I swore then, and I was proven to be right. There was one time with another customer, where I proved the screen to be the problem, and not the computer’s VGA card, using my laptop, and another where I could remove the blame from a poor and unjustly accused computer, because I could not connect to the internet using the same ADSL line from my own laptop, etc. It’s a usefull machine, and it saves my time.

One of the things one expects is to open his laptop’s cover, and "Whoosh!", get an up-and-running system right then. As we all know computers, this is not the case. Running Linux on the laptop, it was even worse. Up till a year ago, Software Suspend solution for a pooched ACPI enabled laptops, with no hardware suspend built-in, were, how to say, poor at best. I remember being able to suspend using some SWSUSP beta version, and it was able to suspend and resume about 2/3 of the times I tried to, took five minutes, and not always when it didn’t manage to suspend I was attentative enough to notice it. The poor laptop got to remain up and running (and when swsusp got hang, it consumed 100% CPU) inside my bag few times, until I discovered it half an hour or so later. Not good. Not only this, but this beta version worked sometimes, while its following release (or RC) version failed to suspend or resume or both completely. It was far from being perfect. However, I am full of respect to the people who made it, fighting uncommon hardware setups, which you can find only in laptops, and made a mature and working

Mature, becuase it works, not becuase it’s the most trivial thing to make it work.

I can clearly say that SWSUSP2, in version 2.1.9, for kernel is remarkebly fast, clear, and well working. Using the new UserUI (Nice splash screen with animation, showing during the suspend/resume operation), i can be the envy of my peers, if only they cared.

For anyone on the net asking about it, i can describe shortly how and what I did to make it work.

First, follow the instructions in Software Suspend web site. They know what they are saying, although their site is not always organized (it’s getting better, with the Wiki! Keep the good work!).

To Explain in short words what I have done:

  1. Get and untar/bzip2 kernel version (linux-
  2. Get software-suspend-2.1.9-for-2.6.11
  3. Patch the new kernel by using the new method swsusp2 supply (RTFM)
  4. Patch the new kernel with your newly downloaded fbsplash-0.9.2-2.6.11 patch
  5. Get, unzip and compile userui package (note – You will need to edit fbanim/userui_fbanim_core.c and change #include <linux/fb.h> into #include "linux/fb.h" else it won’t compile
  6. You would want to make your own kernel now. It’s going to take a while. You can borrow from my own config (config- file.
  7. Anything further can be found easilly in Software Suspend Wiki
  8. Make sure your initrd (if you use it) is set up correctly

It should work correctly at this point. You would like to pick a nice graphics, and I hope, with the help of my wife, to arrange myself some uniqe and eye catching image. Why? Because. It doesn’t cost my anything further, and it will sure attract attention to the system.