Bug 194745 - security/openvpn: incorrect self route when using subnet topology
Summary: security/openvpn: incorrect self route when using subnet topology
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Matthias Andree
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-01 19:35 UTC by Anton Saietskii
Modified: 2015-06-10 19:19 UTC (History)
1 user (show)

See Also:
vsasjason: maintainer-feedback? (mandree)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Anton Saietskii 2014-11-01 19:35:09 UTC
OpenVPN set the self address route via the tunnel interface instead of correct - loopback.
I'm using topology subnet with 192.168.89.0 255.255.255.0 network.

Example below:
jason@cli0:~ % ifconfig tun0
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
        options=80000<LINKSTATE>
        inet6 fe80::ec4:7aff:fe06:5e%tun0 prefixlen 64 scopeid 0x7 
        inet 192.168.89.2 --> 192.168.89.2 netmask 0xffffff00 
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        Opened by PID 86175
jason@cli0:~ % netstat -rn | fgrep '192.168.89.'
192.168.89.0/24    192.168.89.2       UGS         0  4857954   tun0
192.168.89.2       link#7             UH          0        5   tun0
jason@cli0:~ % ping -c 3 192.168.89.2
PING 192.168.89.2 (192.168.89.2): 56 data bytes

--- 192.168.89.2 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
jason@cli0:~ % ping -c 3 192.168.89.1
PING 192.168.89.1 (192.168.89.1): 56 data bytes
64 bytes from 192.168.89.1: icmp_seq=0 ttl=64 time=30.161 ms
64 bytes from 192.168.89.1: icmp_seq=1 ttl=64 time=30.200 ms
64 bytes from 192.168.89.1: icmp_seq=2 ttl=64 time=30.220 ms

--- 192.168.89.1 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 30.161/30.194/30.220/0.024 ms
jason@cli0:~ %

I tried a workaround on the server:
ifconfig tun0 inet 192.168.89.1 192.168.89.255
route add -net 192.168.89.0/24 -iface tun0

So the results are:
jason@srv0:~$ ifconfig tun0
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
        options=80000<LINKSTATE>
        inet6 fe80::21e:67ff:fead:6ab0%tun0 prefixlen 64 scopeid 0x3 
        inet 192.168.89.1 --> 192.168.89.255 netmask 0x0 
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        Opened by PID 63010
jason@srv0:~$ netstat -rn | fgrep '192.168.89.'
192.168.89.0/24    tun0               US          0 29374111   tun0
192.168.89.1       link#3             UHS         0   213985    lo0
192.168.89.255     link#3             UH          0        0   tun0
jason@srv0:~$ ping -c 3 192.168.89.1
PING 192.168.89.1 (192.168.89.1): 56 data bytes
64 bytes from 192.168.89.1: icmp_seq=0 ttl=64 time=0.050 ms
64 bytes from 192.168.89.1: icmp_seq=1 ttl=64 time=0.093 ms
64 bytes from 192.168.89.1: icmp_seq=2 ttl=64 time=0.016 ms

--- 192.168.89.1 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.016/0.053/0.093/0.032 ms
jason@srv0:~$
Comment 1 Bugzilla Automation freebsd_committer 2014-11-01 19:35:09 UTC
Auto-assigned to maintainer mandree@FreeBSD.org
Comment 2 Matthias Andree freebsd_committer 2014-11-18 22:59:36 UTC
forwarded upstream as <https://community.openvpn.net/openvpn/ticket/481#ticket>
Comment 3 Matthias Andree freebsd_committer 2014-11-18 23:01:32 UTC
https://community.openvpn.net/openvpn/ticket/55 might be related.
Comment 4 Matthias Andree freebsd_committer 2014-12-13 19:32:19 UTC
upstream added 2.3.7 as milestone to fix this. some discussion/progress in https://community.openvpn.net/openvpn/ticket/481
Comment 5 commit-hook freebsd_committer 2015-05-22 21:39:52 UTC
A commit references this bug:

Author: mandree
Date: Fri May 22 21:39:39 UTC 2015
New revision: 387083
URL: https://svnweb.freebsd.org/changeset/ports/387083

Log:
  Add experimental patch by Gert D?ring to fix PR #194745.
  Must be enabled through the options framework ("make config").

  PR:		194745

Changes:
  head/security/openvpn/Makefile
  head/security/openvpn/files/EF-subnet.patch
Comment 6 Matthias Andree freebsd_committer 2015-05-22 21:43:23 UTC
Anton,

please:
1. upgrade your ports tree such that you get openvpn 2.3.6_5
2. run "make config" and enable the SUBNETFIX option
3. recompile, reinstall, and see if that fixes the bug for you,
4. report back.

Thank you.
Comment 7 Gert Doering 2015-05-31 14:09:20 UTC
Upstream release 2.3.7 is imminent - it would be nice to hear back whether the fix works for you...
Comment 8 Anton Saietskii 2015-06-01 18:54:52 UTC
I've tested proposed patch, and now host can ping/etc himself. I also have some thoughts:
1. Can exist another way without halving effective address space?
2. Will OpenVPN server know about 2 used addresses by client, eg server=192.168.0.1(+192.168.0.2). First client connects and pulls 192.168.0.3 addr. The second client will get 192.168.0.4 or 192.168.0.5? Unfortunately, I cannot test this right now.
Comment 9 Gert Doering 2015-06-01 19:36:15 UTC
(In reply to Anton Sayetsky from comment #8)

Good to hear that it's working for you.

As far as the "halving effective address space" - it isn't.  This is *subnet* mode, so the whole subnet is always on the tun interface (like, a /24 or /27) - and the "second address" is not used by the client, it's just there to fulfill the requirement "a peer to peer address must be specified that is on the other side of the tun".

As in subnet mode, *all* addresses out of the subnet except the one assigned to the host itself are "on the other side of the tun", this is not actually changing anything - it is just making FreeBSD understand which address is "mine" and which is "someone elses".

As there is no layer 2 resolving (ARP) on a tun interface, all that matters in the end is "which routes are pointing to tun<x>" - and that the other end knows which addresses are "its", and which addresses are "mine".

Yes, it's a hack, but keep that in mind: as long as the client's address is understood to be "local", and all the rest of the subnet is routed into the tun (as single host routes or subnet route), things will do what is needed in subnet mode.

The older --topology net30 mode actually needed a /30 for each client (so you automatically had "local" and "remote" addresses available) - but that still confused people as the "remote" address never pings in point-to-multipoint mode...
Comment 10 Matthias Andree freebsd_committer 2015-06-10 19:19:45 UTC
Port upgraded to 2.3.7 release.
Comment 11 commit-hook freebsd_committer 2015-06-10 19:19:56 UTC
A commit references this bug:

Author: mandree
Date: Wed Jun 10 19:18:57 UTC 2015
New revision: 389128
URL: https://svnweb.freebsd.org/changeset/ports/389128

Log:
  Update to new upstream release 2.3.7.

  Fixes
  PR:		194745

Changes:
  head/security/openvpn/Makefile
  head/security/openvpn/distinfo
  head/security/openvpn/files/EF-subnet.patch
  head/security/openvpn/files/EF1.patch
  head/security/openvpn/files/EF2.patch
  head/security/openvpn/files/EF3.patch