Bug #1525
closedOpenVPN passtos does not work
0%
Description
I set up an OpenVPN tunnel, everthings works fine but if I try to use the passtos option of OpenVPN, the TOS Bits are not copied to the tunnel packets. See the trace below:
2 ICMP packets on the LAN interface (local net is 192.168.96.0/24) with TOS=0x5:
13:45:18.455786 IP (tos 0x5,ECT, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 128)
192.168.96.11 > 172.27.1.13: ICMP echo request, id 3732, seq 46, length 108
13:45:19.457209 IP (tos 0x5,ECT, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 128)
192.168.96.11 > 172.27.1.13: ICMP echo request, id 3732, seq 47, length 108
are transfered via these two openvpn tunnel packets:
13:45:18.456172 IP (tos 0x0, ttl 64, id 3976, offset 0, flags [none], proto UDP (17), length 209, bad cksum 0 (>5183)!)>8bb3)!)
172.22.23.128.44238 > 85.182.xxx.xxx.11946: UDP, length 181
13:45:19.457600 IP (tos 0x0, ttl 64, id 54615, offset 0, flags [none], proto UDP (17), length 209, bad cksum 0 (
172.22.23.128.44238 > 85.182.xxx.xxx.11946: UDP, length 181
As you can see the TOS Bits are not copied to the tunnel packet.
The decrypted packets on the other side have the correct TOS Bit = 0x5.
You cannot use traffic shaping/QoS on a shared link (Internet+OpenVPN tunnel) without this option :-(
Perhaps it's an openvpn or freebsd issue, I am not sure...
Using: 2.0-RC2 (i386) nanabsd(4G) May 11 2011
Updated by Jim Pingle almost 13 years ago
Does the passtos keyword appear in your OpenVPN config in /var/etc/openvpn/ for the tunnel?
If the keyword appears there, and it doesn't work, unfortunately that is an OpenVPN bug and there may not be anything we can do about it. If the keyword isn't there, then there is a bug in the code that generates the config, and it can be fixed.
Updated by Torsten Vielhak almost 13 years ago
The keyword is in the config, see below. I will try an openvpn linux client. I think setting the TOS field is very OS dependent.
dev ovpnc1 dev-type tun dev-node /dev/tun1 writepid /var/run/openvpn_client1.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp cipher AES-128-CBC up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local 172.22.23.128 tls-client client lport 0 management /var/etc/openvpn/client1.sock unix remote 85.182.255.196 11946 ifconfig 172.16.3.2 172.16.3.1 route 172.27.0.0 255.255.0.0 ca /var/etc/openvpn/client1.ca cert /var/etc/openvpn/client1.cert key /var/etc/openvpn/client1.key passtos
Updated by Torsten Vielhak almost 13 years ago
It's working with Linux OpenVPN 2.1.1 x86_64-redhat-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] built on Jan 5 2010
without TOS field set:
14:13:48.291364 IP (tos 0x0, ttl 64, id 20501, offset 0, flags [none], proto UDP (17), length 161)
172.22.23.10.cadlock2 > 85.182.255.196.11946: [udp sum ok] UDP, length 133
14:13:49.291392 IP (tos 0x0, ttl 64, id 20502, offset 0, flags [none], proto UDP (17), length 161)
172.22.23.10.cadlock2 > 85.182.255.196.11946: [udp sum ok] UDP, length 133
Set TOS to 0x5 and the encrypted packet is also tagged with tos 0x5:
14:13:52.673831 IP (tos 0x5,ECT, ttl 64, id 20503, offset 0, flags [none], proto UDP (17), length 161)
172.22.23.10.cadlock2 > 85.182.255.196.11946: [udp sum ok] UDP, length 133
14:13:53.673363 IP (tos 0x5,ECT, ttl 64, id 20504, offset 0, flags [none], proto UDP (17), length 161)
172.22.23.10.cadlock2 > 85.182.255.196.11946: [udp sum ok] UDP, length 133
Updated by Torsten Vielhak almost 13 years ago
Just compiled
OpenVPN 2.2.0 x86_64-unknown-linux-gnu [SSL] [EPOLL] [eurephia] built on May 13 2011
and it works:
14:48:29.844255 IP (tos* 0x5*,ECT, ttl 64, id 19047, offset 0, flags [none], proto UDP (17), length 161)
172.22.23.10.cadlock2 > 85.182.255.196.11946: [udp sum ok] UDP, length 133
14:48:30.844248 IP (tos* 0x5*,ECT, ttl 64, id 19048, offset 0, flags [none], proto UDP (17), length 161)
172.22.23.10.cadlock2 > 85.182.255.196.11946: [udp sum ok] UDP, length 133
Hmmm... strange problem.
Updated by Jim Pingle almost 13 years ago
Any way to try that same test compiling it on a FreeBSD client?
It's probably a FreeBSD-specific issue, if that's the case it needs to be reported to the OpenVPN project
Updated by Chris Buechler almost 13 years ago
- Status changed from New to Feedback
Updated by Torsten Vielhak almost 13 years ago
You are right! It looks like an OpenVPN problem in the FreeBSD port. I
compiled OpenVPN 2.2.0 with FreeBSD8.1
This is the decrypted packet:
11:04:49.312291 IP (tos 0x5,ECT, ttl 63, id 58247, offset 0, flags [none], proto ICMP (1), length 84)
172.16.3.2 > 172.27.1.13: ICMP echo request, id 51644, seq 36, length 64
an this is the encrypted one:
11:04:49.304835 IP (tos 0x0, ttl 64, id 58280, offset 0, flags [none], proto UDP (17), length 161)
172.22.23.131.1000 > 85.182.255.196.11946: UDP, length 133
So I think we can close this ticket and I will try to open a ticket at openvpn.
Thanks for your support!
Updated by Jim Pingle almost 13 years ago
- Status changed from Feedback to Closed
Thank you for taking the time to track it down, it's really appreciated.
If you hear back anything from them, be sure to let us know so we can look into getting it fixed in the future.
Updated by Torsten Vielhak almost 13 years ago
see ticket #135:
https://community.openvpn.net/openvpn/ticket/135
I found the problem (see ticket above). Let's see if the guys at openvpn make a patch for this.
Updated by Jim Pingle almost 13 years ago
Well if you found a workaround, even if they don't patch it, we can. Just do a diff -u file.c.orig file.c and post the output here. I didn't see the filename mentioned on the ticket there.
We can rig it so the patch is applied to our port for openvpn.
Updated by Jim Pingle almost 13 years ago
- Status changed from New to Needs Patch
Updated by Torsten Vielhak almost 13 years ago
That would be great ;-) The patched file ist openvpn-2.2.0/socket.h
bsd81# diff -u socket.h.orig socket.h --- socket.h.orig 2011-04-06 18:04:54.000000000 +0200 +++ socket.h 2011-05-17 17:10:46.000000000 +0200 @@ -885,7 +885,10 @@ link_socket_set_tos (struct link_socket *ls) { if (ls && ls->ptos_defined) - setsockopt (ls->sd, IPPROTO_IP, IP_TOS, &ls->ptos, sizeof (ls->ptos)); + { + int tos = ls->ptos; + setsockopt (ls->sd, IPPROTO_IP, IP_TOS, &tos, sizeof (tos)); + } } #endif
Updated by Jim Pingle almost 13 years ago
Can you try that with a cast instead of reassignment? You should be able to use (int) before that variable name for a similar effect.
Updated by Torsten Vielhak almost 13 years ago
Are you sure? The parameter is a pointer to the address of ptos (&ls->ptos), so a cast would lead to unpredictable results.
e.g. Memory: aa bb cc dd ee ff
If ls->ptos is at "cc" than a cast to integer would lead to the value "dd cc" or "cc dd", which is not what we want. Or am I completly wrong?
Updated by Torsten Vielhak almost 13 years ago
Whatever! ;-) This is even shorter... ptos is not used anywhere else:
bsd81# diff -u socket.h.orig socket.h --- socket.h.orig 2011-04-06 18:04:54.000000000 +0200 +++ socket.h 2011-05-18 13:22:15.000000000 +0200 @@ -225,7 +225,7 @@ #if PASSTOS_CAPABILITY /* used to get/set TOS. */ - uint8_t ptos; + uint32_t ptos; bool ptos_defined; #endif
Updated by Jim Pingle almost 13 years ago
My c is a bit rusty so it could have gone either way :-)
If that header patch does the job that is much nicer. There was some concern that the extra variable in the first patch would have had a speed impact during normal operation.
You'll want to update the OpenVPN ticket with that same code as well, the could probably do another ifdef there testing for FreeBSD, or some configure mojo and it would be even easier for them.
Updated by Jim Pingle almost 13 years ago
- Status changed from Needs Patch to Feedback
Committed that little patch here:
https://github.com/bsdperimeter/pfsense-tools/commit/f2b7c612a4434df1d6ac9314a2f98c2fe7bdf7cb
Next new snapshot should have an OpenVPN binary that includes the fix.
Updated by Chris Buechler about 12 years ago
- Status changed from Feedback to Resolved