pfSense

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.

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

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

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.

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

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!

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.

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.

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

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.

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?

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

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.