I have a box in the lan that sends packets through open vpn.
openvpn is running on the shorewall boxes on both endpoints.
The traffic is being classified, but clipping is occuring.
Does traffic have to be classifed on the openvpn interface as well?
All of the traffic originates in the loc (lan). On one end the
voip box is 10.19.227.240 in this <snip>
This rule I have recently tryed but not enough time to see if it has
improve voip which I was thinking would mark traffic going through open
vpn from 10.19.227.240 > 10.192.139.240
1 $FW 10.192.139.240 ALL
pkts bytes target prot opt in out source
destination
1203K 223M CLASSIFY all -- * * 10.19.227.18
0.0.0.0/0 CLASSIFY set 1:11
46 2864 CLASSIFY icmp -- * eth0 0.0.0.0/0
0.0.0.0/0 icmp type 8 CLASSIFY set 1:12
0 0 CLASSIFY icmp -- * eth0 0.0.0.0/0
0.0.0.0/0 icmp type 0 CLASSIFY set 1:12
23 1448 CLASSIFY icmp -- * eth1 0.0.0.0/0
0.0.0.0/0 icmp type 8 CLASSIFY set 1:12
176 10704 CLASSIFY icmp -- * eth1 0.0.0.0/0
0.0.0.0/0 icmp type 0 CLASSIFY set 1:12
0 0 CLASSIFY tcp -- eth1 * 10.194.53.0/24
0.0.0.0/0 multiport dports 23 CLASSIFY set 1:12
0 0 CLASSIFY tcp -- * eth0 0.0.0.0/0
0.0.0.0/0 multiport dports 53 CLASSIFY set 1:13
0 0 CLASSIFY tcp -- * eth0 0.0.0.0/0
0.0.0.0/0 tcp spt:53 CLASSIFY set 1:13
326K 25M CLASSIFY udp -- * eth1 0.0.0.0/0
0.0.0.0/0 multiport dports 53 CLASSIFY set 2:13
0 0 CLASSIFY udp -- * eth1 0.0.0.0/0
0.0.0.0/0 udp spt:53 CLASSIFY set 2:13
5318K 542M CLASSIFY tcp -- * eth0 0.0.0.0/0
0.0.0.0/0 multiport dports 80 CLASSIFY set 1:12
2096 2573K CLASSIFY tcp -- * eth0 0.0.0.0/0
0.0.0.0/0 tcp spt:80 CLASSIFY set 1:12
68144 11M CLASSIFY tcp -- * eth1 0.0.0.0/0
0.0.0.0/0 multiport dports 80 CLASSIFY set 2:12
238K 293M CLASSIFY tcp -- * eth1 0.0.0.0/0
512:P 0.0.0.0/0 64.42.53.203 all
512:P 64.42.53.203 0.0.0.0/0 all
256:P eth3:10.19.227.0/24 0.0.0.0/0 tcp ftp
256:P eth3:10.19.227.0/24 0.0.0.0/0 tcp ftp-data
#2:P:103 eth3:10.19.227.0/24 64.42.53.203 all
#2:P:103 eth3:10.19.227.0/24 0.0.0.0/0 tcp 25
tcrules---------------------------------------------------------------------
#
# Route Arkona to eth0
256 $FW 216.177.224.2 all
512 $FW 216.174.194.53,216.174.194.54 all
256:P eth3:10.19.227.0/24 216.177.224.2 tcp
domain
256:P eth3:10.19.227.0/24 216.177.224.2 udp
domain
512:P 0.0.0.0/0 216.174.194.53,216.174.194.54 tcp
domain
512:P 0.0.0.0/0 216.174.194.53,216.174.194.54 udp
domain
#256:P eth1:10.194.53.0/24 0.0.0.0/0 ESP
#2:F eth0 0.0.0.0/0 ESP
#2 $FW 0.0.0.0/0 ALL
# ************ Maximize priority of VoIP traffic
*******************************************
#
#
1:11 10.19.227.18 0.0.0.0/0 ALL
1 $FW 10.192.139.240 ALL
#
# ************ Prioritize pings with low payload
*******************************************
1:12 0.0.0.0/0 eth0 icmp echo-request
1:12 0.0.0.0/0 eth0 icmp echo-reply
1:12 0.0.0.0/0 eth1 icmp echo-request
1:12 0.0.0.0/0 eth1 icmp echo-reply
1:12 eth1:10.194.53.0/24 0.0.0.0/0 tcp
telnet
# ************ Prioritize services
*********************************************************
# DNS
1:13 0.0.0.0/0 eth0 tcp 53
1:13 0.0.0.0/0 eth0 tcp - 53
2:13 0.0.0.0/0 eth1 udp 53
2:13 0.0.0.0/0 eth1 udp - 53
# HTTP
1:12 0.0.0.0/0 eth0 tcp 80
1:12 0.0.0.0/0 eth0 tcp - 80
2:12 0.0.0.0/0 eth1 tcp 80
2:12 0.0.0.0/0 eth1 tcp - 80
# SMTP/POP3
1:13 0.0.0.0/0 eth0 tcp 25
1:13 0.0.0.0/0 eth0 tcp - 25
2:13 0.0.0.0/0 eth1 tcp 25
2:13 0.0.0.0/0 eth1 tcp - 25
1:13 0.0.0.0/0 eth0 tcp 110
1:13 0.0.0.0/0 eth0 tcp - 110
2:13 0.0.0.0/0 eth1 tcp 110
2:13 0.0.0.0/0 eth1 tcp - 110
# SSH
1:12 0.0.0.0/0 eth0 tcp 22
Thanks
Mike
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
I have a box in the lan that sends packets through open vpn.
openvpn is running on the shorewall boxes on both endpoints.
The traffic is being classified, but clipping is occuring.
Does traffic have to be classifed on the openvpn interface as well?
All of the traffic originates in the loc (lan). On one end the voip box is
10.19.227.240 in this <snip>
This rule I have recently tryed but not enough time to see if it has improve
voip
which I was thinking would mark traffic going through open vpn from
10.19.227.18 > 10.192.139.240
1 $FW 10.192.139.240 ALL
pkts bytes target prot opt in out source
destination
1203K 223M CLASSIFY all -- * * 10.19.227.18
0.0.0.0/0 CLASSIFY set 1:11
46 2864 CLASSIFY icmp -- * eth0 0.0.0.0/0
0.0.0.0/0 icmp type 8 CLASSIFY set 1:12
0 0 CLASSIFY icmp -- * eth0 0.0.0.0/0
0.0.0.0/0 icmp type 0 CLASSIFY set 1:12
23 1448 CLASSIFY icmp -- * eth1 0.0.0.0/0
0.0.0.0/0 icmp type 8 CLASSIFY set 1:12
176 10704 CLASSIFY icmp -- * eth1 0.0.0.0/0
0.0.0.0/0 icmp type 0 CLASSIFY set 1:12
0 0 CLASSIFY tcp -- eth1 * 10.194.53.0/24
0.0.0.0/0 multiport dports 23 CLASSIFY set 1:12
0 0 CLASSIFY tcp -- * eth0 0.0.0.0/0
0.0.0.0/0 multiport dports 53 CLASSIFY set 1:13
0 0 CLASSIFY tcp -- * eth0 0.0.0.0/0
0.0.0.0/0 tcp spt:53 CLASSIFY set 1:13
326K 25M CLASSIFY udp -- * eth1 0.0.0.0/0
0.0.0.0/0 multiport dports 53 CLASSIFY set 2:13
0 0 CLASSIFY udp -- * eth1 0.0.0.0/0
0.0.0.0/0 udp spt:53 CLASSIFY set 2:13
5318K 542M CLASSIFY tcp -- * eth0 0.0.0.0/0
0.0.0.0/0 multiport dports 80 CLASSIFY set 1:12
2096 2573K CLASSIFY tcp -- * eth0 0.0.0.0/0
0.0.0.0/0 tcp spt:80 CLASSIFY set 1:12
68144 11M CLASSIFY tcp -- * eth1 0.0.0.0/0
0.0.0.0/0 multiport dports 80 CLASSIFY set 2:12
238K 293M CLASSIFY tcp -- * eth1 0.0.0.0/0
512:P 0.0.0.0/0 64.42.53.203 all
512:P 64.42.53.203 0.0.0.0/0 all
256:P eth3:10.19.227.0/24 0.0.0.0/0 tcp ftp
256:P eth3:10.19.227.0/24 0.0.0.0/0 tcp ftp-data
#2:P:103 eth3:10.19.227.0/24 64.42.53.203 all
#2:P:103 eth3:10.19.227.0/24 0.0.0.0/0 tcp 25
tcrules---------------------------------------------------------------------
#
# Route Arkona to eth0
256 $FW 216.177.224.2 all
512 $FW 216.174.194.53,216.174.194.54 all
256:P eth3:10.19.227.0/24 216.177.224.2 tcp
domain
256:P eth3:10.19.227.0/24 216.177.224.2 udp
domain
512:P 0.0.0.0/0 216.174.194.53,216.174.194.54 tcp
domain
512:P 0.0.0.0/0 216.174.194.53,216.174.194.54 udp
domain
#256:P eth1:10.194.53.0/24 0.0.0.0/0 ESP
#2:F eth0 0.0.0.0/0 ESP
#2 $FW 0.0.0.0/0 ALL
# ************ Maximize priority of VoIP traffic
*******************************************
#
#
1:11 10.19.227.18 0.0.0.0/0 ALL
1 $FW 10.192.139.240 ALL
#
# ************ Prioritize pings with low payload
*******************************************
1:12 0.0.0.0/0 eth0 icmp echo-request
1:12 0.0.0.0/0 eth0 icmp echo-reply
1:12 0.0.0.0/0 eth1 icmp echo-request
1:12 0.0.0.0/0 eth1 icmp echo-reply
1:12 eth1:10.194.53.0/24 0.0.0.0/0 tcp
telnet
# ************ Prioritize services
*********************************************************
# DNS
1:13 0.0.0.0/0 eth0 tcp 53
1:13 0.0.0.0/0 eth0 tcp - 53
2:13 0.0.0.0/0 eth1 udp 53
2:13 0.0.0.0/0 eth1 udp - 53
# HTTP
1:12 0.0.0.0/0 eth0 tcp 80
1:12 0.0.0.0/0 eth0 tcp - 80
2:12 0.0.0.0/0 eth1 tcp 80
2:12 0.0.0.0/0 eth1 tcp - 80
# SMTP/POP3
1:13 0.0.0.0/0 eth0 tcp 25
1:13 0.0.0.0/0 eth0 tcp - 25
2:13 0.0.0.0/0 eth1 tcp 25
2:13 0.0.0.0/0 eth1 tcp - 25
1:13 0.0.0.0/0 eth0 tcp 110
1:13 0.0.0.0/0 eth0 tcp - 110
2:13 0.0.0.0/0 eth1 tcp 110
2:13 0.0.0.0/0 eth1 tcp - 110
# SSH
1:12 0.0.0.0/0 eth0 tcp 22
Thanks
Mike
I thought this might need a dump and above in my post
there is a mistake. Here is the correct addresses of
the voip boxes.
10.19.227.18>10.192.139.240
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services for just about anything
Open
Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Mike wrote:> I have a box in the lan that sends packets through open vpn. > openvpn is running on the shorewall boxes on both endpoints. > The traffic is being classified, but clipping is occuring. > Does traffic have to be classifed on the openvpn interface as well?You must define shaping on the openvpn interface if you want to prioritize the traffic going through that interface. And you probably also want to give the open VPN traffic itself (usually UDP 1194) a boost on the external interface. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Mike wrote:> I have a box in the lan that sends packets through open vpn. > openvpn is running on the shorewall boxes on both endpoints. > The traffic is being classified, but clipping is occuring. > Does traffic have to be classifed on the openvpn interface as well?You must define shaping on the openvpn interface if you want to prioritize the traffic going through that interface. And you probably also want to give the open VPN traffic itself (usually UDP 1194) a boost on the external interface. -Tom Thank you Tom Not sure how to go about that yet but I will do some studying. I have searched for some examples and posts for simular configurations. Trouble is most are asterisk, these phone systems are vodavi phone boxes using h323 with the bit 7 turned on in the TOS field for their QOS. Since the VOIP cards are assigned an IP I use the IP for Qos. Not much out there for example configs. Has anybody else got any examples for this? On a side note when I did the shorewall dump in the last post I got this error but the dump seemed to work and did not list connections in the dump: [root@gate ~]# shorewall dump > dump cat: /proc/net/ip_conntrack: No such file or directory Is shorewall looking in the wrong place for ipconntrack? Mike ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Mike wrote:> > > > Mike wrote: >> I have a box in the lan that sends packets through open vpn. >> openvpn is running on the shorewall boxes on both endpoints. >> The traffic is being classified, but clipping is occuring. >> Does traffic have to be classifed on the openvpn interface as well? > > You must define shaping on the openvpn interface if you want to prioritize > the traffic going through that interface. And you probably also want to give > the open VPN traffic itself (usually UDP 1194) a boost on the external > interface. > > -Tom > > > Thank you Tom > Not sure how to go about that yet but I will do some studying. > I have searched for some examples and posts for simular > configurations. Trouble is most are asterisk, these phone > systems are vodavi phone boxes using h323 with the bit 7 turned on in the > TOS > field for their QOS. Since the VOIP cards are assigned an IP I use the > IP for Qos. Not much out there for example configs. Has anybody else got > any examples for this? > On a side note when I did the shorewall dump in the last post > I got this error but the dump seemed to work and did not list connections in > the dump: > [root@gate ~]# shorewall dump > dump > cat: /proc/net/ip_conntrack: No such file or directory > > Is shorewall looking in the wrong place for ipconntrack?Shorewall 3.4.1 only knew one place to look for it. I can change the code, Mike, but I can''t make users upgrade. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Interesting this comes up, we find ourselves in a similar situation On 12/13/07, Tom Eastep <teastep@shorewall.net> wrote:> > Mike wrote: > > I have a box in the lan that sends packets through open vpn. > > openvpn is running on the shorewall boxes on both endpoints. > > The traffic is being classified, but clipping is occuring. > > Does traffic have to be classifed on the openvpn interface as well? > > You must define shaping on the openvpn interface if you want to prioritize > the traffic going through that interface. And you probably also want to > give > the open VPN traffic itself (usually UDP 1194) a boost on the external > interface.We''re in a similar situation but with richer set of data which includes video etc. First, it seems that OpenVPN is in a better position to "do the right thing" given you''ve already paid the price for getting packets from the kernel into user space. Perhaps OpenVPN doesn''t support QoS (yet) so the approach Tom suggests might be the only one available.... and is gonna give better performance... of course, most of us are limited by our uplink speeds so cpu typically isn''t the real bottleneck. A finer grained approach is to try something with the ToS... apparently (and I''m just getting to this part of our buildout) OpenVPN will preserve ToS settings with the "passtos" directive.... then, you should be able to use Shorewall to use or set ToS... on the pre-tun0 side, set it if its not right, and post vpn (port 1194) stream use it again to shape within the broader set of rules for your "real "interface". somewhere in here the discussion of OpenVPN''s use of UDP / TCP to carry both types of traffic will come up and I think things could get complicated... -glenn -Tom> -- > Tom Eastep \ Nothing is foolproof to a sufficiently talented fool > Shoreline, \ http://shorewall.net > Washington USA \ teastep@shorewall.net > PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It''s the best place to buy or sell services > for just about anything Open Source. > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > > >-- Glenn H. Tarbox, PhD ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Mike wrote:> > > > Mike wrote: >> I have a box in the lan that sends packets through open vpn. >> openvpn is running on the shorewall boxes on both endpoints. >> The traffic is being classified, but clipping is occuring. >> Does traffic have to be classifed on the openvpn interface as well? > > You must define shaping on the openvpn interface if you want to > prioritize the traffic going through that interface. And you probably > also want to give the open VPN traffic itself (usually UDP 1194) a > boost on the external interface. > > -Tom > > > Thank you Tom > Not sure how to go about that yet but I will do some studying. > I have searched for some examples and posts for simular > configurations. Trouble is most are asterisk, these phone systems are > vodavi phone boxes using h323 with the bit 7 turned on in the TOS > field for their QOS. Since the VOIP cards are assigned an IP I use the > IP for Qos. Not much out there for example configs. Has anybody else > got any examples for this? > On a side note when I did the shorewall dump in the last post I got > this error but the dump seemed to work and did not list connections in > the dump: > [root@gate ~]# shorewall dump > dump > cat: /proc/net/ip_conntrack: No such file or directory > > Is shorewall looking in the wrong place for ipconntrack?Shorewall 3.4.1 only knew one place to look for it. I can change the code, Mike, but I can''t make users upgrade. I am excited about putting the lasted perl version on this box anyway. Just been busy, I have two boxes already upgraded to perl, but this box is a busy one. I am thinking the upgrade to latest perl should go off without a hitch? I was thinking this weeked would be good. The reason I have waited about 150 users on this box. I have been tesing the perl versions elsewhere. Can you think of any issues with this upgrade? Thank you Tom. BTW How is Terry and your Dog? Merry Christmas to your family! ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Mike wrote:> I am excited about putting the lasted perl version on this box > anyway. Just been busy, I have two boxes already > upgraded to perl, but this box is a busy one. I am thinking the upgrade to > latest perl should go off without a hitch? > I was thinking this weeked would be good. The reason I have waited about 150 > users on this box. I have been tesing the perl > versions elsewhere. Can you think of any issues with this upgrade? >The 4.0.x release notes list approximately 20 incompatibilities between earlier Shorewall versions and Shorewall-perl. You need to check each one against your configuration. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Mike wrote:> I have a box in the lan that sends packets through open vpn. > openvpn is running on the shorewall boxes on both endpoints. > The traffic is being classified, but clipping is occuring. > Does traffic have to be classifed on the openvpn interface as well?You must define shaping on the openvpn interface if you want to prioritize the traffic going through that interface. And you probably also want to give the open VPN traffic itself (usually UDP 1194) a boost on the external interface. We''re in a similar situation but with richer set of data which includes video etc. First, it seems that OpenVPN is in a better position to "do the right thing" given you''ve already paid the price for getting packets from the kernel into user space. Perhaps OpenVPN doesn''t support QoS (yet) so the approach Tom suggests might be the only one available.... and is gonna give better performance... of course, most of us are limited by our uplink speeds so cpu typically isn''t the real bottleneck. A finer grained approach is to try something with the ToS... apparently (and I''m just getting to this part of our buildout) OpenVPN will preserve ToS settings with the "passtos" directive.... then, you should be able to use Shorewall to use or set ToS... on the pre-tun0 side, set it if its not right, and post vpn (port 1194) stream use it again to shape within the broader set of rules for your "real "interface". somewhere in here the discussion of OpenVPN''s use of UDP / TCP to carry both types of traffic will come up and I think things could get complicated... -glenn Thank you Glenn, Do you have any examples that you would mind sharing. I have spent a lot of time reading again on shaping. Sometime just get stumped at the starting gate. Also on this setup should have a full t-1 soon, as the current bandwidth is 768 12 channels. This box has two ISP''s but using the T-1 for VOIP. I would be glad to share any think I have with you if that would help. Thanks Mike ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
On 12/13/07, Mike <landers@lanlinecomputers.com> wrote:> > > > Thank you Glenn, > Do you have any examples that you would mind sharing. I have spent a > lot of time reading again on > shaping. Sometime just get stumped at the starting gate. Also on this > setup should have a full t-1 > soon, as the current bandwidth is 768 12 channels. This box has two ISP''s > but using the T-1 for > VOIP. > I would be glad to share any think I have with you if that would help. >I am also early on in the process.... we''re worried about both SIP and IAX but am glad to work through the issues with you. We have really big pipes on one side of our system and a bunch of really small pipes on the other... we''re doing vpn, shaping, and multi-provider... and characterizing metrics on the QoS vector to try and optimize overall "goodness" (technical engineering term). Tom, should we take this to another channel and post a summary of our findings or is it better to just have this discussion broadcast on this list? -glenn Thanks> Mike > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It''s the best place to buy or sell services > for just about anything Open Source. > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > _______________________________________________ > Shorewall-users mailing list > Shorewall-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-users > >-- Glenn H. Tarbox, PhD ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Glenn Tarbox, PhD wrote:> > Tom, should we take this to another channel and post a summary of our > findings or is it better to just have this discussion broadcast on this > list? >Glenn, Why don''t you take this off-line and let us know what you find. I would also encourage you to publish the results on the Wiki so that others can benefit. Thanks! -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
On Thu, Dec 13, 2007 at 01:51:17PM -0800, Glenn Tarbox, PhD wrote:> Tom, should we take this to another channel and post a summary of our > findings or is it better to just have this discussion broadcast on this > list? >FWIW, I am not doing anything on this scale, I would be interested in a summary of your findings at minimum and don''t care if you continue to post to the list. K -- In Vino Veritas http://astroturfgarden.com ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Mike wrote:> I have a box in the lan that sends packets through open vpn. > openvpn is running on the shorewall boxes on both endpoints. > The traffic is being classified, but clipping is occuring. > Does traffic have to be classifed on the openvpn interface as well?You must define shaping on the openvpn interface if you want to prioritize the traffic going through that interface. And you probably also want to give the open VPN traffic itself (usually UDP 1194) a boost on the external interface. -Tom -- Tom I have tried the following for some test until Glenn and I try passing Tos bit through openvpn with the passtos directive which seems to be supported now with openvpn. In my case here there is traffic from 10.19.227.18 which is a pbs phone box with h323 udp traffic for voip and Remote Desktop 3389 no other traffic but these two above. When you state "And you probably also want to give the open VPN traffic itself (usually UDP 1194) a boost on the external interface." Would the two rules work below 2:11 10.19.227.18 0.0.0.0/0 ALL 3:11 10.19.227.18 0.0.0.0/0 ALL Then I am thinking the remote desktop protocall will fall into the default class? Mike #INTERFACE IN-BANDWITH OUT-BANDWIDTH eth0 3000kbit 1152kbit eth1 768kbit 768kbit tun1 768kbit 768kbit #INTERFACE MARK RATE CEIL PRIORITY OPTIONS eth0 1 full full 1 eth0 2 full/4 full 2 eth0 3 full/4 full 3 default eth0 4 full/8 full*8/10 4 # # eth1 1 full full 1 eth1 2 full/4 full 2 eth1 3 full/4 full 3 default eth1 4 full/8 full*8/10 4 ## # tun1 1 full full 1 tun1 2 full/4 full 2 tun1 3 full/8 full*8/10 3 default # ************ Maximize priority of VoIP traffic ******************************************* # # 2:11 10.19.227.18 0.0.0.0/0 ALL 3:11 10.19.227.18 0.0.0.0/0 ALL 2 $FW 10.192.139.240 ALL ---------not sure if this is needed # # ************ Prioritize pings with low payload ******************************************* 2:12 0.0.0.0/0 eth0 icmp echo-request 2:12 0.0.0.0/0 eth0 icmp echo-reply 2:12 0.0.0.0/0 eth1 icmp echo-request 2:12 0.0.0.0/0 eth1 icmp echo-reply 2:12 eth1:10.194.53.0/24 0.0.0.0/0 tcp telnet # ************ Prioritize services ********************************************************* # DNS 1:13 0.0.0.0/0 eth0 tcp 53 1:13 0.0.0.0/0 eth0 tcp - 53 2:13 0.0.0.0/0 eth1 udp 53 2:13 0.0.0.0/0 eth1 udp - 53 # HTTP 1:12 0.0.0.0/0 eth0 tcp 80 1:12 0.0.0.0/0 eth0 tcp - 80 2:12 0.0.0.0/0 eth1 tcp 80 2:12 0.0.0.0/0 eth1 tcp - 80 # SMTP/POP3 1:13 0.0.0.0/0 eth0 tcp 25 1:13 0.0.0.0/0 eth0 tcp - 25 2:13 0.0.0.0/0 eth1 tcp 25 2:13 0.0.0.0/0 eth1 tcp - 25 1:13 0.0.0.0/0 eth0 tcp 110 1:13 0.0.0.0/0 eth0 tcp - 110 2:13 0.0.0.0/0 eth1 tcp 110 2:13 0.0.0.0/0 eth1 tcp - 110 # SSH 1:12 0.0.0.0/0 eth0 tcp 22 1:12 0.0.0.0/0 eth0 tcp - 22 2:12 0.0.0.0/0 eth1 tcp 22 2:12 0.0.0.0/0 eth1 tcp - 22 # ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Mike wrote:> I have a box in the lan that sends packets through open vpn. > openvpn is running on the shorewall boxes on both endpoints. > The traffic is being classified, but clipping is occuring. > Does traffic have to be classifed on the openvpn interface as well?You must define shaping on the openvpn interface if you want to prioritize the traffic going through that interface. And you probably also want to give the open VPN traffic itself (usually UDP 1194) a boost on the external interface. -Tom -- Tom I have tried the following for some test until Glenn and I try passing Tos bit through openvpn with the passtos directive which seems to be supported now with openvpn. In my case here there is traffic from 10.19.227.18 which is a pbs phone box with h323 udp traffic for voip and Remote Desktop 3389 no other traffic but these two above. When you state "And you probably also want to give the open VPN traffic itself (usually UDP 1194) a boost on the external interface." Would the two rules work below 2:11 10.19.227.18 0.0.0.0/0 ALL 3:11 10.19.227.18 0.0.0.0/0 ALL Then I am thinking the remote desktop protocall will fall into the default class? Mike #INTERFACE IN-BANDWITH OUT-BANDWIDTH eth0 3000kbit 1152kbit eth1 768kbit 768kbit tun1 768kbit 768kbit #INTERFACE MARK RATE CEIL PRIORITY OPTIONS eth0 1 full full 1 eth0 2 full/4 full 2 eth0 3 full/4 full 3 default eth0 4 full/8 full*8/10 4 # # eth1 1 full full 1 eth1 2 full/4 full 2 eth1 3 full/4 full 3 default eth1 4 full/8 full*8/10 4 ## # tun1 1 full full 1 tun1 2 full/4 full 2 tun1 3 full/8 full*8/10 3 default BTW the default class in tun1 will be 2, using 3 for test purposes. When I am reffering to the "only traffic" above 3389 and voip means the only traffic through tun1. Mike ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Mike wrote:>Something is weird with this mail client.. had to copy & paste> > Mike wrote: > I have tried the following for some test until Glenn and I try passing Tos > bit through openvpn with the passtos directive which seems to be supported > now with openvpn. In my case here there is traffic from > 10.19.227.18 which is a pbs phone box with h323 udp traffic for voip and > Remote Desktop 3389 no other traffic but these two above. > When you state "And you probably also want to give the open VPN traffic > itself (usually UDP 1194) a boost on the external interface." > Would the two rules work below > 2:11 10.19.227.18 0.0.0.0/0 ALL > 3:11 10.19.227.18 0.0.0.0/0 ALL >I think Tom is referring to openvpn traffic carried on port 1194 between the firewalls. That source would be the external interface and not the phone box. I''m not quite up-to-date on the Qos stuff, but I think the rule would look like: 2:11 $FW 0.0.0.0/0 udp 1194 3:11 $FW 0.0.0.0/0 udp 1194 Jerry ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Jerry Vonau wrote:> Mike wrote: >> > Something is weird with this mail client.. had to copy & paste >> Mike wrote: >> I have tried the following for some test until Glenn and I try passing Tos >> bit through openvpn with the passtos directive which seems to be supported >> now with openvpn. In my case here there is traffic from >> 10.19.227.18 which is a pbs phone box with h323 udp traffic for voip and >> Remote Desktop 3389 no other traffic but these two above. >> When you state "And you probably also want to give the open VPN traffic >> itself (usually UDP 1194) a boost on the external interface." >> Would the two rules work below >> 2:11 10.19.227.18 0.0.0.0/0 ALL >> 3:11 10.19.227.18 0.0.0.0/0 ALL >> > I think Tom is referring to openvpn traffic carried on port 1194 > between the firewalls. That source would be the external interface and > not the phone box. I''m not quite up-to-date on the Qos stuff, but I > think the rule would look like: > 2:11 $FW 0.0.0.0/0 udp 1194 > 3:11 $FW 0.0.0.0/0 udp 1194Need to place the interface name in the DEST column 2:11 $FW eth0 udp 1194 3:11 $FW eth1 udp 1194 I haven''t had time to follow this thread closely so I don''t know if only one of those needs to be there (you only need it on the external interface(s) that handle(s) the VPN traffic). -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Jerry Vonau wrote:> Mike wrote: >> > Something is weird with this mail client.. had to copy & paste >> Mike wrote: >> I have tried the following for some test until Glenn and I try >> passing Tos bit through openvpn with the passtos directive which >> seems to be supported now with openvpn. In my case here there is >> traffic from >> 10.19.227.18 which is a pbs phone box with h323 udp traffic for voip >> and Remote Desktop 3389 no other traffic but these two above. >> When you state "And you probably also want to give the open VPN >> traffic itself (usually UDP 1194) a boost on the external interface." >> Would the two rules work below >> 2:11 10.19.227.18 0.0.0.0/0 ALL >> 3:11 10.19.227.18 0.0.0.0/0 ALL >> > I think Tom is referring to openvpn traffic carried on port 1194 > between the firewalls. That source would be the external interface and > not the phone box. I''m not quite up-to-date on the Qos stuff, but I > think the rule would look like: > 2:11 $FW 0.0.0.0/0 udp 1194 > 3:11 $FW 0.0.0.0/0 udp 1194Need to place the interface name in the DEST column 2:11 $FW eth0 udp 1194 3:11 $FW eth1 udp 1194 I haven''t had time to follow this thread closely so I don''t know if only one of those needs to be there (you only need it on the external interface(s) that handle(s) the VPN traffic). -Tom -- Tom Following your logic above would be: 2:11 $FW eth0 udp 1194 3:11 $FW tun1 udp 1194 tun1 is the third interface listed in tcdevices Thank you Mike ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Mike wrote:> Tom > Following your logic above would be: > 2:11 $FW eth0 udp 1194 > 3:11 $FW tun1 udp 1194> tun1 is the third interface listed in tcdevicesMike, Please don''t post your reply below the "--". Most mailers delete that part of the post when replying. Your rule for tun1 is silly; no udp 1194 traffic will go THROUGH the tunnel. That protocol/port is used to carry the tunneled traffic itself. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
Mike wrote:> Tom > Following your logic above would be: > 2:11 $FW eth0 udp 1194 > 3:11 $FW tun1 udp 1194> tun1 is the third interface listed in tcdevicesMike, Please don''t post your reply below the "--". Most mailers delete that part of the post when replying. Your rule for tun1 is silly; no udp 1194 traffic will go THROUGH the tunnel. That protocol/port is used to carry the tunneled traffic itself. -Tom Then would this make sense: <snip from mangle> Chain tcpost (1 references) pkts bytes target prot opt in out source destination 436 20588 CLASSIFY all -- * * 10.19.227.18 0.0.0.0/0 CLASSIFY set 3:11 284 34640 CLASSIFY udp -- * eth1 0.0.0.0/0 0.0.0.0/0 multiport dports 7788 CLASSIFY set 2:11 3 258 CLASSIFY all -- * * 10.19.227.4 10.194.79.55 CLASSIFY set 3:11 3 258 CLASSIFY all -- * * 10.19.227.4 10.194.79.55 CLASSIFY set 3:11 0 0 CLASSIFY all -- * * 10.192.139.240 0.0.0.0/0 CLASSIFY set 2:11 3:11 10.19.227.18 0.0.0.0/0 ALL -----any thing destin from voip box to anywhere through tun1 gets a packet mark of ''1'' 2:11 $FW eth1 udp 7788 ---note not 1194 #INTERFACE IN-BANDWITH OUT-BANDWIDTH eth0 3000kbit 1152kbit eth1 768kbit 768kbit tun1 768kbit 768kbit tun2 768kbit 768kbit #INTERFACE MARK RATE CEIL PRIORITY OPTIONS eth0 1 full full 1 eth0 2 full/4 full 2 eth0 3 full/4 full 3 default eth0 4 full/8 full*8/10 4 # # eth1 1 full full 1 eth1 2 full/4 full 2 eth1 3 full/4 full 3 default eth1 4 full/8 full*8/10 4 ## # tun1 1 full full 1 tun1 2 full/4 full 2 default tun1 3 full/8 full*8/10 3 # tun2 1 full full 1 tun2 2 full/4 full 2 default tun2 3 full/8 full*8/10 3 #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It''s the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace