[LARTC] Wondershaper breaks IPSec tunnels

[LARTC] Wondershaper breaks IPSec tunnels

[Jason A. Pattie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello, been awhile since I've written.

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.

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?

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 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):
- ----------
# IPSec traffic in 1:10
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
~      match ip protocol 0x32 0xff \
~      flowid 1:10

tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
~      match ip protocol 0x33 0xff \
~      flowid 1:10


These are the changes to match RDP on the IPSec interface (where DEV2 ipsec0):
- ----------
# RDP (Remote Desktop Protocol) in interactive class 1:10 on ipsecN
interfaces
tc filter add dev $DEV2 parent 1: protocol ip prio 10 u32 \
~   match ip sport 3389 0xffff \
~   flowid 1:10


Are these even valid?

Thank you for your time.

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

iD8DBQFASL3YuYsUrHkpYtARApa3AJ4mTCkmMwC3FYziUeQyUE5FuouUhACaA+ym
GtrHZ3dZNC9WF9AP6Z80qP0=H5D4
-----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/

Re: [LARTC] Wondershaper breaks IPSec tunnels

[Jason A. Pattie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am I silently being told that this is the wrong question to ask of this
list?  :)

Jason A. Pattie wrote:
| Hello, been awhile since I've written.
|
| 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.
|
| 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?
|
| 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 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):
| ----------
| # IPSec traffic in 1:10
| tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
| ~      match ip protocol 0x32 0xff \
| ~      flowid 1:10
|
| tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
| ~      match ip protocol 0x33 0xff \
| ~      flowid 1:10
|
|
| These are the changes to match RDP on the IPSec interface (where DEV2 | ipsec0):
| ----------
| # RDP (Remote Desktop Protocol) in interactive class 1:10 on ipsecN
| interfaces
| tc filter add dev $DEV2 parent 1: protocol ip prio 10 u32 \
| ~   match ip sport 3389 0xffff \
| ~   flowid 1:10
|
|
| Are these even valid?
|
| Thank you for your time.
|

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

iD8DBQFAUH7luYsUrHkpYtARAtrwAJ0VMDLsj3OkSC8y9q2ATpn1atZsQQCfSXwb
qJ8gocIXuwXk04MWvF/tKBY\aVU
-----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/

Re: [LARTC] Wondershaper breaks IPSec tunnels

[Damion de Soto]

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.


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

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, 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.




-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Damion de Soto - Software Engineer  email:     damion@snapgear.com
SnapGear - A CyberGuard Company ---    ph:         +61 7 3435 2809
  | Custom Embedded Solutions          fax:         +61 7 3891 3630
  | and Security Appliances            web: http://www.snapgear.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  ---  Free Embedded Linux Distro at   http://www.snapgear.org  ---

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] Wondershaper breaks IPSec tunnels

[Jason A. Pattie]

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

Re: [LARTC] Wondershaper breaks IPSec tunnels

[Damion de Soto]

Hi Jason,
> 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?
Yeah, it is.  I can't recall exactly why I did that, but it doesn't seem to make 
sense now.
Oh, yes I can.  I have other filters setup for TOS bits, and wanted to make sure that 
no matter what TOS bits the ipsec packets had, they were going into 1:20.

> 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.
I guess it depends on whether or not you want delays.  I try to keep my ceil values 
just a little bit below the max they could hit.
although I guess it's probabaly not really noticable.

> | 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.
yeah, check out "What if sum of child rates is greater than parent rate ?"
on http://luxik.cdi.cz/~devik/qos/htb/htbfaq.htm

regards

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Damion de Soto - Software Engineer  email:     damion@snapgear.com
SnapGear - A CyberGuard Company ---    ph:         +61 7 3435 2809
  | Custom Embedded Solutions          fax:         +61 7 3891 3630
  | and Security Appliances            web: http://www.snapgear.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  ---  Free Embedded Linux Distro at   http://www.snapgear.org  ---

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/