Date: Thu, 02 Jun 2016 22:08:02 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-amd64@FreeBSD.org Subject: [Bug 207831] r293159 breaks OpenVPN routing Message-ID: <bug-207831-6-Ax49Z6MDm5@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-207831-6@https.bugs.freebsd.org/bugzilla/> References: <bug-207831-6@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207831 --- Comment #8 from guyyur@gmail.com --- Oliver, Did you try to connect with more than one openvpn client? For me the problem was only seen when the second client tried to connect. The first client got the address assigned to the remote side of the tunnel and there is a correct route for it. The second client got an address that required using the /24 route which incorrectly leads to lo0. Bad route for 192.168.170.0/24 with r293159: # netstat -rnf inet | grep -e Destination -e 192.168.170 Destination Gateway Flags Netif Expire 192.168.170.0/24 192.168.170.1 UGS lo0 192.168.170.1 link#4 UHS lo0 192.168.170.2 link#4 UH tun0 Good route for 192.168.170.0/24 with r293159 rtsock.c changes reverted: # netstat -rnf inet | grep -e Destination -e 192.168.170 Destination Gateway Flags Netif Expire 192.168.170.0/24 192.168.170.1 UGS tun0 192.168.170.1 link#4 UHS lo0 192.168.170.2 link#4 UH tun0 # ifconfig tun0 inet tun0: flags=3D8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500 options=3D80000<LINKSTATE> inet 192.168.170.1 --> 192.168.170.2 netmask 0xffffff00 Opened by PID 671 You can also manually create the tunnel and route to compare 10.3-RELEASE to 11-CURRENT: ifconfig tun0 create ifconfig tun0 192.168.170.1 192.168.170.2 mtu 1500 netmask 255.255.255.0 up route add -net 192.168.170.0 192.168.170.1 255.255.255.0 --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-207831-6-Ax49Z6MDm5>