Having a little trouble grasping the tos byte in these phone systems I am
working with.
First I will explain what I think this works like. Tos and dscp are
different in that dscp was implemented in favor of the old tos.
The first 6 bits in the Tos header with the last two for ECN.
DSCP is the most significant 6 bits of the 8 bit TOS header.
802.1p priority is the upper most significant 3 bits that are called
the CoS bits In all my layer two devices. AC3 (Voice) popular
setting is dec 46 binary 101110 hex 2E. bin 101110 in dscp.
Which equates to dec 184 hex 0xB8 bin 10111000 in Tos presidence.
This phone system uses the old tos bits. However you can only make
entries as follows with a admin phone. And you hit one key 0~7 and save.
0 = Normal Service (default)
1 = Maximize Reliability
2 = Maximize Throughput
3 = Maximize Reliability & Throughput
4 = Minimize Delay
5 = Minimize Delay & Maximize Reliability
6 = Minimize Delay & Maximize Throughput
7 = Minimize Delay & Maximize Reliability & Maximize Throughput
Here is a binary sniff of one frame with this tos bit set
Differentiated Services Field: 0x1c (DSCP 0x07: Unknown DSCP; ECN: 0x00
0001 11.. = Differentiated Services Codepoint: Unknown (0x07)
and a ascii dump as you can see one phone system is set to 5 and the other 7
21:36:14.847073 In ethertype IPv4 (0x0800), length 96: (tos 0x1c, ttl 253, id
60531, offset 0, flags [DF], proto UDP (17), length 80) 10.19.227.18.12582 >
10.143.99.241.16100: [udp sum ok] UDP, length 52
21:36:14.858575 Out ethertype IPv4 (0x0800), length 96: (tos 0x14, ttl 253, id
26376, offset 0, flags [DF], proto UDP (17), length 80) 10.143.99.241.32085 >
10.19.227.18.16100: [udp sum ok] UDP, length 52
2
I am currently handling the qos with these two rules
as I had learned in the past here on the list.
both shorewall boxes have this:
2:11 10.143.99.241 10.19.227.18 ALL
2:11 $FW eth1 udp 7788
eth0 1008kbit 604kbit
eth1 3536kbit 1024kbit
tun0 3536kbit 1024kbit
The above has a side affect of all traffic through the tunnel gets
class one which is not desired. Just want h323 ulaw in class 1
In some shorewall examples I have seen entries in tcclasses like this
tos=0x68/0xfc,tos=0xb8/0xfc Which is the ef class in diffservices.
In the options field. I tried converting this to
tos=0x70/0xfc,tos=0x1c/0xfc which 70 is 1c in dscp.
One thing I dont understand is the 0xfc a mask? This entry is
confusing.
I also tried taking the mask off? and just entering 0x70 then
0x1c. I noticed after that when you list filters. you get this
filter parent 2: protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0
flowid 2:11 (rule hit 89 success 0)
dsfield 0x70 (success 0 ) ............the match changes to dsfield without
0xfc.
I then concluded that I am quessing.
I know how to accomplish this with ports, but some of these ports have wide
ranges (in the thousands) using udp and would take quite a few tcrules entries.
IPKTS Unicast, IPKTS Multicast are part of the mix.
question1: Is there a way to do this with tos or packet/connection marking more
efficently.
Q2: Am I way off track here with trying to use tos?
Can anyone help.
Thanks
Mike
------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
Mike Lander wrote:> Having a little trouble grasping the tos byte in these phone systems I am > working with. > First I will explain what I think this works like. Tos and dscp are > different in that dscp was implemented in favor of the old tos. > > The first 6 bits in the Tos header with the last two for ECN. > DSCP is the most significant 6 bits of the 8 bit TOS header. > 802.1p priority is the upper most significant 3 bits that are called > the CoS bits In all my layer two devices. AC3 (Voice) popular > setting is dec 46 binary 101110 hex 2E. bin 101110 in dscp. > Which equates to dec 184 hex 0xB8 bin 10111000 in Tos presidence. > This phone system uses the old tos bits. However you can only make > entries as follows with a admin phone. And you hit one key 0~7 and save. > 0 = Normal Service (default) > 1 = Maximize Reliability > 2 = Maximize Throughput > 3 = Maximize Reliability & Throughput > 4 = Minimize Delay > 5 = Minimize Delay & Maximize Reliability > 6 = Minimize Delay & Maximize Throughput > 7 = Minimize Delay & Maximize Reliability & Maximize ThroughputThat is a confusing enumeration because it has no obvious relationship to the actual values of the 8-bit TOS field. The defined values are: 0x10 = Minimize-Delay 0x08 = Maximize-Throughput 0x04 = Maximize-Reliability 0x02 = Minimize-Cost 0x00 = Normal-Service So Minimize Delay & Maximize Reliability would be 0x10 + 0x40 = 0x14.> > Here is a binary sniff of one frame with this tos bit set > > Differentiated Services Field: 0x1c (DSCP 0x07: Unknown DSCP; ECN: 0x00 > 0001 11.. = Differentiated Services Codepoint: Unknown (0x07) > > and a ascii dump as you can see one phone system is set to 5 and the other 7 > > 21:36:14.847073 In ethertype IPv4 (0x0800), length 96: (tos 0x1c, ttl 253, id 60531, offset 0, flags [DF], proto UDP (17), length 80) 10.19.227.18.12582 > 10.143.99.241.16100: [udp sum ok] UDP, length 520x1c = Minimize-Delay + Maximize=Throughput + Maximize-Reliability> 21:36:14.858575 Out ethertype IPv4 (0x0800), length 96: (tos 0x14, ttl 253, id 26376, offset 0, flags [DF], proto UDP (17), length 80) 10.143.99.241.32085 > 10.19.227.18.16100: [udp sum ok] UDP, length 52 > 2As above 0x14 = Minimize-Delay & Maximize-Reliability> > I am currently handling the qos with these two rules > as I had learned in the past here on the list. > both shorewall boxes have this: > 2:11 10.143.99.241 10.19.227.18 ALL > 2:11 $FW eth1 udp 7788 > > eth0 1008kbit 604kbit > eth1 3536kbit 1024kbit > tun0 3536kbit 1024kbit > > The above has a side affect of all traffic through the tunnel gets > class one which is not desired. Just want h323 ulaw in class 1 > In some shorewall examples I have seen entries in tcclasses like this > tos=0x68/0xfc,tos=0xb8/0xfc Which is the ef class in diffservices. > In the options field. I tried converting this to > tos=0x70/0xfc,tos=0x1c/0xfc which 70 is 1c in dscp.> One thing I dont understand is the 0xfc a mask? This entry is > confusing.From ''man tcclasses'': tos=0x<value>[/0x<mask>] (<mask> defaults to 0xff) This lets you define a classifier for the given <value>/<mask> combination of the IP packet´s TOS/Precedence/DiffSrv octet (aka the TOS byte). Please note that classifiers override all mark settings, so if you define a classifer for a class, all traffic having that mark will go in it regardless of any mark set on the packet by a firewall/mangle filter. Since Shorewall 3.4, *the man pages are an integral part of the Shorewall documentation*. Use them! The bottom line is that the tos= OPTION allows you to mask the entire 8-bit TOS field then compare the result with a constant value. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
> Mike Lander wrote: > > Having a little trouble grasping the tos byte in these phone systems I am > > working with. > > First I will explain what I think this works like. Tos and dscp are > > different in that dscp was implemented in favor of the old tos. > > > > The first 6 bits in the Tos header with the last two for ECN. > > DSCP is the most significant 6 bits of the 8 bit TOS header. > > 802.1p priority is the upper most significant 3 bits that are called > > the CoS bits In all my layer two devices. AC3 (Voice) popular > > setting is dec 46 binary 101110 hex 2E. bin 101110 in dscp. > > Which equates to dec 184 hex 0xB8 bin 10111000 in Tos presidence. > > This phone system uses the old tos bits. However you can only make > > entries as follows with a admin phone. And you hit one key 0~7 and save. > > 0 = Normal Service (default) > > 1 = Maximize Reliability > > 2 = Maximize Throughput > > 3 = Maximize Reliability & Throughput > > 4 = Minimize Delay > > 5 = Minimize Delay & Maximize Reliability > > 6 = Minimize Delay & Maximize Throughput > > 7 = Minimize Delay & Maximize Reliability & Maximize Throughput > > That is a confusing enumeration because it has no obvious relationship > to the actual values of the 8-bit TOS field. The defined values are: > > 0x10 = Minimize-Delay > 0x08 = Maximize-Throughput > 0x04 = Maximize-Reliability > 0x02 = Minimize-Cost > 0x00 = Normal-Service > > So Minimize Delay & Maximize Reliability would be 0x10 + 0x40 = 0x14. > > > > Here is a binary sniff of one frame with this tos bit set > > > > Differentiated Services Field: 0x1c (DSCP 0x07: Unknown DSCP; ECN: 0x00 > > 0001 11.. = Differentiated Services Codepoint: Unknown (0x07) > > > > and a ascii dump as you can see one phone system is set to 5 and the other 7 > > > > 21:36:14.847073 In ethertype IPv4 (0x0800), length 96: (tos 0x1c, ttl 253, id 60531, offset 0, flags [DF], proto UDP (17), length 80) 10.19.227.18.12582 > 10.143.99.241.16100: [udp sum ok] UDP, length 52 > > 0x1c = Minimize-Delay + Maximize=Throughput + Maximize-Reliability > > > 21:36:14.858575 Out ethertype IPv4 (0x0800), length 96: (tos 0x14, ttl 253, id 26376, offset 0, flags [DF], proto UDP (17), length 80) 10.143.99.241.32085 > 10.19.227.18.16100: [udp sum ok] UDP, length 52 > > 2 > > As above 0x14 = Minimize-Delay & Maximize-Reliability > > > > > I am currently handling the qos with these two rules > > as I had learned in the past here on the list. > > both shorewall boxes have this: > > 2:11 10.143.99.241 10.19.227.18 ALL > > 2:11 $FW eth1 udp 7788 > > > > eth0 1008kbit 604kbit > > eth1 3536kbit 1024kbit > > tun0 3536kbit 1024kbit > > > > The above has a side affect of all traffic through the tunnel gets > > class one which is not desired. Just want h323 ulaw in class 1 > > In some shorewall examples I have seen entries in tcclasses like this > > tos=0x68/0xfc,tos=0xb8/0xfc Which is the ef class in diffservices. > > In the options field. I tried converting this to > > tos=0x70/0xfc,tos=0x1c/0xfc which 70 is 1c in dscp. > > > > > One thing I dont understand is the 0xfc a mask? This entry is > > confusing. > > From ''man tcclasses'': > > tos=0x<value>[/0x<mask>] (<mask> defaults to 0xff) > This lets you define a classifier for the given <value>/<mask> > combination of the IP packet´s TOS/Precedence/DiffSrv octet > (aka the TOS byte). Please note that classifiers override all > mark settings, so if you define a classifer for a class, all > traffic having that mark will go in it regardless of any mark > set on the packet by a firewall/mangle filter. > > Since Shorewall 3.4, *the man pages are an integral part of the > Shorewall documentation*. Use them! > > The bottom line is that the tos= OPTION allows you to mask the entire > 8-bit TOS field then compare the result with a constant value. > > -Tom> Mike Lander wrote: > > Having a little trouble grasping the tos byte in these phone systems I am > > working with. > > First I will explain what I think this works like. Tos and dscp are > > different in that dscp was implemented in favor of the old tos. > > > > The first 6 bits in the Tos header with the last two for ECN. > > DSCP is the most significant 6 bits of the 8 bit TOS header. > > 802.1p priority is the upper most significant 3 bits that are called > > the CoS bits In all my layer two devices. AC3 (Voice) popular > > setting is dec 46 binary 101110 hex 2E. bin 101110 in dscp. > > Which equates to dec 184 hex 0xB8 bin 10111000 in Tos presidence. > > This phone system uses the old tos bits. However you can only make > > entries as follows with a admin phone. And you hit one key 0~7 and save. > > 0 = Normal Service (default) > > 1 = Maximize Reliability > > 2 = Maximize Throughput > > 3 = Maximize Reliability & Throughput > > 4 = Minimize Delay > > 5 = Minimize Delay & Maximize Reliability > > 6 = Minimize Delay & Maximize Throughput > > 7 = Minimize Delay & Maximize Reliability & Maximize Throughput > > That is a confusing enumeration because it has no obvious relationship > to the actual values of the 8-bit TOS field. The defined values are: > > 0x10 = Minimize-Delay > 0x08 = Maximize-Throughput > 0x04 = Maximize-Reliability > 0x02 = Minimize-Cost > 0x00 = Normal-Service > > So Minimize Delay & Maximize Reliability would be 0x10 + 0x40 = 0x14. > > > > Here is a binary sniff of one frame with this tos bit set > > > > Differentiated Services Field: 0x1c (DSCP 0x07: Unknown DSCP; ECN: 0x00 > > 0001 11.. = Differentiated Services Codepoint: Unknown (0x07) > > > > and a ascii dump as you can see one phone system is set to 5 and the other 7 > > > > 21:36:14.847073 In ethertype IPv4 (0x0800), length 96: (tos 0x1c, ttl 253, id 60531, offset 0, flags [DF], proto UDP (17), length 80) 10.19.227.18.12582 > 10.143.99.241.16100: [udp sum ok] UDP, length 52 > > 0x1c = Minimize-Delay + Maximize=Throughput + Maximize-Reliability > > > 21:36:14.858575 Out ethertype IPv4 (0x0800), length 96: (tos 0x14, ttl 253, id 26376, offset 0, flags [DF], proto UDP (17), length 80) 10.143.99.241.32085 > 10.19.227.18.16100: [udp sum ok] UDP, length 52 > > 2 > > As above 0x14 = Minimize-Delay & Maximize-Reliability > > > > > I am currently handling the qos with these two rules > > as I had learned in the past here on the list. > > both shorewall boxes have this: > > 2:11 10.143.99.241 10.19.227.18 ALL > > 2:11 $FW eth1 udp 7788 > > > > eth0 1008kbit 604kbit > > eth1 3536kbit 1024kbit > > tun0 3536kbit 1024kbit > > > > The above has a side affect of all traffic through the tunnel gets > > class one which is not desired. Just want h323 ulaw in class 1 > > In some shorewall examples I have seen entries in tcclasses like this > > tos=0x68/0xfc,tos=0xb8/0xfc Which is the ef class in diffservices. > > In the options field. I tried converting this to > > tos=0x70/0xfc,tos=0x1c/0xfc which 70 is 1c in dscp. > > > > > One thing I dont understand is the 0xfc a mask? This entry is > > confusing. > > From ''man tcclasses'': > > tos=0x<value>[/0x<mask>] (<mask> defaults to 0xff) > This lets you define a classifier for the given <value>/<mask> > combination of the IP packet´s TOS/Precedence/DiffSrv octet > (aka the TOS byte). Please note that classifiers override all > mark settings, so if you define a classifer for a class, all > traffic having that mark will go in it regardless of any mark > set on the packet by a firewall/mangle filter. > > Since Shorewall 3.4, *the man pages are an integral part of the > Shorewall documentation*. Use them! > > The bottom line is that the tos= OPTION allows you to mask the entire > 8-bit TOS field then compare the result with a constant value. > > -TomI read the man pages, so fc=11111100 So This and''s the tos byte, which mask the ecn bits? 14 010100 and fc 11111100 =010100 or really to to 01010000? Here is show filters on this config below. note that the firewall on the other end is set to 0xfc af32(different for testing purposes) This firewall is 0x14 or the DSCP class af22. Both these firewalls are openvpn through eth1 with passtoss set. Firewall A eth0 1 full full 1 eth0 2 full/2 full 2 tcp-ack,tos-minimize-delay eth0 3 full/4 full 3 default eth0 4 full/8 full*8/10 4 # eth1 1 full full 1 tos=0x14/0xfc eth1 2 full/2 full 2 tcp-ack,tos-minimize-delay eth1 3 full/4 full 3 default eth1 4 full/8 full*8/10 4 # tun0 1 full full 1 tun0 2 full/4 full 2 tcp-ack,tos-minimize-delay tun0 3 full/4 full 3 default tun0 4 full/8 full*8/10 4 # Here is a show classifiers result on the firewallA that sends a 14 tos. Firewall A filter parent 2: protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 2:11 (rule hit 1080 success 46) match 00140000/00fc0000 at 0 (success 46 ) Here is a show classifiers result on the firewallB that sends a 1c tos. However the firewall on the this end with tos @ 1c classifier has no hit success. Not sure why? Firewall B filter parent 2: protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 2:11 (rule hit 649 success 0) match 001c0000/00fc0000 at 0 (success 0 ) Firewall B eth0 1 full full 1 eth0 2 full/2 full 2 tcp-ack,tos-minimize-delay eth0 3 full/4 full 3 default eth0 4 full/8 full*8/10 4 # eth1 1 full full 1 tos=0x1c/0xfc eth1 2 full/2 full 2 tcp-ack,tos-minimize-delay eth1 3 full/4 full 3 default eth1 4 full/8 full*8/10 4 # tun0 1 full full 1 tun0 2 full/4 full 2 tcp-ack,tos-minimize-delay tun0 3 full/4 full 3 default tun0 4 full/8 full*8/10 4 Mike ------------------------------------------------------------------------------ Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
Mike Lander wrote:> I read the man pages, so fc=11111100 So This and''s the tos byte, > which mask the ecn bits? 14 010100 and fc 11111100 =010100 or > really to to 01010000?0x14 & 0xfc = 0x14 = 00010100> Here is show filters on this config below. note that the firewall on the other > end is set to 0xfc af32(different for testing purposes) This firewall is 0x14 or the > DSCP class af22. Both these firewalls are openvpn through eth1 with passtoss set.So do you know for certain that OpenVPN transfers the TOS byte exactly from the encapsulated packet to the encapsulating UDP packet? I don''t, although I would suspect that it does.> > Firewall A > > eth0 1 full full 1 > eth0 2 full/2 full 2 tcp-ack,tos-minimize-delay > eth0 3 full/4 full 3 default > eth0 4 full/8 full*8/10 4 > # > eth1 1 full full 1 tos=0x14/0xfc > eth1 2 full/2 full 2 tcp-ack,tos-minimize-delay > eth1 3 full/4 full 3 default > eth1 4 full/8 full*8/10 4 > # > tun0 1 full full 1 > tun0 2 full/4 full 2 tcp-ack,tos-minimize-delay > tun0 3 full/4 full 3 default > tun0 4 full/8 full*8/10 4Why aren''t you shaping the VOIP traffic on tun0 also?> # > Here is a show classifiers result on the firewallA that sends a 14 tos. > > Firewall A > filter parent 2: protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 2:11 (rule hit 1080 success 46) > match 00140000/00fc0000 at 0 (success 46 ) > > Here is a show classifiers result on the firewallB that sends a 1c tos. > > However the firewall on the this end with tos @ 1c classifier has no hit success. > Not sure why?Me neither.> > Firewall B > filter parent 2: protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 2:11 (rule hit 649 success 0) > match 001c0000/00fc0000 at 0 (success 0 ) > > Firewall B > > eth0 1 full full 1 > eth0 2 full/2 full 2 tcp-ack,tos-minimize-delay > eth0 3 full/4 full 3 default > eth0 4 full/8 full*8/10 4 > # > eth1 1 full full 1 tos=0x1c/0xfc > eth1 2 full/2 full 2 tcp-ack,tos-minimize-delay > eth1 3 full/4 full 3 default > eth1 4 full/8 full*8/10 4 > # > tun0 1 full full 1 > tun0 2 full/4 full 2 tcp-ack,tos-minimize-delay > tun0 3 full/4 full 3 default > tun0 4 full/8 full*8/10 4Again, I assume that you are looking at the traffic on eth1? -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
> Mike Lander wrote: > > > I read the man pages, so fc=11111100 So This and''s the tos byte, > > which mask the ecn bits? 14 010100 and fc 11111100 =010100 or > > really to to 01010000? > > 0x14 & 0xfc = 0x14 = 00010100 > > > Here is show filters on this config below. note that the firewall on the other > > end is set to 0xfc af32(different for testing purposes) This firewall is 0x14 or the > > DSCP class af22. Both these firewalls are openvpn through eth1 with passtoss set. > > > > > Firewall A > > > > eth0 1 full full 1 > > eth0 2 full/2 full 2 tcp-ack,tos-minimize-delay > > eth0 3 full/4 full 3 default > > eth0 4 full/8 full*8/10 4 > > # > > eth1 1 full full 1 tos=0x14/0xfc > > eth1 2 full/2 full 2 tcp-ack,tos-minimize-delay > > eth1 3 full/4 full 3 default > > eth1 4 full/8 full*8/10 4 > > # > > tun0 1 full full 1 > > tun0 2 full/4 full 2 tcp-ack,tos-minimize-delay > > tun0 3 full/4 full 3 default > > tun0 4 full/8 full*8/10 4 > > Why aren''t you shaping the VOIP traffic on tun0 also?I was reading a post you helped me with a long time ago that you said it was already encrypted and would not work. I am wrong sounds like. I Will try that. >> > # > > Here is a show classifiers result on the firewallA that sends a 14 tos. > > > > Firewall A > > filter parent 2: protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 2:11 (rule hit 1080 success 46) > > match 00140000/00fc0000 at 0 (success 46 ) > > > > Here is a show classifiers result on the firewallB that sends a 1c tos. > > > > However the firewall on the this end with tos @ 1c classifier has no hit success. > > Not sure why? > > Me neither. > > > > > Firewall B > > filter parent 2: protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 2:11 (rule hit 649 success 0) > > match 001c0000/00fc0000 at 0 (success 0 ) > > > > Firewall B > > > > eth0 1 full full 1 > > eth0 2 full/2 full 2 tcp-ack,tos-minimize-delay > > eth0 3 full/4 full 3 default > > eth0 4 full/8 full*8/10 4 > > # > > eth1 1 full full 1 tos=0x1c/0xfc > > eth1 2 full/2 full 2 tcp-ack,tos-minimize-delay > > eth1 3 full/4 full 3 default > > eth1 4 full/8 full*8/10 4 > > # > > tun0 1 full full 1 > > tun0 2 full/4 full 2 tcp-ack,tos-minimize-delay > > tun0 3 full/4 full 3 default > > tun0 4 full/8 full*8/10 4 > > Again, I assume that you are looking at the traffic on eth1? > > -TomYes> So do you know for certain that OpenVPN transfers the TOS byte exactly > from the encapsulated packet to the encapsulating UDP packet? I don''t, > although I would suspect that it does.Yes here is a snif of the firewall that sends a tos 14 to the 1c firewall I am on the 10.143.99.241 at this dump looking at the local interface eth2 Chehalis:~ # tcpdump -nevvi eth2 host 10.19.227.18 tcpdump: listening on eth2, link-type EN10MB (Ethernet), capture size 96 bytes 14:04:37.431828 00:40:5a:29:a8:4f > 00:0b:cd:50:14:b4, ethertype IPv4 (0x0800), length 60: (tos 0x14, ttl 254, id 60413, offset 0, flags [DF], proto TCP (6), length 44) 10.143.99.241.8585 > 10.19.227.18.1720: S, cksum 0x424a (correct), 577466648:577466648(0) win 16000 <mss 1446> 14:04:37.475506 00:0b:cd:50:14:b4 > 00:40:5a:29:a8:4f, ethertype IPv4 (0x0800), length 58: (tos 0x1c, ttl 252, id 25190, offset 0, flags [DF], proto TCP (6), length 44) 10.19.227.18.1720 > 10.143.99.241.8585: S, cksum 0x5e84 (correct), 3753903173:3753903173(0) ack 577466649 win 16000 <mss 1365> 14:04:37.475799 00:40:5a:29:a8:4f > 00:0b:cd:50:14:b4, ethertype IPv4 (0x0800), length 60: (tos 0x14, ttl 254, id 60414, offset 0, flags [DF], proto TCP (6), length 40) 10.143.99.241.8585 > 10.19.227.18.1720: ., cksum 0x75e2 (correct),>On firewall that uses the 1c tos in the shorewall docs it states that traffic falls into these classes regardless. Is that true? Also both boxes are at Chehalis:~ # shorewall version 4.2.9 But the box that uses the 1c tos is suse 10.3 the box at tos 14 is suse 11.1 could this be that the earlier suse has modules lacking support? Mike ------------------------------------------------------------------------------ Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
Mike Lander wrote:> > Yes here is a snif of the firewall that sends a tos 14 to the 1c > firewall I am on the 10.143.99.241 at this dump looking at the local > interface eth2 > > Chehalis:~ # tcpdump -nevvi eth2 host 10.19.227.18 tcpdump: listening > on eth2, link-type EN10MB (Ethernet), capture size 96 bytes > 14:04:37.431828 00:40:5a:29:a8:4f > 00:0b:cd:50:14:b4, ethertype IPv4 > (0x0800), length 60: (tos 0x14, ttl 254, id 60413, offset 0, flags > [DF], proto TCP (6), length 44) 10.143.99.241.8585 > > 10.19.227.18.1720: S, cksum 0x424a (correct), 577466648:577466648(0) > win 16000 <mss 1446> 14:04:37.475506 00:0b:cd:50:14:b4 > > 00:40:5a:29:a8:4f, ethertype IPv4 (0x0800), length 58: (tos 0x1c, ttl > 252, id 25190, offset 0, flags [DF], proto TCP (6), length 44) > 10.19.227.18.1720 > 10.143.99.241.8585: S, cksum 0x5e84 (correct), > 3753903173:3753903173(0) ack 577466649 win 16000 <mss 1365> > 14:04:37.475799 00:40:5a:29:a8:4f > 00:0b:cd:50:14:b4, ethertype IPv4 > (0x0800), length 60: (tos 0x14, ttl 254, id 60414, offset 0, flags > [DF], proto TCP (6), length 40) 10.143.99.241.8585 > > 10.19.227.18.1720: ., cksum 0x75e2 (correct),Just for completeness -- We''ve spent most of our Saturday looking at shaping of UDP packets on eth1 and now you show us a packet trace of TCP packets on eth2... How is that possibly relevant? -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
> > Mike Lander wrote: > > > > > Yes here is a snif of the firewall that sends a tos 14 to the 1c > > firewall I am on the 10.143.99.241 at this dump looking at the local > > interface eth2 > > > > Chehalis:~ # tcpdump -nevvi eth2 host 10.19.227.18 tcpdump: listening > > on eth2, link-type EN10MB (Ethernet), capture size 96 bytes > > 14:04:37.431828 00:40:5a:29:a8:4f > 00:0b:cd:50:14:b4, ethertype IPv4 > > (0x0800), length 60: (tos 0x14, ttl 254, id 60413, offset 0, flags > > [DF], proto TCP (6), length 44) 10.143.99.241.8585 > > > 10.19.227.18.1720: S, cksum 0x424a (correct), 577466648:577466648(0) > > win 16000 <mss 1446> 14:04:37.475506 00:0b:cd:50:14:b4 > > > 00:40:5a:29:a8:4f, ethertype IPv4 (0x0800), length 58: (tos 0x1c, ttl > > 252, id 25190, offset 0, flags [DF], proto TCP (6), length 44) > > 10.19.227.18.1720 > 10.143.99.241.8585: S, cksum 0x5e84 (correct), > > 3753903173:3753903173(0) ack 577466649 win 16000 <mss 1365> > > 14:04:37.475799 00:40:5a:29:a8:4f > 00:0b:cd:50:14:b4, ethertype IPv4 > > (0x0800), length 60: (tos 0x14, ttl 254, id 60414, offset 0, flags > > [DF], proto TCP (6), length 40) 10.143.99.241.8585 > > > 10.19.227.18.1720: ., cksum 0x75e2 (correct), > > > Just for completeness -- We''ve spent most of our Saturday looking at > shaping of UDP packets on eth1 and now you show us a packet trace of TCP > packets on eth2... > > How is that possibly relevant? > > -TomI was trying to get you a quick reply. Mothership Firewall 10.19.227.18 proprietary voip card did all the talking for tos on the lan eth0 ISP1 eth1 ISP2 eth2 DMZ proxyarped mail and webserver eth3 loc tun0 vpn1 tun1 vpn2 tun2 vpn3 >>> this is the tun we worked on A also ipsec is on eth0 on both boxes to Las vegus The firewall I gave you the sniff on B no dmz on this one 10.143.99.241 proprietary voip card did all the talking for tos on the lan eth0 ISP1 eth1 ISP2 eth2 lan tun0 >>> this is the tun we worked on B ipsec When I did that sniff I had a second thought of sniffing tun0 but to me it made more sense to sniff eth2 if I had sniffed eth1 I would of had to use FQ addresses correct? By the time it reaches eth1 its encyrpted right? How would you have expected to see the sniff through tun0? Mike ------------------------------------------------------------------------------ Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
Mike Lander wrote:>> Mike Lander wrote: >> >>> Yes here is a snif of the firewall that sends a tos 14 to the 1c >>> firewall I am on the 10.143.99.241 at this dump looking at the local >>> interface eth2 >>> >>> Chehalis:~ # tcpdump -nevvi eth2 host 10.19.227.18 tcpdump: listening >>> on eth2, link-type EN10MB (Ethernet), capture size 96 bytes >>> 14:04:37.431828 00:40:5a:29:a8:4f > 00:0b:cd:50:14:b4, ethertype IPv4 >>> (0x0800), length 60: (tos 0x14, ttl 254, id 60413, offset 0, flags >>> [DF], proto TCP (6), length 44) 10.143.99.241.8585 > >>> 10.19.227.18.1720: S, cksum 0x424a (correct), 577466648:577466648(0) >>> win 16000 <mss 1446> 14:04:37.475506 00:0b:cd:50:14:b4 > >>> 00:40:5a:29:a8:4f, ethertype IPv4 (0x0800), length 58: (tos 0x1c, ttl >>> 252, id 25190, offset 0, flags [DF], proto TCP (6), length 44) >>> 10.19.227.18.1720 > 10.143.99.241.8585: S, cksum 0x5e84 (correct), >>> 3753903173:3753903173(0) ack 577466649 win 16000 <mss 1365> >>> 14:04:37.475799 00:40:5a:29:a8:4f > 00:0b:cd:50:14:b4, ethertype IPv4 >>> (0x0800), length 60: (tos 0x14, ttl 254, id 60414, offset 0, flags >>> [DF], proto TCP (6), length 40) 10.143.99.241.8585 > >>> 10.19.227.18.1720: ., cksum 0x75e2 (correct), >> >> Just for completeness -- We''ve spent most of our Saturday looking at >> shaping of UDP packets on eth1 and now you show us a packet trace of TCP >> packets on eth2... >> >> How is that possibly relevant? >> >> -Tom > I was trying to get you a quick reply. > > Mothership Firewall > 10.19.227.18 proprietary voip card did all the > talking for tos on the lan > eth0 ISP1 > eth1 ISP2 > eth2 DMZ proxyarped mail and webserver > eth3 loc > tun0 vpn1 > tun1 vpn2 > tun2 vpn3 >>> this is the tun we worked on A > > also ipsec is on eth0 on both boxes to Las vegus > > The firewall I gave you the sniff on B > no dmz on this one > 10.143.99.241 proprietary voip card did all the > talking for tos on the lan > eth0 ISP1 > eth1 ISP2 > eth2 lan > tun0 >>> this is the tun we worked on B > ipsec > > When I did that sniff I had a second thought of sniffing tun0 > but to me it made more sense to sniff eth2 if I had sniffed eth1 > I would of had to use FQ addresses correct? By the time it reaches > eth1 its encyrpted right? How would you have expected to see the > sniff through tun0?I give up. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
> > Mike Lander wrote: > > > > > Yes here is a snif of the firewall that sends a tos 14 to the 1c > > firewall I am on the 10.143.99.241 at this dump looking at the local > > interface eth2 > > > > Chehalis:~ # tcpdump -nevvi eth2 host 10.19.227.18 tcpdump: listening > > on eth2, link-type EN10MB (Ethernet), capture size 96 bytes > > 14:04:37.431828 00:40:5a:29:a8:4f > 00:0b:cd:50:14:b4, ethertype IPv4 > > (0x0800), length 60: (tos 0x14, ttl 254, id 60413, offset 0, flags > > [DF], proto TCP (6), length 44) 10.143.99.241.8585 > > > 10.19.227.18.1720: S, cksum 0x424a (correct), 577466648:577466648(0) > > win 16000 <mss 1446> 14:04:37.475506 00:0b:cd:50:14:b4 > > > 00:40:5a:29:a8:4f, ethertype IPv4 (0x0800), length 58: (tos 0x1c, ttl > > 252, id 25190, offset 0, flags [DF], proto TCP (6), length 44) > > 10.19.227.18.1720 > 10.143.99.241.8585: S, cksum 0x5e84 (correct), > > 3753903173:3753903173(0) ack 577466649 win 16000 <mss 1365> > > 14:04:37.475799 00:40:5a:29:a8:4f > 00:0b:cd:50:14:b4, ethertype IPv4 > > (0x0800), length 60: (tos 0x14, ttl 254, id 60414, offset 0, flags > > [DF], proto TCP (6), length 40) 10.143.99.241.8585 > > > 10.19.227.18.1720: ., cksum 0x75e2 (correct), > > > Just for completeness -- We''ve spent most of our Saturday looking at > shaping of UDP packets on eth1 and now you show us a packet trace of TCP > packets on eth2... > > How is that possibly relevant? > > -TomTom These firewalls are 10 years old. At least some the locations or seats are. I first put in the one I am calling the mothership 10 years ago with seawall on it. This has grown so much over the years its very complex now. The main location feeds four other geographic locations. A small amount feed others in all in just this business there are 5 shorewall boxes. Also at layer2 two of these locations feed 5ghz wireless bridges to two other buildings. Not to meantion all of these boxes connect to vegus point to point with ipsec. You have helped me over the years to build a solid firewall foundation. In fact I was complimented by Red Flag of Washington that this place was secure recently. I am not deserving all of this credit as shorewall list has helped more so over the years. I did not want to overwhelm this list with the whole config, however if I could be of any help you are due from me. I have great bandwidth and servers as I have mentioned before. I would like to build a website of this config we worked on today. I am sure it would be in the higher catagories of shorewalls capability. And maybe help others as others have helped me. However I am sure that there are bigger and better out there because there are no speed limits with shorewall. If you guys ever need stuff let me know on my personal email as I always monitor that closly. Mike ------------------------------------------------------------------------------ Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
> > Mike Lander wrote: > >> Mike Lander wrote: > >> > >>> Yes here is a snif of the firewall that sends a tos 14 to the 1c > >>> firewall I am on the 10.143.99.241 at this dump looking at the local > >>> interface eth2 > >>> > >>> Chehalis:~ # tcpdump -nevvi eth2 host 10.19.227.18 tcpdump: listening > >>> on eth2, link-type EN10MB (Ethernet), capture size 96 bytes > >>> 14:04:37.431828 00:40:5a:29:a8:4f > 00:0b:cd:50:14:b4, ethertype IPv4 > >>> (0x0800), length 60: (tos 0x14, ttl 254, id 60413, offset 0, flags > >>> [DF], proto TCP (6), length 44) 10.143.99.241.8585 > > >>> 10.19.227.18.1720: S, cksum 0x424a (correct), 577466648:577466648(0) > >>> win 16000 <mss 1446> 14:04:37.475506 00:0b:cd:50:14:b4 > > >>> 00:40:5a:29:a8:4f, ethertype IPv4 (0x0800), length 58: (tos 0x1c, ttl > >>> 252, id 25190, offset 0, flags [DF], proto TCP (6), length 44) > >>> 10.19.227.18.1720 > 10.143.99.241.8585: S, cksum 0x5e84 (correct), > >>> 3753903173:3753903173(0) ack 577466649 win 16000 <mss 1365> > >>> 14:04:37.475799 00:40:5a:29:a8:4f > 00:0b:cd:50:14:b4, ethertype IPv4 > >>> (0x0800), length 60: (tos 0x14, ttl 254, id 60414, offset 0, flags > >>> [DF], proto TCP (6), length 40) 10.143.99.241.8585 > > >>> 10.19.227.18.1720: ., cksum 0x75e2 (correct), > >> > >> Just for completeness -- We''ve spent most of our Saturday looking at > >> shaping of UDP packets on eth1 and now you show us a packet trace of TCP > >> packets on eth2... > >> > >> How is that possibly relevant? > >> > >> -Tom > > I was trying to get you a quick reply. > > > > Mothership Firewall > > 10.19.227.18 proprietary voip card did all the > > talking for tos on the lan > > eth0 ISP1 > > eth1 ISP2 > > eth2 DMZ proxyarped mail and webserver > > eth3 loc > > tun0 vpn1 > > tun1 vpn2 > > tun2 vpn3 >>> this is the tun we worked on A > > > > also ipsec is on eth0 on both boxes to Las vegus > > > > The firewall I gave you the sniff on B > > no dmz on this one > > 10.143.99.241 proprietary voip card did all the > > talking for tos on the lan > > eth0 ISP1 > > eth1 ISP2 > > eth2 lan > > tun0 >>> this is the tun we worked on B > > ipsec > > > > When I did that sniff I had a second thought of sniffing tun0 > > but to me it made more sense to sniff eth2 if I had sniffed eth1 > > I would of had to use FQ addresses correct? By the time it reaches > > eth1 its encyrpted right? How would you have expected to see the > > sniff through tun0? > > I give up. > > -TomTom, This is where I raise my hand to ask maybe a dumb question. You ask me are you sure that the passtoss directive is making it through? My thought was to sniff as far downsteam as possible to prove to you and I that it was. eth2 on the sniffed firewall is after the outside interface on the firewall that is fixing to send the packet to the phone system on the next layer2 hop. Ie it has made through eth3,tun2,eth1 from the first firewall to eth1,tun0,eth2 on B To me it made sense to show that the tos bit had made it through all those hops before I lost control of the packet to the phone system. Please help me understand what I am not understanding here. It could be that I cant see the forest for trees I dont understand why you asked this. Did you want eth1 or tun0? To me the packet made it through encrytion and all interfaces before its handed to the phone system with tos "1c" still in place. Mike ------------------------------------------------------------------------------ Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
Mike Lander wrote:>> Mike Lander wrote: >> >>> Yes here is a snif of the firewall that sends a tos 14 to the 1c >>> firewall I am on the 10.143.99.241 at this dump looking at the local >>> interface eth2 >>> >>> Chehalis:~ # tcpdump -nevvi eth2 host 10.19.227.18 tcpdump: listening >>> on eth2, link-type EN10MB (Ethernet), capture size 96 bytes >>> 14:04:37.431828 00:40:5a:29:a8:4f > 00:0b:cd:50:14:b4, ethertype IPv4 >>> (0x0800), length 60: (tos 0x14, ttl 254, id 60413, offset 0, flags >>> [DF], proto TCP (6), length 44) 10.143.99.241.8585 > >>> 10.19.227.18.1720: S, cksum 0x424a (correct), 577466648:577466648(0) >>> win 16000 <mss 1446> 14:04:37.475506 00:0b:cd:50:14:b4 > >>> 00:40:5a:29:a8:4f, ethertype IPv4 (0x0800), length 58: (tos 0x1c, ttl >>> 252, id 25190, offset 0, flags [DF], proto TCP (6), length 44) >>> 10.19.227.18.1720 > 10.143.99.241.8585: S, cksum 0x5e84 (correct), >>> 3753903173:3753903173(0) ack 577466649 win 16000 <mss 1365> >>> 14:04:37.475799 00:40:5a:29:a8:4f > 00:0b:cd:50:14:b4, ethertype IPv4 >>> (0x0800), length 60: (tos 0x14, ttl 254, id 60414, offset 0, flags >>> [DF], proto TCP (6), length 40) 10.143.99.241.8585 > >>> 10.19.227.18.1720: ., cksum 0x75e2 (correct), >> >> Just for completeness -- We''ve spent most of our Saturday looking at >> shaping of UDP packets on eth1 and now you show us a packet trace of TCP >> packets on eth2... >> >> How is that possibly relevant? >> >> -Tom > > Tom > These firewalls are 10 years old. At least some the locations or seats > are. I first put in the one I am calling the mothership 10 years ago > with seawall on it. This has grown so much over the years its very > complex now. The main location feeds four other geographic locations. > A small amount feed others in all in just this business there are 5 > shorewall boxes. Also at layer2 two of these locations feed 5ghz > wireless bridges to two other buildings. Not to meantion all of these > boxes connect to vegus point to point with ipsec. You have helped me over > the years to build a solid firewall foundation. In fact I was complimented > by Red Flag of Washington that this place was secure recently. I am not > deserving all of this credit as shorewall list has helped more so over > the years. > > I did not want to overwhelm this list > with the whole config, however if I could be of any help you are due > from me. I have great bandwidth and servers as I have mentioned before. > I would like to build a website of this config we worked on today. I am > sure it would be in the higher catagories of shorewalls capability. > And maybe help others as others have helped me. > However I am sure that there are bigger and better out there because > there are no speed limits with shorewall. If you guys ever need stuff > let me know on my personal email as I always monitor that closly.Mike, Thanks -- I appreciate the offer. But that doesn''t change the fact that I''ve spent most of my Father''s Day Saturday on your problem. I''m going to try to take tomorrow off from Shorewall; I have HP work that I need to catch up on. So if your problem still isn''t solved then please do us both a favor -- reconfigure the phones that are using TOS 1c to use 14 like the other end and be done with it. Because I really don''t have any more time to spend on your issue. I will release the patch that I posted earlier as part of 4.2.11. That won''t be for another month; but if anyone needs it, it is available in the list archives. Regards, -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
Mike Lander wrote:>> Mike Lander wrote: >> >>> Yes here is a snif of the firewall that sends a tos 14 to the 1c >>> firewall I am on the 10.143.99.241 at this dump looking at the local >>> interface eth2 >>> >>> Chehalis:~ # tcpdump -nevvi eth2 host 10.19.227.18 tcpdump: >>> listening on eth2, link-type EN10MB (Ethernet), capture size 96 >>> bytes >>> 14:04:37.431828 00:40:5a:29:a8:4f > 00:0b:cd:50:14:b4, ethertype >>> IPv4 (0x0800), length 60: (tos 0x14, ttl 254, id 60413, offset 0, >>> flags [DF], proto TCP (6), length 44) 10.143.99.241.8585 > >>> 10.19.227.18.1720: S, cksum 0x424a (correct), 577466648:577466648(0) >>> win 16000 <mss 1446> 14:04:37.475506 00:0b:cd:50:14:b4 > >>> 00:40:5a:29:a8:4f, ethertype IPv4 (0x0800), length 58: (tos 0x1c, >>> ttl 252, id 25190, offset 0, flags [DF], proto TCP (6), length 44) >>> 10.19.227.18.1720 > 10.143.99.241.8585: S, cksum 0x5e84 (correct), >>> 3753903173:3753903173(0) ack 577466649 win 16000 <mss 1365> >>> 14:04:37.475799 00:40:5a:29:a8:4f > 00:0b:cd:50:14:b4, ethertype >>> IPv4 (0x0800), length 60: (tos 0x14, ttl 254, id 60414, offset 0, >>> flags [DF], proto TCP (6), length 40) 10.143.99.241.8585 > >>> 10.19.227.18.1720: ., cksum 0x75e2 (correct), >> >> Just for completeness -- We''ve spent most of our Saturday looking at >> shaping of UDP packets on eth1 and now you show us a packet trace of >> TCP packets on eth2... >> >> How is that possibly relevant? >> >> -TomIf I understood your configuration correctly, you were shaping on eth1 based on the TOS of the raw SIP packets. The only way that works is if OpenVPN transfers the TOS setting on the SIP packet to the Encryped Encapsulated SIP Packet. So you would need to look on your external interface (which I understood was eth1) to see of there are TOS = 14 (or 1c) UDP 1194 packets when you are talking on the phone. Does that make sense? Cheers, -Tom To complete this thread I have compiled a dump of the encrypted communication between the two phone boxes. Below is the result as you can see the tos byte has been preserved across the tunnel. One has the tos bit to 1c and the other 14. Also whats cool here is that my former voip rules Put all the traffic across this tunnel in class1 This dump is the encrypted outside interface eth1 This is me on the call or maybe the phone ringing. Chehalis:/var/log/squidGuard # tcpdump -nevvi eth1 18:44:11.708552 00:40:5a:29:a8:4f > 00:0b:cd:50:14:b4, ethertype IPv4 (0x0800), length 214: (tos 0x14, ttl 254, id 54218, offset 0, flags [DF], proto UDP (17), length 200) 10.143.99.241.3106 > 10.19.227.18.3134: [no cksum] UDP, length 172 18:44:11.719062 00:0b:cd:50:14:b4 > 00:40:5a:29:a8:4f, ethertype IPv4 (0x0800), length 214: (tos 0x1c, ttl 252, id 54642, offset 0, flags [DF], proto UDP (17), length 200) 10.19.227.18.3134 > 10.143.99.241.3106: [no cksum] UDP, length 172 18:44:11.719377 00:0b:cd:50:14:b4 > 00:40:5a:29:a8:4f, ethertype IPv4 (0x0800), length 54: (tos 0x1c, ttl 252, id 54643, offset 0, flags [DF], proto TCP (6), length 40) 10.19.227.18.1720 > 10.143.99.241.8650: ., cksum 0x382c (correct), 499:499(0) ack 469 win 16000 So you can shape the traffic with the tos bit COOL! Thank you Tom for the patch working great. Mike ------------------------------------------------------------------------------ Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
Mike Lander wrote:> Mike Lander wrote: >>> Mike Lander wrote: >>> >>>> Yes here is a snif of the firewall that sends a tos 14 to the 1c >>>> firewall I am on the 10.143.99.241 at this dump looking at the local >>>> interface eth2 >>>> >>>> Chehalis:~ # tcpdump -nevvi eth2 host 10.19.227.18 tcpdump: >>>> listening on eth2, link-type EN10MB (Ethernet), capture size 96 >>>> bytes >>>> 14:04:37.431828 00:40:5a:29:a8:4f > 00:0b:cd:50:14:b4, ethertype >>>> IPv4 (0x0800), length 60: (tos 0x14, ttl 254, id 60413, offset 0, >>>> flags [DF], proto TCP (6), length 44) 10.143.99.241.8585 > >>>> 10.19.227.18.1720: S, cksum 0x424a (correct), 577466648:577466648(0) >>>> win 16000 <mss 1446> 14:04:37.475506 00:0b:cd:50:14:b4 > >>>> 00:40:5a:29:a8:4f, ethertype IPv4 (0x0800), length 58: (tos 0x1c, >>>> ttl 252, id 25190, offset 0, flags [DF], proto TCP (6), length 44) >>>> 10.19.227.18.1720 > 10.143.99.241.8585: S, cksum 0x5e84 (correct), >>>> 3753903173:3753903173(0) ack 577466649 win 16000 <mss 1365> >>>> 14:04:37.475799 00:40:5a:29:a8:4f > 00:0b:cd:50:14:b4, ethertype >>>> IPv4 (0x0800), length 60: (tos 0x14, ttl 254, id 60414, offset 0, >>>> flags [DF], proto TCP (6), length 40) 10.143.99.241.8585 > >>>> 10.19.227.18.1720: ., cksum 0x75e2 (correct), >>> Just for completeness -- We''ve spent most of our Saturday looking at >>> shaping of UDP packets on eth1 and now you show us a packet trace of >>> TCP packets on eth2... >>> >>> How is that possibly relevant? >>> >>> -Tom > If I understood your configuration correctly, you were shaping on eth1 based > on the TOS of the raw SIP packets. The only way that works is if OpenVPN > transfers the TOS setting on the SIP packet to the Encryped Encapsulated SIP > Packet. > > So you would need to look on your external interface (which I understood was > eth1) to see of there are TOS = 14 (or 1c) UDP 1194 packets when you are > talking on the phone. > > Does that make sense? > > Cheers, > -Tom > > To complete this thread I have compiled a dump of the encrypted > communication between the two phone boxes. Below is the result > as you can see the tos byte has been preserved across the > tunnel. One has the tos bit to 1c and the other 14. > Also whats cool here is that my former voip rules > Put all the traffic across this tunnel in class1 > This dump is the encrypted outside interface eth1 > This is me on the call or maybe the phone ringing. > > Chehalis:/var/log/squidGuard # tcpdump -nevvi eth1 > > 18:44:11.708552 00:40:5a:29:a8:4f > 00:0b:cd:50:14:b4, ethertype IPv4 > (0x0800), length 214: (tos 0x14, ttl 254, id 54218, offset 0, flags [DF], > proto UDP (17), length 200) 10.143.99.241.3106 > 10.19.227.18.3134: [no > cksum] UDP, length 172 > 18:44:11.719062 00:0b:cd:50:14:b4 > 00:40:5a:29:a8:4f, ethertype IPv4 > (0x0800), length 214: (tos 0x1c, ttl 252, id 54642, offset 0, flags [DF], > proto UDP (17), length 200) 10.19.227.18.3134 > 10.143.99.241.3106: [no > cksum] UDP, length 172 > 18:44:11.719377 00:0b:cd:50:14:b4 > 00:40:5a:29:a8:4f, ethertype IPv4 > (0x0800), length 54: (tos 0x1c, ttl 252, id 54643, offset 0, flags [DF], > proto TCP (6), length 40) 10.19.227.18.1720 > 10.143.99.241.8650: ., cksum > 0x382c (correct), 499:499(0) ack 469 win 16000 > > So you can shape the traffic with the tos bit COOL! > > Thank you Tom for the patch working great.Thanks Mike, for completing this thread based on our private emails. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
Mike Lander wrote>> Mike Lander wrote:>> >>> Yes here is a snif of the firewall that sends a tos 14 to the 1c >>> firewall I am on the 10.143.99.241 at this dump looking at the local >>> interface eth2 >>> >>> Chehalis:~ # tcpdump -nevvi eth2 host 10.19.227.18 tcpdump: >>> listening on eth2, link-type EN10MB (Ethernet), capture size 96 >>> bytes >>> 14:04:37.431828 00:40:5a:29:a8:4f > 00:0b:cd:50:14:b4, ethertype >>> IPv4 (0x0800), length 60: (tos 0x14, ttl 254, id 60413, offset 0, >>> flags [DF], proto TCP (6), length 44) 10.143.99.241.8585 > >>> 10.19.227.18.1720: S, cksum 0x424a (correct), 577466648:577466648(0) >>> win 16000 <mss 1446> 14:04:37.475506 00:0b:cd:50:14:b4 > >>> 00:40:5a:29:a8:4f, ethertype IPv4 (0x0800), length 58: (tos 0x1c, >>> ttl 252, id 25190, offset 0, flags [DF], proto TCP (6), length 44) >>> 10.19.227.18.1720 > 10.143.99.241.8585: S, cksum 0x5e84 (correct), >>> 3753903173:3753903173(0) ack 577466649 win 16000 <mss 1365> >>> 14:04:37.475799 00:40:5a:29:a8:4f > 00:0b:cd:50:14:b4, ethertype >>> IPv4 (0x0800), length 60: (tos 0x14, ttl 254, id 60414, offset 0, >>> flags [DF], proto TCP (6), length 40) 10.143.99.241.8585 > >>> 10.19.227.18.1720: ., cksum 0x75e2 (correct), >> >> Just for completeness -- We''ve spent most of our Saturday looking at >> shaping of UDP packets on eth1 and now you show us a packet trace of >> TCP packets on eth2... >> >> How is that possibly relevant? >> >> -Tom > I was trying to get you a quick reply. > > Mothership Firewall > 10.19.227.18 proprietary voip card did all the talking for tos on the > lan eth0 ISP1 > eth1 ISP2 > eth2 DMZ proxyarped mail and webserver > eth3 loc > tun0 vpn1 > tun1 vpn2 > tun2 vpn3 >>> this is the tun we worked on A > > also ipsec is on eth0 on both boxes to Las vegus > > The firewall I gave you the sniff on B no dmz on this one > 10.143.99.241 proprietary voip card did all the talking for tos on > the lan eth0 ISP1 > eth1 ISP2 > eth2 lan > tun0 >>> this is the tun we worked on B > ipsec > > When I did that sniff I had a second thought of sniffing tun0 but to > me it made more sense to sniff eth2 if I had sniffed eth1 I would of > had to use FQ addresses correct? By the time it reaches > eth1 its encyrpted right? How would you have expected to see the sniff > through tun0?I give up. -Tom I hope this is not a problem to bring this up again but after reading Through this is the last paragraph I wrote before Tom gave up That whole paragraph seems silly. I understand a that outside interface "Eth1" in this firewall is doing the encryption here, and that it makes more sense To use that interface in testing this firewall. I really don''t even get Where I was coming from now that I am rested and read this. I had many Days into firewalls at this point and hardly any sleep. This came out great Though and I am happy with the way it turned out. That interface eth1, showed FQ Traffic on it and I was in a hurry. IF I had waited for a phone call or made A call I would have seen the traffic. The voip system was idle and I did not See any traffic. Then thought of sniffing the tun side of the interface. Instead I did the local which caused the confusion. Mike ------------------------------------------------------------------------------ Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org