From: tincanteksup <tin...@gm...> - 2019-07-22 17:32:25
|
Hi, I don't have a Tunnelblick client to test with but generally I do have a CentOS7 VM server and it works normally. I notice that you are probably building openvpn yourself so make sure you are building with ./configure --enable-systemd For further troubleshooting, using a higher --verb may be useful. Try --verb 4 and 7. You could also try disabling Negotiated Ciphers --ncp-disable. That's what I would do. On 22/07/2019 17:05, Stephen Reese wrote: > I have a CentOS 7 system in which I have installed OpenVPN 2.4.7. When a > Tunnelbrick client connects, the OpenVPN service Segmentation faults. > Thoughts on how I can troubleshoot? I also tried the EPEL version and 2.4.6 > as well as disabled SELinux and see the same symptoms. Tried the commercial > version and it works fine but would like to use the open-source version. > Here's the the output from the server: > > $ sudo ./openvpn-2.4.7/src/openvpn/openvpn --config > /etc/openvpn/server/domain.conf > Mon Jul 22 15:18:53 2019 OpenVPN 2.4.7 x86_64-pc-linux-gnu [SSL (OpenSSL)] > [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jul 18 2019 > Mon Jul 22 15:18:53 2019 library versions: OpenSSL 1.0.2k-fips 26 Jan > 2017, LZO 2.06 > Mon Jul 22 15:18:53 2019 Diffie-Hellman initialized with 2048 bit key > Mon Jul 22 15:18:53 2019 Outgoing Control Channel Authentication: Using 512 > bit message hash 'SHA512' for HMAC authentication > Mon Jul 22 15:18:53 2019 Incoming Control Channel Authentication: Using 512 > bit message hash 'SHA512' for HMAC authentication > Mon Jul 22 15:18:53 2019 TUN/TAP device tun0 opened > Mon Jul 22 15:18:53 2019 TUN/TAP TX queue length set to 100 > Mon Jul 22 15:18:53 2019 /usr/sbin/ifconfig tun0 172.30.25.1 netmask > 255.255.255.0 mtu 1500 broadcast 172.30.25.255 > Mon Jul 22 15:18:53 2019 Could not determine IPv4/IPv6 protocol. Using > AF_INET > Mon Jul 22 15:18:53 2019 Socket Buffers: R=[212992->212992] > S=[212992->212992] > Mon Jul 22 15:18:53 2019 UDPv4 link local (bound): [AF_INET][undef]:1194 > Mon Jul 22 15:18:53 2019 UDPv4 link remote: [AF_UNSPEC] > Mon Jul 22 15:18:53 2019 GID set to nobody > Mon Jul 22 15:18:53 2019 UID set to nobody > Mon Jul 22 15:18:53 2019 MULTI: multi_init called, r=256 v=256 > Mon Jul 22 15:18:53 2019 IFCONFIG POOL: base=172.30.25.2 size=252, ipv6=0 > Mon Jul 22 15:18:53 2019 IFCONFIG POOL LIST > Mon Jul 22 15:18:53 2019 Initialization Sequence Completed > Mon Jul 22 15:19:03 2019 1.1.1.1:64546 TLS: Initial packet from [AF_INET] > 1.1.1.1:64546, sid=1b685dec f2c923f7 > Mon Jul 22 15:19:03 2019 1.1.1.1:64546 VERIFY OK: depth=1, O=domain.com, CN= > domain.com CA > Mon Jul 22 15:19:03 2019 1.1.1.1:64546 VERIFY OK: depth=0, O=domain.com, > CN=user > Mon Jul 22 15:19:03 2019 1.1.1.1:64546 peer info: IV_VER=2.4.7 > Mon Jul 22 15:19:03 2019 1.1.1.1:64546 peer info: IV_PLAT=mac > Mon Jul 22 15:19:03 2019 1.1.1.1:64546 peer info: IV_PROTO=2 > Mon Jul 22 15:19:03 2019 1.1.1.1:64546 peer info: IV_NCP=2 > Mon Jul 22 15:19:03 2019 1.1.1.1:64546 peer info: IV_LZ4=1 > Mon Jul 22 15:19:03 2019 1.1.1.1:64546 peer info: IV_LZ4v2=1 > Mon Jul 22 15:19:03 2019 1.1.1.1:64546 peer info: IV_LZO=1 > Mon Jul 22 15:19:03 2019 1.1.1.1:64546 peer info: IV_COMP_STUB=1 > Mon Jul 22 15:19:03 2019 1.1.1.1:64546 peer info: IV_COMP_STUBv2=1 > Mon Jul 22 15:19:03 2019 1.1.1.1:64546 peer info: IV_TCPNL=1 > Mon Jul 22 15:19:03 2019 1.1.1.1:64546 peer info: > IV_GUI_VER="net.tunnelblick.tunnelblick_5370_3.8.0__build_5370)" > Mon Jul 22 15:19:04 2019 1.1.1.1:64546 Control Channel: TLSv1.2, cipher > TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA > Mon Jul 22 15:19:04 2019 1.1.1.1:64546 [user] Peer Connection Initiated > with [AF_INET]1.1.1.1:64546 > Mon Jul 22 15:19:04 2019 user/1.1.1.1:64546 MULTI_sva: pool returned > IPv4=172.30.25.2, IPv6=(Not enabled) > Mon Jul 22 15:19:04 2019 user/1.1.1.1:64546 MULTI: Learn: 172.30.25.2 -> > user/1.1.1.1:64546 > Mon Jul 22 15:19:04 2019 user/1.1.1.1:64546 MULTI: primary virtual IP for > user/1.1.1.1:64546: 172.30.25.2 > Mon Jul 22 15:19:05 2019 user/1.1.1.1:64546 PUSH: Received control message: > 'PUSH_REQUEST' > Mon Jul 22 15:19:05 2019 user/1.1.1.1:64546 SENT CONTROL [user]: > 'PUSH_REPLY,route-gateway 172.30.25.1,topology subnet,ping 10,ping-restart > 120,ifconfig 172.30.25.2 255.255.255.0,peer-id 0,cipher AES-256-GCM' > (status=1) > Mon Jul 22 15:19:05 2019 user/1.1.1.1:64546 Data Channel: using negotiated > cipher 'AES-256-GCM' > Segmentation fault > > Here's the server configuration: > > port 1194 > proto udp > dev tun > ca /etc/openvpn/server/domain/ca.crt > cert /etc/openvpn/server/domain/server.crt > key /etc/openvpn/server/domain/server.key > dh /etc/openvpn/server/domain/dh2048.pem > tls-auth /etc/openvpn/server/domain/ta.key 0 > #plugin /usr/lib64/openvpn/plugin/lib/openvpn-auth-ldap.so > "/etc/openvpn/auth/freeipa.conf" > ifconfig-pool-persist /etc/openvpn/server/domain/ipp.txt > topology subnet > server 172.30.25.0 255.255.255.0 > keepalive 10 120 > max-clients 25 > user nobody > group nobody > persist-key > persist-tun > status /var/log/openvpn-status.log > verb 3 > tls-version-min 1.2 > auth SHA512 > cipher AES-256-CBC > reneg-sec 14400 > tun-mtu 1500 > > Here's the client configuration: > > client > dev tun > tls-client > ping 10 > ping-restart 120 > proto udp > remote 1.1.1.1 1194 udp > resolv-retry infinite > nobind > persist-key > persist-tun > ca ca.crt > cert user.crt > key user.key > tls-auth ta.key 1 > auth SHA512 > cipher AES-256-CBC > keysize 256 > > > > _______________________________________________ > Openvpn-users mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-users > |