OpenVPN puts subnet on lo0 on FreeBSD 11, breaks in certain cases
openvpn - UDP/TUN (TAP works)
clients connect to server, in the logs everything is fine, but no access anywhere.
without "ifconfig-push" it works
from server log when a client connects:
MULTI_sva: pool returned IPv4=10.0.7.2
as it should be without "ifconfig-push"
but i push 10.0.7.100 and client gets 10.0.7.100
#1 Updated by Jim Pingle almost 3 years ago
- Category set to OpenVPN
- Status changed from New to Feedback
- Priority changed from High to Normal
Unless this was a working configuration on a previous version, it's more likely to be a configuration error. There is not nearly enough detail here about the specifics of the setup or how to duplicate the problem.
#2 Updated by Dmitry Ivanov almost 3 years ago
it works on 2.3.*
i installed 2.4, and restored config from 2.3.3
openvpn server UDP/TUN
Server mode - Remote Access (User Auth)
tunnel network - 10.0.7.0/24
in "client specific overrides" i added only "ifconfig-push 10.0.7.100 255.255.255.0;" for a single user. this user (windows client or android... does not matter) connects and gets this ip. but have no access.
other users without "ifconfig-push" are working fine.
#4 Updated by Dmitry Ivanov almost 3 years ago
keepalive 10 60
server 10.0.7.0 255.255.255.0
auth-user-pass-verify "/usr/local/sbin/ovpn_auth_verify user 'Local Database' false server7 1200" via-env
management /var/etc/openvpn/server7.sock unix
push "route 10.10.96.0 255.255.240.0"
push "dhcp-option DOMAIN gormost.lan"
push "dhcp-option DNS 10.10.111.1"
push "dhcp-option WINS 10.10.111.1"
#6 Updated by Jim Pingle almost 3 years ago
- Subject changed from OpenVPN "ifconfig-push" drop all traffic on client to OpenVPN puts subnet on lo0 on FreeBSD 11, breaks in certain cases
- Target version set to 2.4.0
I ran some tests and can confirm the issue on 2.4 only.
2.3.3 and 2.4 run the same version of OpenVPN and have identical options for compiling the port, but behave differently at runtime.
The generated configurations we make are identical, but the only difference I see is in the routing table.
10.5.201.0/24 10.5.201.1 UGS ovpns1 10.5.201.1 link#8 UHS lo0 10.5.201.2 link#8 UH ovpns1
10.7.100.0/24 10.7.100.1 UGS lo0 10.7.100.1 link#11 UHS lo0 10.7.100.2 link#11 UH ovpns1
Given the other routing changes, I wonder if this might be related to #6828 in some way.
#8 Updated by Jim Pingle almost 3 years ago
This appears to be a general problem with OpenVPN on FreeBSD 11:
There is a workaround mentioned among the problem reports of removing the route and manually re-adding it, but it's not ideal. It needs a proper fix either in OpenVPN or FreeBSD. It looks as though it's getting some recent attention from both camps, hopefully that results in a solution we can use soon.
#10 Updated by Renato Botelho almost 3 years ago
- Status changed from Confirmed to Feedback
I've imported a patch from OpenVPN development list:
Next round of snapshots, with OpenVPN 2.3.12_2 will have it