Re: [LARTC] Wondershaper breaks IPSec tunnels

["Jason A. Pattie" <pattieja@pcxperience.com>]

-----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/