{5} Accepted, Active Tickets by Owner (Full Description) (21 matches)

List tickets accepted, group by ticket owner. This report demonstrates the use of full-row display.

Gert Döring (11 matches)

Ticket Summary Component Milestone Type Created
Description
#1322 Use actual VPN gateway address to determine "default" route Networking release 2.7 Feature Wish 09/08/20

Align IPv4 code with IPv6 code, so "get_default_gateway()" grows an extra field for "destination address to query", and fill that with the VPN gateway's (IPv4) address.

After all, this is what we're interested in, not "some /0 route that might not be the route actually used" (machines with multiple interfaces are getting more common)


#498 Support dynamic IPv6 prefixes in server config rather than hardcoded prefixes. IPv6 release 2.7 Feature Wish 01/02/15

The use of DHCPv6-PD by many ISPs creates a headache in using IPv6 for an OpenVPN tunnel because OpenVPN currently requires the IPv6 prefix be hardcoded into the server config.

It would be nice to have OpenVPN use whatever prefix is assigned to the TUN adapter by DHCPv6.

For example, let's say the OpenVPN server machine receives a /60 address from the ISP: 2001:db8::/60. The DHCPv6 client on machine then assigns a /64 to the OpenVPN tun adapter: 2001:db8:0:1::1/64. Now I want OpenVPN to assign IPv6 addresses to connecting clients using WHATEVER prefix was assigned to the tun adapter.

Seems like the way to accomplish this would be as follows: 1) Remove the "ifconfig-ipv6" command from the server config. Thus IPv6 assignment to the TUN adapter on the server could be handled by the DHCPv6 client on the machine as and when it receives a new prefix from the ISP. (In the current state, if the IPv6 address is given to the TUN adapter by DHCPv6, then OpenVPN also calls ifconfig to assign the address and produces a file-already-exists error and OpenVPN exits as a result. However, the "ifconfig-ipv6" command cannot currently be removed from the server config because...) 2) Currently "ifconfig-ipv6-pool" also requires that "ifconfig-ipv6" is used. Remove this requirement so "ifconfig-ipv6-pool" can be used without "ifconfig-ipv6". 3) Allow syntax for "ifconfig-ipv6-pool" that only specifies the suffix. For example "ifconfig-ipv6-pool ::100/64" would assign IPv6 addresses to connecting clients starting at <prefix>::100. The <prefix> would be whatever is assigned to the TUN adapter. 4) When the IPv6 prefix assigned by DHCPv6-PD to the TUN adapter on the server changes, re-issue new IPv6 addresses to connected clients with the new prefix.

The only workaround I have come up with is to use ULA addresses, which can be hardcoded. This works for local traffix, but prevents me redirecting all IPv6 internet-bound traffic through the tunnel (because clients do not receive a publicly routable IPv6 address).


#877 Clients bound to a specific IP don't use a random outgoing port Configuration release 2.6 Feature Wish 04/26/17

On one of my systems, I'm running an OpenVPN server as well as a client. This system has 5 public IPs with the OpenVPN server bound to 0.0.0.0:1194, and the client bound to one of the public IPs (--local 1.1.1.1), connecting to server2.domain.com:1194 (using --remote server2.domain.com 1194)

As --port defaults to 1194, the client was bound to 1.1.1.1:1194 and not receiving data (was being received by the server instead). --lport should probably default to 0 (random) and --rport to 1194.


#1085 --topology subnet is not ignore --dev tap mode Generic / unclassified release 2.7 Bug / Defect 08/18/18

On FreeBSD 11.2 with OpenVPN 2.4.6, contrary to the lines in the man page:

       --topology mode
              Configure virtual addressing topology when running in --dev tun mode.  This directive has no meaning in --dev tap mode, which always uses a subnet topology.

using the line "topology subnet" in a config file with "dev tap" results in subnet mode being turned off and point-to-point mode seemingly being turned on.

On the server side, one sees the following:

root@opensecrets:/usr/local/etc/openvpn# ifconfig tap0
tap0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=80000<LINKSTATE>
	ether 00:bd:55:98:05:00
	inet6 fe80::2bd:55ff:fe98:500%tap0 prefixlen 64 tentative scopeid 0x5 
	inet6 2001:470:b09d:17::1 prefixlen 64 tentative 
	inet 10.128.64.1 netmask 0xfffff000 broadcast 10.128.64.2 
	nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
	media: Ethernet autoselect
	status: active
	groups: tap 
	Opened by PID 88373

With the supposed point-to-point peer IP address as the broadcast address.

On the client side with both those lines in the config file, you see this:

root@authns1:/var/log/openvpn # ifconfig tap0
tap0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=80000<LINKSTATE>
	ether 00:bd:18:b9:1d:00
	hwaddr 00:bd:18:b9:1d:00
	inet6 fe80::2bd:18ff:feb9:1d00%tap0 prefixlen 64 scopeid 0x4 
	inet6 2001:470:b09d:17::10 prefixlen 64 
	inet 10.128.64.16 netmask 0xfffff000 broadcast 10.128.64.1 
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
	media: Ethernet autoselect
	status: active
	groups: tap 
	Opened by PID 7148

Again with the supposed point-to-point peer address as the broadcast.

Commenting out "topology subnet" line results in the expected values.

Server:

root@opensecrets:/usr/local/etc/openvpn# ifconfig tap0
tap0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=80000<LINKSTATE>
	ether 00:bd:56:a5:14:00
	inet6 fe80::2bd:56ff:fea5:1400%tap0 prefixlen 64 tentative scopeid 0x5 
	inet6 2001:470:b09d:17::1 prefixlen 64 tentative 
	inet 10.128.64.1 netmask 0xfffff000 broadcast 10.128.79.255 
	nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
	media: Ethernet autoselect
	status: active
	groups: tap 
	Opened by PID 88524

Client:

root@authns1:/var/log/openvpn # ifconfig tap0
tap0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=80000<LINKSTATE>
	ether 00:bd:68:3c:1f:00
	hwaddr 00:bd:68:3c:1f:00
	inet6 fe80::2bd:68ff:fe3c:1f00%tap0 prefixlen 64 tentative scopeid 0x4 
	inet6 2001:470:b09d:17::10 prefixlen 64 
	inet 10.128.64.16 netmask 0xfffff000 broadcast 10.128.79.255 
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
	media: Ethernet autoselect
	status: active
	groups: tap 
	Opened by PID 7425

Since the man page says that --topology has no meaning in --dev tap mode, one would expect that it would have no effect at all.


#931 TAP mode can loop packets back to the originating client Networking Bug / Defect 08/30/17

In TAP mode with client-to-client enabled, if the server learns a MAC address as being at client A and then client A sends a packet with that MAC address as a destination, the packet is routed back to client A. This is wrong and not what real switches do. It causes issues as the packet bounces back and corrupts other switches' learning tables. If two OpenVPN clients are involved, it could also cause an infinite switching loop.

This can be reproduced by setting up a TAP server with --server-bridge --client-to-client, and a client with --dev tap-cli, and then running the following two Python one-liners on the client (requires scapy):

# python2 -c 'from scapy.all import *; sendp(Ether(dst="00:00:00:00:01:aa",src="00:00:00:00:01:bb",type=0xaaaa)/"test", iface="tap-cli")'
# python2 -c 'from scapy.all import *; sendp(Ether(dst="00:00:00:00:01:bb",src="00:00:00:00:01:aa",type=0xaaaa)/"test", iface="tap-cli")'

The first packet causes OpenVPN to learn 00:00:00:00:01:bb for the client. The second one shows up twice in a tcpdump of tap-cli: the OpenVPN server resolves the 00:00:00:00:01:bb destination to the same client and loops it back. Doing this test on a real switch (or a linux bridge) does not yield the same behavior, which is expected, as normal switches never "hairpin" packets back to their source.

This issue is particularly insidious because it randomly breaks connectivity between hosts which are on the same physical switch (not across the VPN link) just because an OpenVPN client TAP is also bridged to the same network. If Host A sends a packet to Host B and the real switch's MAC table entry for Host B has expired, it floods the packet to Host C which bridges it to OpenVPN, it gets looped back, and now the physical switch thinks Host A's MAC address lives on Host C's port and things break until Host A decides to talk again.


#1384 Connections can fail if ping-restart < connect-retry (UDP, static key) Configuration release 2.5.3 Bug / Defect 02/10/21

I have a case here with server and client both using keepalive 10 120 and the default connect-retry 5 300, where both sides fail to connect because they are in caught in a vicious circle of 7min loops:

  • Reconnecting Re-using pre-shared static key
  • Not receiving any pings for 120 sec
  • Declaring an Inactivity timeout and pausing for 300sec

and because one side's reconnect happens right when the other side pauses, they always miss each other. See the merged log snippet below.

What had happened was that because of DNS issues, both sides could not connect for several days, until connect-retry had grown from initially 5sec to 300sec. By the time the DNS issue got resolved, both where in 7min cycle (2min running, 5min pause), and by chance their 2min "running" phases didn't overlap.

This can happen at least in my case with UDP and a shared secret, see configs below. There it can occur if one side's connect-retry is larger than the other side's ping-restart, and vice versa.

I guess this problem is unique to the Static Key encryption mode, because in TLS mode the server side would not pause?

Note that the default maximum for connect-retry is 300, and that an often recommended setting for ping-restart is 120 (e.g. via keepalive 10 60).

If my analysis is correct and still the case, I'd consider it a bug in the documentation and the default values. I'd recommend to:

  • Document under which circumstances this can happen, e.g. in the man page
  • Reduce the default maximum for connect-retry from 300 to something smaller than the frequently found ping-restart 120 (at least in susceptible modes)
  • In susceptible modes throw a warning when ping-restart is set and not larger than the connect-retry maximum (not to be confused with connect-retry-max!)

(This is not entirely exact, as one would have to compare ping-restart on one side to the connect-retry maximum of the other side. But given that most users mirror those settings on both sides, maybe the best way forward).

We are using OpenVPN 2.4.7-1ubuntu2 on Ubuntu 20.04.


Snippets from the server's and client's log:

# SERVER:
Feb 09 22:11:35 server[605]: Inactivity timeout (--ping-restart), restarting
Feb 09 22:11:35 server[605]: SIGUSR1[soft,ping-restart] received, process restarting
Feb 09 22:11:35 server[605]: Restart pause, 300 second(s)
# SERVER PAUSES FOR 300sec

# CLIENT:
Feb 09 22:12:34 client[614041]: Re-using pre-shared static key
Feb 09 22:12:34 client[614041]: Preserving previous TUN/TAP instance: tun0
Feb 09 22:12:34 client[614041]: TCP/UDP: Preserving recently used remote address: [AF_INET]xx.yyy.xxx.yy:1194
Feb 09 22:12:34 client[614041]: Socket Buffers: R=[212992->212992] S=[212992->212992]
Feb 09 22:12:34 client[614041]: UDPv4 link local (bound): [AF_INET][undef]:1194
Feb 09 22:12:34 client[614041]: UDPv4 link remote: [AF_INET]xx.yyy.xxx.yy:1194
# Server is dead, so no pings fopr 120sec
Feb 09 22:14:34 client[614041]: Inactivity timeout (--ping-restart), restarting
Feb 09 22:14:34 client[614041]: SIGUSR1[soft,ping-restart] received, process restarting
Feb 09 22:14:34 client[614041]: Restart pause, 300 second(s)
# CLIENT PAUSES FOR 300sec

# SERVER WAKES UP:
Feb 09 22:16:35 server[605]: Re-using pre-shared static key
Feb 09 22:16:35 server[605]: Preserving previous TUN/TAP instance: tun0
Feb 09 22:16:35 server[605]: Socket Buffers: R=[212992->212992] S=[212992->212992]
Feb 09 22:16:35 server[605]: UDPv4 link local (bound): [AF_INET][undef]:1194
Feb 09 22:16:35 server[605]: UDPv4 link remote: [AF_UNSPEC]
# Client is pausing, so no pings for 120sec
Feb 09 22:18:35 server[605]: Inactivity timeout (--ping-restart), restarting
Feb 09 22:18:35 server[605]: SIGUSR1[soft,ping-restart] received, process restarting
Feb 09 22:18:35 server[605]: Restart pause, 300 second(s)
# SERVER PAUSES FOR 300sec

... and so on and so forth ad infinitum


Server config:

user                    openvpn
group                   openvpn
chroot                  /var/lib/openvpn
cd                      /var/lib/openvpn
tmp-dir                 state

verb                    3
status                  state/status.log  60

port                    1194
proto                   udp4

secret			/etc/openvpn/private/shared.key 0
persist-key

dev                     tun
persist-tun
ifconfig                172.29.0.1 172.29.0.2
keepalive               10 120
compress
ncp-disable
cipher                  AES-256-CBC
auth                    SHA256
replay-persist          state/rpstate

route                   x.x.x.x y.y.y.y

Client config:

user                    openvpn
group                   openvpn
chroot                  /var/lib/openvpn
tmp-dir                 state
verb                    3

remote                  server 1194 udp4

secret                  /etc/openvpn/private/shared.key 1
persist-key

dev                     tun
persist-tun
ifconfig                172.29.0.2 172.29.0.1
keepalive               10 120
compress
ncp-disable
cipher                  AES-256-CBC
auth                    SHA256

route                   x.x.x.x y.y.y.y

#495 src/plugins/down-root/down-root.c should not include <err.h> directly plug-ins / plug-in API Bug / Defect 12/29/14

configure script will detect the existence of <err.h> , if <err.h> exist, down-root.c will include ith with config.h, if err.h is exist, it should not use err() and warn() from err.h.

This bug cause openvpn fail to build on AIX platform with default configure option. us '--disable-plugin-down-root' is a workaround.


#496 src/plugins/down-root/down-root.c should use src/compat/compat-daemon.c when daemon() not exist plug-ins / plug-in API Bug / Defect 12/29/14

when daemon() does not exist, down-root.c cannot use daemon() function from src/compat/compat-daemon.c.

This cause openvpn build faild on AIX.


#626 Routing entry not deleted when MAC address moves from client to server Networking release 2.7 Bug / Defect 11/09/15

Context:

A TAP OpenVPN connection is made between two virtual machine hypervisors. The TAP devices are bridged with the VM interfaces, thus creating a L2 bridge between the VMs on different hosts.

A virtual machine (192.168.42.102) is moved from a hypervisor host (node02) to another one (node01).

Initial situation:

.---------------------------------.                         .---------------------------------.
| node01                          |                         | node02                          |
| OpenVPN server                  |                         | OpenVPN client                  |
|                                 |                         |                                 |
|    .-----------------------.    |                         |     .-----------------------.   |
|    | br0                   |    |                         |     | br0                   |   |
|    | .-------------------. |    |                         |     | .-------------------. |   |
|    | | tap0              | |    |                         |     | | tap1              | |   |
|    | | 192.168.42.1      |<----------------OpenVPN----------------| 192.168.42.2      | |   |
|    | | de:57:b6:64:0e:c8 | |    |                         |     | | 2e:60:ce:c9:63:d1 | |   |
|    | '-------------------' |    |                         |     | '-------------------' |   |
|    |                       |    |                         |     | .-------------------. |   |
|    |                       |    |                         |     | | vnet0             | |   |
|    |                       |    |                         |     | | 192.168.42.102    | |   |
|    |                       |    |                         |     | | 52:54:00:de:ad:02 | |   |
|    |                       |    |                         |     | '-------------------' |   |
|    '-----------------------'    |                         |     '-----------------------'   |
'---------------------------------'                         '---------------------------------'

Final situation:

.---------------------------------.                         .---------------------------------.
| node01                          |                         | node02                          |
| OpenVPN server                  |                         | OpenVPN client                  |
|                                 |                         |                                 |
|    .-----------------------.    |                         |     .-----------------------.   |
|    | br0                   |    |                         |     | br0                   |   |
|    | .-------------------. |    |                         |     | .-------------------. |   |
|    | | tap0              | |    |                         |     | | tap1              | |   |
|    | | 192.168.42.1      |<----------------OpenVPN----------------| 192.168.42.2      | |   |
|    | | de:57:b6:64:0e:c8 | |    |                         |     | | 2e:60:ce:c9:63:d1 | |   |
|    | '-------------------' |    |                         |     | '-------------------' |   |
|    | .-------------------. |    |                         |     |                       |   |
|    | | vnet0             | |    |                         |     |                       |   |
|    | | 192.168.42.102    | |    |                         |     |                       |   |
|    | | 52:54:00:de:ad:02 | |    |                         |     |                       |   |
|    | '-------------------' |    |                         |     |                       |   |
|    '-----------------------'    |                         |     '-----------------------'   |
'---------------------------------'                         '---------------------------------'

What I do: Ping 192.168.42.2 (node02) from 192.168.42.102 (the VM).

What happens: Once the machine is moved from node02 to node01, no ping reply reaches the VM.

What should happen instead: Ping replies should reach the VM.


OpenVPN version:

OpenVPN 2.3.8 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Aug  4 2015
library versions: OpenSSL 1.0.1e-fips 11 Feb 2013, LZO 2.06
Originally developed by James Yonan
Copyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@openvpn.net>
Compile time defines: enable_crypto=yes enable_crypto_ofb_cfb=yes enable_debug=yes enable_def_auth=yes enable_dependency_tracking=no enable_dlopen=unknown enable_dlopen_self=unknown enable_dlopen_self_static=unknown enable_fast_install=yes enable_fragment=yes enable_http_proxy=yes enable_iproute2=yes enable_libtool_lock=yes enable_lzo=yes enable_lzo_stub=no enable_management=yes enable_multi=yes enable_multihome=yes enable_pam_dlopen=no enable_password_save=yes enable_pedantic=no enable_pf=yes enable_pkcs11=yes enable_plugin_auth_pam=yes enable_plugin_down_root=yes enable_plugins=yes enable_port_share=yes enable_pthread=yes enable_selinux=no enable_server=yes enable_shared=yes enable_shared_with_static_runtimes=no enable_small=no enable_socks=yes enable_ssl=yes enable_static=yes enable_strict=no enable_strict_options=no enable_systemd=yes enable_win32_dll=yes enable_x509_alt_username=yes with_crypto_library=openssl with_gnu_ld=yes with_iproute_path=/sbin/ip with_mem_check=no with_plugindir='$(libdir)/openvpn/plugins' with_sysroot=no

Linux version:

CentOS Linux release 7.1.1503 (Core)
Linux node02 4.1.12-default #1 SMP Thu Nov 5 16:00:51 CET 2015 x86_64 x86_64 x86_64 GNU/Linux

Server config:

local 198.51.100.7
port 1194
proto udp
dev tap0
mode server
tls-server
ca /etc/openvpn/pki/whatever-ca-crt.pem
cert /etc/openvpn/pki/whatever-server-crtchain.pem
key /etc/openvpn/pki/whatever-server-key.pem
dh /etc/openvpn/pki/whatever-ca-dh.pem
tls-auth /etc/openvpn/pki/ta.key 0
server-bridge 192.168.11.1 255.255.255.0 192.168.11.100 192.168.11.200
client-to-client
duplicate-cn
keepalive 10 120
#comp-lzo
max-clients 4
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
log-append openvpn.log
verb 9
script-security 2

Client config:

client
dev tap1
proto udp
remote 198.51.100.7 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca /etc/openvpn/pki/whatever-ca-crt.pem
cert /etc/openvpn/pki/whatever-client02-crtchain.pem
key /etc/openvpn/pki/whatever-client02-key.pem
ns-cert-type server
tls-auth /etc/openvpn/pki/ta.key 1
#comp-lzo
verb 9
log-append openvpnclient.log
script-security 2
keepalive 30 120
float
status openvpn-status.log

Here are the log excerpt for a ping packet from the VM the other hypervisor:

Server sends ping packet:

read from TUN/TAP returned 98
GET INST BY VIRT: 2e:60:ce:c9:63:d1 -> OpenVPNClient02/198.51.100.8:45186 via 2e:60:ce:c9:63:d1
OpenVPNClient02/198.51.100.8:45186 TUN READ [98]
OpenVPNClient02/198.51.100.8:45186 ENCRYPT FROM: 0000006c 2e60cec9 63d15254 00dead02 08004500 0054f4ea 0000ff01 f104c0a[more...]
OpenVPNClient02/198.51.100.8:45186 ENCRYPT TO: 8bc767c2 ebacf0f8 120e8996 092c2d68 675bd569 33189ea8 2aa88961 998fcfb[more...]
OpenVPNClient02/198.51.100.8:45186 UDPv4 WRITE [133] to [AF_INET]198.51.100.8:45186: P_DATA_V1 kid=0 DATA c2fe31ee 55bf2043 c24309d1 fef442c3 78d1002d 8bc767c2 ebacf0f8 120e899[more...]
OpenVPNClient02/198.51.100.8:45186 UDPv4 write returned 133

Client receives ping packet:

UDPv4 READ [133] from [AF_INET]198.51.100.7:1194: P_DATA_V1 kid=0 DATA c2fe31ee 55bf2043 c24309d1 fef442c3 78d1002d 8bc767c2 ebacf0f8 120e899[more...]
DECRYPT TO: 0000006c 2e60cec9 63d15254 00dead02 08004500 0054f4ea 0000ff01 f104c0a[more...]
PID_TEST [0] [SSL-0] [112233445566778899>>>>>>>>>>>>>>>>EEEEEEEEEEEEEEEEEEEEEEEEEEEEEE] 0:107 0:108 t=1447061166[0] r=[-2,64,15,0,1] sl=[21,64,64,528]
TUN WRITE [98]
write to TUN/TAP returned 98

Client sends pong packet:

TUN READ [98]
ENCRYPT FROM: 0000006a 525400de ad022e60 cec963d1 08004500 00541a02 00004001 8aeec0a[more...]
ENCRYPT TO: 7cc560fa 28a6349d bad24eca 5fee496c b570067a 0b0e3d6e 4f5f518f 4615351[more...]
UDPv4 WRITE [133] to [AF_INET]198.51.100.7:1194: P_DATA_V1 kid=0 DATA 31716baa 29bd16a4 68e4a888 a2ffccca 673cbd94 7cc560fa 28a6349d bad24ec[more...]
UDPv4 write returned 133

Server receives pong packet and sends it back to client:

OpenVPNClient02/198.51.100.8:45186 UDPv4 READ [133] from [AF_INET]198.51.100.8:45186: P_DATA_V1 kid=0 DATA 31716baa 29bd16a4 68e4a888 a2ffccca 673cbd94 7cc560fa 28a6349d bad24ec[more...]
OpenVPNClient02/198.51.100.8:45186 DECRYPT TO: 0000006a 525400de ad022e60 cec963d1 08004500 00541a02 00004001 8aeec0a[more...]
OpenVPNClient02/198.51.100.8:45186 GET INST BY VIRT: 52:54:00:de:ad:02 -> OpenVPNClient02/198.51.100.8:45186 via 52:54:00:de:ad:02
OpenVPNClient02/198.51.100.8:45186 ENCRYPT FROM: 0000006d 525400de ad022e60 cec963d1 08004500 00541a02 00004001 8aeec0a[more...]
OpenVPNClient02/198.51.100.8:45186 ENCRYPT TO: 5526778c dc9e2db5 64674da6 9d1eab5c c8511d8e bf3ed564 75acdc5c 4dbfa2e[more...]
OpenVPNClient02/198.51.100.8:45186 UDPv4 WRITE [133] to [AF_INET]198.51.100.8:45186: P_DATA_V1 kid=0 DATA b70e40a4 2c9e44c2 43545727 7513c0f7 a61148c1 5526778c dc9e2db5 64674da[more...]
OpenVPNClient02/198.51.100.8:45186 UDPv4 write returned 133

Client receives pong packet:

UDPv4 read returned 133
UDPv4 READ [133] from [AF_INET]198.51.100.7:1194: P_DATA_V1 kid=0 DATA b70e40a4 2c9e44c2 43545727 7513c0f7 a61148c1 5526778c dc9e2db5 64674da[more...]
DECRYPT TO: 0000006d 525400de ad022e60 cec963d1 08004500 00541a02 00004001 8aeec0a[more...]
TUN WRITE [98]
write to TUN/TAP returned 98

TCPdump on client shows the pong packet coming back:

10:38:31.163434 IP 192.168.42.102 > 192.168.42.2: ICMP echo request, id 48223, seq 806, length 64
10:38:31.163472 IP 192.168.42.2 > 192.168.42.102: ICMP echo reply, id 48223, seq 806, length 64
10:38:31.165248 IP 192.168.42.2 > 192.168.42.102: ICMP echo reply, id 48223, seq 806, length 64

Getting the server's status report indicates that the MAC address of 192.168.42.102 (the VM) is still considered to be reachable through the VPN client while it now should be considered a local address:

OpenVPN CLIENT LIST
Updated,Mon Nov  9 10:30:52 2015
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
OpenVPNClient02,198.51.100.8:45186,63009,96567,Mon Nov  9 10:21:58 2015
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
2e:60:ce:c9:63:d1,OpenVPNClient02,198.51.100.8:45186,Mon Nov  9 10:30:51 2015
52:54:00:de:ad:02,OpenVPNClient02,198.51.100.8:45186,Mon Nov  9 10:30:51 2015
GLOBAL STATS
Max bcast/mcast queue length,1
END

Reading the source code indicates that multi_learn_addr() in multi.c does not update routes when the destination addr is local: https://github.com/OpenVPN/openvpn/blob/ea66a2b5cdb21422139c421b4d3733e1c1c3937e/src/openvpn/multi.c#L1016 Thus, the bad route is kept and is used while it should have been deleted.

When I move the VM between two hypervisors that are both clients of the OpenVPN server (instead of moving it from a client to the server), the condition is respected, the routing table is updated and the network has no problem:

OpenVPNClient02/198.51.100.8:56038 MULTI: Learn: 52:54:00:de:ad:02 -> OpenVPNClient02/198.51.100.8:56038

So, to sum up the diagnostic: When a MAC address moves from a client to the server, the entry in the routing table is not deleted, and the trafic to the MAC address is sent to the client connection where it was last seen while it should be handled locally.

Should I write and submit a patch?


#735 netbsd: named tap devices not auto-created Networking release 2.7 Bug / Defect 09/13/16

running OpenVPN --dev tap3 on NetBSD 7.0.1 only works if that device has been manually created by ifconfig tap3 create before - and then, it still isn't behaving "properly" because ifconfig/route changes are not cleaned up on exit.

Mainly recording this so someone can look into it.

Code in question is in tun.c around line 1600

      if (!dynamic_opened)
        {
          /* has named device existed before? if so, don't destroy at end */
          if ( if_nametoindex( dev ) > 0 )
            {
              msg (M_INFO, "TUN/TAP device %s exists previously, keep at program
 end", dev );
              tt->persistent_if = true;
            }

          if ((tt->fd = open (tunname, O_RDWR)) < 0)
            msg (M_ERR, "Cannot open TUN/TAP dev %s", tunname);
        }

adding an #ifdef TARGET_NETBSD .. else if strncmp(dev, tap) == 0 ... exec("ifconfig $dev create") would work, but not make the code much prettier... (plus, it needs destroy at tun_close).


#853 AIX: down-root: fatal error: err.h: No such file or directory plug-ins / plug-in API Bug / Defect 03/07/17

Compiling source on AIX 7.1 stop with this error message. What is this err.h? I only found the one from openssl, available at /opt/freeware/include/openssl/err.h, but I think this is a different file.

[...]
Making all in down-root
make[4]: Entering directory '/nfs/openvpn/src/plugins/down-root'
/bin/sh ../../../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../.. -I../../../include    -I../../../include -I/opt/freeware/include -g -O2 -std=c99 -MT down-root.lo -MD -MP -MF .deps/down-root.Tpo -c -o down-root.lo down-root.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../.. -I../../../include -I../../../include -I/opt/freeware/include -g -O2 -std=c99 -MT down-root.lo -MD -MP -MF .deps/down-root.Tpo -c down-root.c  -fPIC -DPIC -o .libs/down-root.o
down-root.c:45:17: fatal error: err.h: No such file or directory
 #include <err.h>
                 ^
compilation terminated.
Makefile:514: recipe for target 'down-root.lo' failed
make[4]: *** [down-root.lo] Error 1

Thank you, Giuseppe


David Sommerseth (2 matches)

Ticket Summary Component Milestone Type Created
Description
#945 systemd: LimitNPROC too low, wrong knob Generic / unclassified Bug / Defect 10/09/17

This has been originally reported to Debian at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861923. There is a way to reproduce this inside the bugreport. Basically you need to start several instances that run code as non-root

Since the very first version of the systemd unit it contains the setting

LimitNPROC=10

according to systemd.exec this translates to "ulimit -u".

Even if set in the systemd unit this seems to translate to a generic "limit the number of processes per UID on the whole system" thing, which is certainly not the thing the author had in mind.

https://bugs.launchpad.net/ubuntu/+source/openvpn/+bug/1631104 https://github.com/systemd/systemd/issues/6011#issuecomment-304617744


#840 Server --auth-gen-token and client --auth-nocache do not work together Configuration release 2.6 Bug / Defect 02/07/17

If a server pushes an auth-token to a client using auth-nocache the client does not cache the token. Thus renegotiating a connection after --reneg-sec/bytes/pkts causes client to drop the current connection and request password from user.

Currently the fix is: do not use --auth-nocache in client config.

More information: https://www.mail-archive.com/openvpn-users@lists.sourceforge.net/msg03511.html


Antonio Quartulli (2 matches)

Ticket Summary Component Milestone Type Created
Description
#1399 Linux: configure custom routing table id in client OSS OpenVPN Clients release 2.7 Feature Wish 04/10/21

To the best of my knowledge, on Linux by default route changes get committed to the "main" table 254. I would like to be able to configure my OpenVPN client to use a different routing table instead.

The problem I try to solve is routing traffic from some daemons over a VPN connection, but not traffic from other applications or daemons. An elegant solution would be for IPTables to mark traffic from applications running as a certain user- or group-id with a particular index i, e.g. "iptables -t mangle -A OUTPUT -p tcp -m owner --uid-owner [uid] -j MARK --set-mark 10" Using "ip rule add fwmark 10 table [table-id]", I can then route traffic for those applications according to the routing table written by OpenVPN, while other traffic continues to use the default routing table. Manually scripting up routing table entries may be possible using route-up scripts, but in the presence of dynamic IPs and pushed/pulled route changes this use-case might be cleaner to achieve with a simple "route-table" option in a VPNs configuration file.


#1405 make persist-key always on, remove other code path Configuration release 2.7 Feature Wish 05/03/21

As discussed (suggested) on the openvpn-devel list in this thread

http://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg22098.html

nobody seems to see a good reason to keep the code path no --persist-key.

So, feature wish: make it always-on, remove the "off" code path, document.


Samuli Seppänen (3 matches)

Ticket Summary Component Milestone Type Created
Description
#23 Integrate code security analysis tools into Buildbot Generic / unclassified TODO (General task list) 07/16/10

In the IRC meeting on 22nd Apr 2010 it was agreed that all patches should be checked with (security) auditing tools such as Valgrind and Coverity. These tools need to be integrated into our Continuous integration server app, Buildbot.


#161 GET INST BY VIRT error is too obscure quiet Generic / unclassified release 2.4 Bug / Defect 09/20/11

This error means that your packets are being dropped:

Tue Sep 20 12:47:53 2011 us=236940 GET INST BY VIRT: 196.12.12.88 [failed]

Unfortunately it's very easy to miss. It's not visible at debug level 6 and it's not obvious at all. Perhaps it could be made more severe, and say something like:

"No internal route (iroute) to 196.12.12.88, dropping packet, see http://openvpn.net/index.php/open-source/faq/79-client/317-qmulti-bad-source-address-from-client--packet-droppedq-or-qget-inst-by-virt-failedq.html"

Cheers, Chris.


#592 Tap-Windows Adapter not work Windows 10 tap-windows6 Bug / Defect 08/06/15

No work Windows 10 Tap-Windows Adapter Add ComponentId?: tap0901 not fix the problem


Steffan Karger (3 matches)

Ticket Summary Component Milestone Type Created
Description
#911 interface mtu calculation in 2.4 significantly different from 2.3 Generic / unclassified Bug / Defect 07/04/17

debian bug report:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867113

with --link-mtu 1400, 2.3 sets ip ... mtu 1344 while 2.4 sets ip ... mtu 1278 (which is too small for IPv6).

I can see a few bytes being lost to account for worst-case crypto overhead before negotiation, but 80 extra bytes? This needs a closer look...


#963 OpenVPN 2.4.4 OpenSSL 1.1.x issues with ECC ciphers (client only) Generic / unclassified release 2.4.11 Bug / Defect 12/01/17
  • openvpn 2.4.4 + openssl 1.1.0g compiled from source.
  • certificates using curve sect571r1

On connect, client hangs, and on server i get: OpenSSL: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher This is only with openssl 1.1 , with 1.0.x it works just fine.

After some reading, i saw this change on OpenSSL:

*) Change the ECC default curve list to be this, in order: x25519, secp256r1, secp521r1, secp384r1. [Rich Salz] Somehow openssl defaults to x25519 , and my certificates are using sect571r1, and passing ecdh-curve to openvpn does not solve it.

What i tried was adding this:

SSL_CTX_set1_curves_list(ctx->ctx, "sect571r1");

in src/openvpn/ssl_openssl.c, on line 271, just under SSL_CTX_set_default_passwd_cb

This only happens on the client, it doesn't seem to have anything to do with the server.

Maybe someone can implement a proper fix to adapt to openssl 1.1 changes ...

Issue can also be seen here: https://github.com/schwabe/ics-openvpn/issues/721


#835 OpenVPN exits on fatal error with large tun-mtu Networking Bug / Defect 01/30/17

There was a discussion in #openvpn on Freenode with users T1w claiming to see speeds increase from ~503Mbps up to 958Mbps by modifying --tun-mtu and setting to some crazy numbers (49k, 48k, even 60k). Curious, I asked for his config files and what he used for testing.

T1w Testing Environment

  • OpenVPN 2.3.14
  • OpenSSL 1.0.1e-fips (RHEL package)

ecrist Testing Environment

  • OpenVPN 2.4.0
  • OpenSSL 1.0.1s

IRC Chat Logs

07:03:47 < BtbN> But it also creates quite a bit of lag on the network
07:05:13 <@ecrist> what/who does 60k MTUs as a "common" practice?
07:05:49 < T1w> ecrist: well.. at the moment I've gone up from ~503Mbit/s to 958Mbit/s just by going up with 
                tun-mtu and disabling fragmentation and mss fix
07:06:57 < T1w> that's in a local test, so it's what I'd expect to see for a 1gbit link, but I've got a real life 
                1gbit line where I've never gone above ~120Mbit
07:07:15 < T1w> and I'd like to change that before investing in a black fiber to get the speed I need
07:07:50 <@ecrist> Is your current 1g link through a normal ISP?
07:07:52 < T1w> BtbN: lag is the least of my problems - as long as I get more throughput
07:07:53 < BtbN> saturating a gigabit link with openvpn is close to impossible though, even with all the tuning you 
                 can get
07:08:24 < T1w> ecrist: that probably pedends on what you mean by "normal"
07:08:30 < T1w> it's a datacenter
07:09:00 < T1w> BtbN: 958 is as close to saturated as I'd expect to see
07:09:06 <@ecrist> ah, most of those are grossly over-subscribed
07:09:30 <@ecrist> T1w: can you send me your config for client/server?  I'd like to try that out
07:10:09 < T1w> BtbN: actually.. just trying the physical link between my testmachines (and not going through 
                openvpn) I get a lower speed..
07:10:30 < T1w> 942Mbit/s compared to the 958Mbit/s through openvpn
07:10:43 < T1w> that's.. interesting
07:10:46 < T1w> ecrist: sec..
07:15:15 < T1w> ecrist: https://paste.sh/UgJDEDVG#u9Dnx5lXCZsBfSuHRY6QJV7a
07:15:39 < T1w> ecrist: it's where I've ended up after reading 
                https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux
07:15:41 <@vpnHelper> Title: Gigabit_Networks_Linux � OpenVPN Community (at community.openvpn.net)
07:16:29 < T1w> ecrist: and no.. our link is not oversubscribed - I can easily get really close to wirespeed when 
                transferring other stuff from around EU (I'm located in Denmark)
07:17:45 < T1w> funny thing is that once I went above 50000 bytes MTU my iperf tests dies out
07:17:52 < T1w> 49000 is fine, 50000 is not
07:19:15 < T1w> ping is fine, but iperf dies out after the first few MB
07:21:46 < T1w> hm.. seemlingly because the serverside dies
07:22:37 < T1w> ah
07:22:38 < T1w> Mon Jan 30 14:09:29 2017 us=427893 gauss/10.5.99.205:42307 Assertion failed at lzo.c:202 (buf_safe 
                (&work, zlen))
07:22:38 < T1w> Mon Jan 30 14:09:29 2017 us=427963 gauss/10.5.99.205:42307 Exiting due to fatal error
07:22:44 < T1w> lets try without lzo
07:22:48 <@ecrist> T1w: what is your iperf syntax for your performance measurements?
07:23:11 < T1w> ecrist: server:  -s -p 10000 -B 10.8.8.6
07:23:26 < T1w> ecrist: client:  -p 10000 -c 10.8.8.6 -t 30
07:24:15 < T1w> I squzed a bit more out by renicing the client iperf to -19 (since the system is used for other 
                stuff)
07:24:49 < T1w> only a few mbit, but it removed a few fluctuations where performance dropped down
07:28:05 <@ecrist> which version of openvpn?
07:28:29 < T1w> hah.. no without lzo it just gives me
07:28:30 < T1w> 49781 IP packet with unknown IP version=15 seen
07:28:50 < T1w> ecrist: 2.3.14
07:29:23 < T1w> the version avabilable in the EPEL 7 x86_64 repo
07:29:43 < T1w> OpenVPN 2.3.14 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on 
                Dec  7 2016
07:29:45 < T1w> using
07:29:57 < T1w> library versions: OpenSSL 1.0.1e-fips 11 Feb 2013, LZO 2.06
07:30:15 < T1w> (RHEL version of OpenSSL with backports)
07:30:44 < T1w> afk - back in 10-15 mins
07:31:03 <@ecrist> I'm trying this out - so far, just two servers connected to the same switch each over 1g 
                   uplinks, I see 936Mbps
07:31:10 <@ecrist> now to set up OpenVPN
07:51:47 <@ecrist> huh, this is a new one
07:51:49 <@ecrist> Mon Jan 30 07:39:16 2017 us=113384 Assertion failed at crypto.c:81 
                   (packet_id_initialized(&opt->packet_id))
07:51:49 <@ecrist> Mon Jan 30 07:39:16 2017 us=113393 Exiting due to fatal error
 [@ecrist(+i)] [5:#openvpn(+cgnprt)] [257 nicks (@9 %0 +2 246)]                                                     

Results (read: problem)

The startup of the server side process is uneventful (logs attached). Startup of the client, however, results in a quick fatal error after full initialization. The same error is evident in the server logs, and that process also dies.

Server Log

Mon Jan 30 07:39:16 2017 us=32861 client/10.3.14.230 SENT CONTROL [client]: 'PUSH_REPLY,route 10.8.8.0 255.255.255.0,route 10.8.8.1,topology net30,ping 5,ping-restart 30,ifconfig 10.8.8.6 10.8.8.5,peer-id 0,cipher AES-256-GCM' (status=1)
Mon Jan 30 07:39:16 2017 us=32907 client/10.3.14.230 Data Channel MTU parms [ L:48046 D:48046 EF:46 EB:8156 ET:0 EL:3 ]
Mon Jan 30 07:39:16 2017 us=33059 client/10.3.14.230 Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Mon Jan 30 07:39:16 2017 us=33096 client/10.3.14.230 Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Mon Jan 30 07:39:21 2017 us=412962 client/10.3.14.230 Assertion failed at crypto.c:81 (packet_id_initialized(&opt->packet_id))
Mon Jan 30 07:39:21 2017 us=413099 client/10.3.14.230 Exiting due to fatal error
Mon Jan 30 07:39:21 2017 us=413159 client/10.3.14.230 /sbin/route delete -net 10.8.8.0 10.8.8.2 255.255.255.0
delete net 10.8.8.0: gateway 10.8.8.2
Mon Jan 30 07:39:21 2017 us=415335 client/10.3.14.230 Closing TUN/TAP interface
Mon Jan 30 07:39:21 2017 us=415525 client/10.3.14.230 /sbin/ifconfig tun1 destroy

Client Log

Mon Jan 30 07:39:16 2017 us=36473 /sbin/route add -net 10.8.8.0 10.8.8.5 255.255.255.0
add net 10.8.8.0: gateway 10.8.8.5
Mon Jan 30 07:39:16 2017 us=37358 /sbin/route add -net 10.8.8.1 10.8.8.5 255.255.255.255
add net 10.8.8.1: gateway 10.8.8.5
Mon Jan 30 07:39:16 2017 us=38263 Initialization Sequence Completed
WrMon Jan 30 07:39:16 2017 us=113384 Assertion failed at crypto.c:81 (packet_id_initialized(&opt->packet_id))
Mon Jan 30 07:39:16 2017 us=113393 Exiting due to fatal error
Mon Jan 30 07:39:16 2017 us=113422 /sbin/route delete -net 10.8.8.0 10.8.8.5 255.255.255.0
delete net 10.8.8.0: gateway 10.8.8.5
Mon Jan 30 07:39:16 2017 us=114344 /sbin/route delete -net 10.8.8.1 10.8.8.5 255.255.255.255
delete net 10.8.8.1: gateway 10.8.8.5
Mon Jan 30 07:39:16 2017 us=115199 Closing TUN/TAP interface
Mon Jan 30 07:39:16 2017 us=115268 /sbin/ifconfig tun0 destroy

I've attached two zip files, one for each the server and client configuration, including DH parameters, certificates, keys, and the HMAC static key.


Note: See TracReports for help on using and creating reports.