Opened 4 years ago

Closed 4 years ago

#713 closed Bug / Defect (worksforme)

debian jessie server-bridge pushes routes to clients no more

Reported by: uulysr Owned by:
Priority: major Milestone:
Component: Generic / unclassified Version: OpenVPN 2.3.4 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords: no pushing routes to clients
Cc:

Description

OS: Linux 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) i686 GNU/Linux


OpenVPN: 2.3.4-5+deb8u1


Server conf (network part):
dev tap_at
server-bridge 192.168.30.186 255.255.255.192 192.168.30.129 192.168.30.190
local XX.XX.XX.XX
port XXXXX
proto udp
# ROUTING
client-to-client
ifconfig-pool-persist config/arc_at_clnts/ip.txt
client-config-dir config/arc_at_clnts


Server sided client conf:
ifconfig-push 192.168.30.131 255.255.255.192
push "route 10.255.252.0 255.255.254.0"


Local net:
eth0 Link encap:Ethernet HWaddr 04:7d:7b:e9:b2:98

inet addr:192.168.30.195 Bcast:192.168.30.223 Mask:255.255.255.224


Issue:
A server-bridge pushes no more client's adress and routes from server sided client configuration. WITHOUT ANY changes in configuration both the server and the client(s).
I stopped the server and entered right client's address into the file config/arc_at_clnts/ip.txt, mentioned above in server configuration. After that client started to get right address. But no routes any way.
The same issue I wathched on Debian Stretch in March, 2016.


Log on server:
Thu Jul 21 18:05:53 2016 188.143.146.174:63011 TLS: Initial packet from [AF_INET]188.143.146.174:63011, sid=d5265ef9 e282c6ce
Thu Jul 21 18:05:53 2016 188.143.146.174:63011 NOTE: --mute triggered...
Thu Jul 21 18:05:53 2016 188.143.146.174:63011 7 variation(s) on previous 1 message(s) suppressed by --mute
Thu Jul 21 18:05:53 2016 188.143.146.174:63011 [al_puppy] Peer Connection Initiated with [AF_INET]188.143.146.174:63011
Thu Jul 21 18:05:53 2016 al_puppy/188.143.146.174:63011 MULTI_sva: pool returned IPv4=192.168.30.131, IPv6=(Not enabled)
Thu Jul 21 18:05:55 2016 al_puppy/188.143.146.174:63011 PUSH: Received control message: 'PUSH_REQUEST'
Thu Jul 21 18:05:55 2016 al_puppy/188.143.146.174:63011 send_push_reply(): safe_cap=940
Thu Jul 21 18:05:55 2016 al_puppy/188.143.146.174:63011 SENT CONTROL [al_puppy]: 'PUSH_REPLY,route-gateway 192.168.30.186,ping 60,ping-restart 300,ifconfig 192.168.30.131 255.255.255.192' (status=1)
Thu Jul 21 18:05:55 2016 al_puppy/188.143.146.174:63011 MULTI: Learn: 12:a7:87:95:88:e9 -> al_puppy/188.143.146.174:63011


Log on client:
Fri Jul 22 00:07:38 2016 OpenVPN 2.3.4 i586-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Nov 19 2015
Fri Jul 22 00:07:38 2016 library versions: OpenSSL 1.0.1t 3 May 2016, LZO 2.08
Fri Jul 22 00:07:38 2016 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
Fri Jul 22 00:07:38 2016 Control Channel Authentication: using '/etc/openvpn/2arc_ring/arc01_at_ta.key' as a OpenVPN static key file
Fri Jul 22 00:07:38 2016 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Jul 22 00:07:38 2016 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Jul 22 00:07:38 2016 Socket Buffers: R=[163840->131072] S=[163840->131072]
Fri Jul 22 00:07:38 2016 NOTE: chroot will be delayed because of --client, --pull, or --up-delay
Fri Jul 22 00:07:38 2016 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Fri Jul 22 00:07:38 2016 UDPv4 link local (bound): [undef]
Fri Jul 22 00:07:38 2016 UDPv4 link remote: [AF_INET]31.184.195.195:63011
Fri Jul 22 00:07:38 2016 TLS: Initial packet from [AF_INET]31.184.195.195:63011, sid=1c08f1b4 05c29d06
Fri Jul 22 00:07:38 2016 VERIFY OK: depth=1, C=RU, ST=NW, L=Sankt-Petersburg, O=ARC Technologies, OU=VWP, CN=arctech.ru, name=arc3_at, emailAddress=alexi@…
Fri Jul 22 00:07:38 2016 VERIFY OK: depth=0, C=RU, ST=NW, L=Sankt-Petersburg, O=ARC Technologies, OU=VWP, CN=arctech.ru, name=arc3_at, emailAddress=alexi@…
Fri Jul 22 00:07:38 2016 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Jul 22 00:07:38 2016 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Jul 22 00:07:38 2016 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Jul 22 00:07:38 2016 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Jul 22 00:07:38 2016 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Fri Jul 22 00:07:38 2016 [arctech.ru] Peer Connection Initiated with [AF_INET]31.184.195.195:63011
Fri Jul 22 00:07:40 2016 SENT CONTROL [arctech.ru]: 'PUSH_REQUEST' (status=1)
Fri Jul 22 00:07:40 2016 PUSH: Received control message: 'PUSH_REPLY,route-gateway 192.168.30.186,ping 60,ping-restart 300,ifconfig 192.168.30.131 255.255.255.192'
Fri Jul 22 00:07:40 2016 OPTIONS IMPORT: timers and/or timeouts modified
Fri Jul 22 00:07:40 2016 OPTIONS IMPORT: --ifconfig/up options modified
Fri Jul 22 00:07:40 2016 OPTIONS IMPORT: route-related options modified
Fri Jul 22 00:07:40 2016 TUN/TAP device tap_2ring opened
Fri Jul 22 00:07:40 2016 TUN/TAP TX queue length set to 100
Fri Jul 22 00:07:40 2016 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Fri Jul 22 00:07:40 2016 /sbin/ip link set dev tap_2ring up mtu 1500
Fri Jul 22 00:07:40 2016 /sbin/ip addr add dev tap_2ring 192.168.30.131/26 broadcast 192.168.30.191
Thu Jul 21 21:07:40 2016 chroot to '/etc/openvpn' and cd to '/' succeeded
Thu Jul 21 21:07:40 2016 GID set to nogroup
Thu Jul 21 21:07:40 2016 UID set to nobody
Thu Jul 21 21:07:40 2016 Initialization Sequence Completed

No route pushing attempts in the both log files!!!
Even more. I tried to add script to systemd openvpn@… to add routes locally. No attempts to execute the script in the both logs either.
Any suggestions???

Change History (3)

comment:1 Changed 4 years ago by Gert Döring

I'd assume that the server cannot read the client config file - some permission change, user ID change that OpenVPN runs under, etc., and it can't find/access config/arc_at_clnts/al_puppy anymore.

If you run the server with --verb 7 (just for a test connect) it will tell you whether it could open the client-config file - look for "TEST FILE" in the log. (If it's a permission problem - EACCESS - it should actually log the fact - so this sounds more like "there just is no file that is named as the client CN in the directory you have specified").

comment:2 Changed 4 years ago by Steffan Karger

Milestone: release 2.3.4

comment:3 Changed 4 years ago by Gert Döring

Resolution: worksforme
Status: newclosed

If we ask for logs, and none are provided, we can't do much here. Closing.

(One possible reason for the server not pushing routes is that it needs to have a gateway address if using tap mode... it should log that with a higher verbosity. Or just try making the statement push "route 10.255.252.0 255.255.254.0 192.168.30.195" and see if that fixes it. But without logs, just random stabs in the dark)

Note: See TracTickets for help on using tickets.