Menu
▾
▴
openvpn-devel
|
From: Craig K. <cr...@pu...> - 2002-10-28 10:49:15
|
Hi there, I use QoS routing and it works great except over openvpn/tun device. Correct me if I am wrong but I think this is because the packets are encapsulated within a UDP packet with no regard to what the original packets TOS field was, so once it reaches a "real" device it is just treated as bulk even it was suppose to be for example minimum-delay. Is there anyway the TOS of the UDP packet could be set the match its payload's TOS? Cheers Craig |
|
From: James Y. <ji...@yo...> - 2002-10-28 12:25:12
|
Craig, No, right now OpenVPN (and I believe the Linux TUN driver as well) has no special handling for QoS such as TOS pass through between different encapsulation layers (though it's an interesting idea). You could, of course, apply QoS rules to OpenVPN's UDP connection or make use of OpenVPN's traffic shaping option (--shaper) for basic control over output speed. By using multiple tunnels between the same hosts, each with different QoS rules, you could accomplish some of the same effect. James Craig Knox <cr...@pu...> said: > Hi there, > I use QoS routing and it works great except over openvpn/tun device. > > Correct me if I am wrong but I think this is because the packets are > encapsulated within a UDP packet with no regard to what the original > packets TOS field was, so once it reaches a "real" device it is just > treated as bulk even it was suppose to be for example minimum-delay. > > Is there anyway the TOS of the UDP packet could be set the match its > payload's TOS? > > Cheers > Craig > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Openvpn-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel > -- |
|
From: Aaron S. <and...@ra...> - 2002-10-29 08:03:02
|
On 28 Oct 2002, Craig Knox wrote: > Hi there, > I use QoS routing and it works great except over openvpn/tun device. > > Correct me if I am wrong but I think this is because the packets are > encapsulated within a UDP packet with no regard to what the original > packets TOS field was, so once it reaches a "real" device it is just > treated as bulk even it was suppose to be for example minimum-delay. > > Is there anyway the TOS of the UDP packet could be set the match its > payload's TOS? One of the problems I can see with this is that you give some information away about the payload, mind you not much, but you are regardless. I guess if you really wanted to do this, one could modify openvpn to look at the IP headers directly inside of openvpn and get the TOS off of the packet and then use setsockopt() to set it for the outgoing packet. It might not seem pretty, but it'll work. Let me know if you want me to hack up a patch for you to do this. Regards, Aaron |
|
From: Craig K. <cr...@pu...> - 2002-10-29 11:54:48
|
Hi, > One of the problems I can see with this is that you give some information > away about the payload, mind you not much, but you are regardless. That is true - but for me its either give away TOS or have things become unresponsive. > I > guess if you really wanted to do this, one could modify openvpn to look at > the IP headers directly inside of openvpn and get the TOS off of the > packet and then use setsockopt() to set it for the outgoing packet. It > might not seem pretty, but it'll work. Let me know if you want me to hack > up a patch for you to do this. Cheers - Think I've manage to make the changes by getting the TOS field of the incoming packet and setting it on the udp packet - in that it seems to work. |
|
From: James Y. <ji...@yo...> - 2002-10-30 23:54:36
|
Craig Knox <cr...@pu...> said: > Hi, > > > One of the problems I can see with this is that you give some information > > away about the payload, mind you not much, but you are regardless. > > That is true - but for me its either give away TOS or have things become > unresponsive. > > > I > > guess if you really wanted to do this, one could modify openvpn to look at > > the IP headers directly inside of openvpn and get the TOS off of the > > packet and then use setsockopt() to set it for the outgoing packet. It > > might not seem pretty, but it'll work. Let me know if you want me to hack > > up a patch for you to do this. > > Cheers - Think I've manage to make the changes by getting the TOS field > of the incoming packet and setting it on the udp packet - in that it > seems to work. I think TOS pass-through would be a nice optional feature to add to OpenVPN. I would be curious to know how this works for you, i.e. extracting the TOS from the TUN/TAP data and calling setsockopt before the encrypted packet gets written to the UDP port. Some caveats that immediately come to mind: * Since OpenVPN does not assume a particular TUN encoding of IP traffic, this patch requires OpenVPN to assume an offset of the TOS bits. * Does the TOS extract and set on the UDP socket with setsockopt work in all cases, such as when packets are fragmented, dropped, or retransmitted? * This process causes the TOS to be sent as plaintext, which could be undesirable from a security standpoint. James |
|
From: Aaron S. <and...@ra...> - 2002-10-31 00:05:41
|
On Wed, 30 Oct 2002, James Yonan wrote: > > Some caveats that immediately come to mind: > > * Since OpenVPN does not assume a particular TUN encoding of IP traffic, this patch requires OpenVPN to assume an offset of the TOS bits. Well if you end up looking at the ip header by using struct iphdr, you'd be able to determine the version of IP packet whether it was 4 or 6, then from there you'd need to use either struct iphdr or struct ipv6hdr, respectively. This would be very similiar to the IPv6 detection stuff I had to do to get ipv6 tunnelling to work with Linux. > > * Does the TOS extract and set on the UDP socket with setsockopt work in all cases, such as when packets are fragmented, dropped, or retransmitted? TOS is independent of the protocol riding on top of it as it is strictly done on the IP level. The thing to consider is, depending on the OS, setting the TOS to certain levels might require root privledges. Aaron |
|
From: Craig K. <cr...@pu...> - 2002-10-31 00:32:50
|
> I think TOS pass-through would be a nice optional feature to add to OpenVPN. I would be curious to know how this works for you, i.e. extracting the TOS from the TUN/TAP data and calling setsockopt before the encrypted packet gets written to the UDP port. It does work. Some results are (the two ping test run at the same time with a couple of large scp (TOS=0x08) copies going at the same time): ping -Q 0x08 [otherside of tunnel] ------------------------------------------------------------------ 10 packets transmitted, 10 received, 0% loss, time 9085ms rtt min/avg/max/mdev = 1097.163/1282.668/2088.874/276.205 ms, pipe 2 ping -Q 0x10 [otherside of tunnel] ----------------------------------------------------------------- 10 packets transmitted, 10 received, 0% loss, time 9089ms rtt min/avg/max/mdev = 45.979/97.734/138.788/26.672 ms > Some caveats that immediately come to mind: > > * Since OpenVPN does not assume a particular TUN encoding of IP traffic, this patch requires OpenVPN to assume an offset of the TOS bits. My quick hack (3 lines) assumes it is only IPv4 (as it always is for me), for other protocols such as IPv6 I wouldn't know how to handle it, but you could always check the first 8bits are 0x45 before trying to read the TOS field. > * Does the TOS extract and set on the UDP socket with setsockopt work in all cases, such as when packets are fragmented, dropped, or retransmitted? I don't think this matters. When packets are fragmented they would get the TOS of the original packet. > * This process causes the TOS to be sent as plaintext, which could be undesirable from a security standpoint. I can't think of any other way to get the same result. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X