Project

General

Profile

Actions

Bug #1525

closed

OpenVPN passtos does not work

Added by Torsten Vielhak about 11 years ago. Updated over 10 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
05/13/2011
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.0
Affected Architecture:

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)!)
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 (
>8bb3)!)
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

Actions #1

Updated by Jim Pingle about 11 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.

Actions #2

Updated by Torsten Vielhak about 11 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

Actions #3

Updated by Torsten Vielhak about 11 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

Actions #4

Updated by Torsten Vielhak about 11 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.

Actions #5

Updated by Jim Pingle about 11 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

Actions #6

Updated by Chris Buechler about 11 years ago

  • Status changed from New to Feedback
Actions #7

Updated by Torsten Vielhak about 11 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!

Actions #8

Updated by Jim Pingle about 11 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.

Actions #9

Updated by Torsten Vielhak about 11 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.

Actions #10

Updated by Jim Pingle about 11 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.

Actions #11

Updated by Jim Pingle about 11 years ago

  • Status changed from Closed to New
Actions #12

Updated by Jim Pingle about 11 years ago

  • Status changed from New to Needs Patch
Actions #13

Updated by Torsten Vielhak about 11 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

Actions #14

Updated by Jim Pingle about 11 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.

Actions #15

Updated by Torsten Vielhak about 11 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?

Actions #16

Updated by Torsten Vielhak about 11 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

Actions #17

Updated by Jim Pingle about 11 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.

Actions #18

Updated by Jim Pingle about 11 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.

Actions #19

Updated by Chris Buechler over 10 years ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF