-----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@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
iD8DBQFAUH7luYsUrHkpYtARAtrwAJ0VMDLsj3OkSC8y9q2ATpn1atZsQQCfSXwb qJ8gocIXuwXk04MWvF/tKBY= =07VU -----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/
