From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jason A. Pattie" Date: Fri, 12 Mar 2004 15:55:07 +0000 Subject: Re: [LARTC] Wondershaper breaks IPSec tunnels Message-Id: <4051DD5B.8070707@pcxperience.com> List-Id: References: <4048BDD8.2050201@pcxperience.com> In-Reply-To: <4048BDD8.2050201@pcxperience.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Damion de Soto wrote: | Hi Jason, | |> Am I silently being told that this is the wrong question to ask of this |> list? :) | | | Probably. I'll reply but I think it'll only be of statistic interest. First of all, thanks for replying. |> | I now have a situation where I get to use traffic shaping for a client. |> | ~ We implemented the WonderShaper script on our own firewall and |> | experienced no problems. I made some modifications to it to add IPSec |> | protocol packets into the 1:10 high priority class using the u32 |> filter. |> | ~ So far on our network, it's worked flawlessly, and we've received |> much |> | benefit from it. Interactive SSH and VNC sessions are now much, much |> | smoother when, for example, we do an apt-get update/upgrade/install at |> | the same time or any downloading, e-mailing, etc. | | Yeah, I've done the same thing. | | |> | However, yesterday, I installed it for a client using the same |> | modifications we have been using, and at first, I only added the |> | modifications to the client's external interface (eth1). Within an |> | hour, the FreeS/WAN VPN connections could no longer negotiate new |> | tunnels when rekeying. In his scenario, he has two DSL connections |> | (eth1, eth2) coming into the firewall with a single internal interface |> | (eth0). It appears that something broke the VPN negotiation when I |> | installed the WonderShaper. As long as the tunnels are up when I start |> | WonderShaper, they work fine, until they need to rekey. Then they |> throw |> | errors saying things like "max number of retransmissions reached", and |> | "Possible authentication failure: no acceptable response to our first |> | encrypted message", etc. The moment I 'stop' the WonderShaper, the VPN |> | tunnels can be reestablished successfully. |> | |> | I was wondering if anyone else has experienced these kinds of problems |> | with the WonderShaper and IPSec tunnels? | | Nope, never seen traffic shaping cause problems like that. | |> | Also, I'm attempting to prioritize RDP packets on the ipsec0 interface. |> | ~ Is this as simple as copying every line in the script except changing |> | $DEV to $DEV2 which is assigned to ipsec0 and adding a u32 match for |> | sport 3389? That's currently what I've done. | | I believe so. | |> | I just can't get over the fact that it works (in almost the exact same |> | scenario, except for the 2 DSL circuits) on our firewall, but not our |> | client's. | | |> | These are the changes that I made to match IPSec traffic and place it |> | into the high priority class (where DEV = eth1 -- the Internet): | | I've put my IPSec traffic in the middle class. But isn't that where it would be if I did nothing to it? Only the really bad traffic gets put in 1:30, right? BTW, the middle class is 1:20, correct? | The only thing I can think of, is that the particular client has | saturated one of the lower priority leaf classes, and delayed the | traffic in the high-priority class for too long for a valid key exchange. | | Unless you've changed it, the wondershaper doesn't specify ceil values, Nope. Haven't changed those values. Do I want to? I basically want any traffic of lower priority to be able to take all the bandwidth as long as there is no traffic of a higher priority around, but have it give way to higher priority traffic when present. | which means they get set to the rate value, and unless you've changed | the way it calculates it's percentage rate values, the sum of the leaf | rates can exceed the parent. | which i believe can lead to weird and/or bad behaviour. Hmm. Guess I'll have to look into this more. Thank you very much. - -- Jason A. Pattie pattieja@xperienceinc.com Xperience, Inc. (http://www.xperienceinc.com) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD0DBQFAUd1buYsUrHkpYtARAs7nAI996t9hXqbx2Kuc+41e0Kq+ffcAn0tUX1nD OBvCVe9hMQ6PABSsx9lc =HxR0 -----END PGP SIGNATURE----- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/