Bug 194745
| Summary: | security/openvpn: incorrect self route when using subnet topology | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Anton Saietskii <vsasjason> |
| Component: | Individual Port(s) | Assignee: | Matthias Andree <mandree> |
| Status: | Closed FIXED | ||
| Severity: | Affects Some People | CC: | gert |
| Priority: | --- | Flags: | vsasjason:
maintainer-feedback?
(mandree) |
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
Auto-assigned to maintainer mandree@FreeBSD.org forwarded upstream as <https://community.openvpn.net/openvpn/ticket/481#ticket> https://community.openvpn.net/openvpn/ticket/55 might be related. upstream added 2.3.7 as milestone to fix this. some discussion/progress in https://community.openvpn.net/openvpn/ticket/481 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 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. Upstream release 2.3.7 is imminent - it would be nice to hear back whether the fix works for you... 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. (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... Port upgraded to 2.3.7 release. 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 |
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:~$