-----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@xxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
