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