https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207831
--- Comment #8 from guy...@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=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
options=80000<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
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
freebsd-amd64@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-amd64
To unsubscribe, send any mail to "freebsd-amd64-unsubscr...@freebsd.org"
