Please post your server and client log files... you need to also disconnect, then reconnect, the client(s)@zoomzoom I just tried it and restarted the jail... still no luck
topology subnet
, as net30 was depreciated years ago.Apr 24 17:53:39 OpenVPN rtsold[14438]: <rtsock_input_ifannounce> interface epair0b removed Apr 24 17:53:39 OpenVPN openvpn[14375]: event_wait : Interrupted system call (code=4) Apr 24 17:53:39 OpenVPN openvpn[14375]: /sbin/route delete -net 172.16.8.0 172.16.8.2 255.255.255.0 Apr 24 17:53:39 OpenVPN openvpn[14375]: ERROR: FreeBSD route delete command failed: external program exited with error status: 77 Apr 24 17:53:39 OpenVPN openvpn[14375]: Closing TUN/TAP interface Apr 24 17:53:39 OpenVPN openvpn[14375]: /sbin/ifconfig tun0 destroy Apr 24 17:53:39 OpenVPN openvpn[14375]: FreeBSD 'destroy tun interface' failed (non-critical): external program exited with error status: 1 Apr 24 17:53:39 OpenVPN openvpn[14375]: SIGTERM[hard,] received, process exiting Apr 24 17:53:39 OpenVPN syslogd: exiting on signal 15 Apr 24 17:53:43 OpenVPN syslogd: kernel boot file is /boot/kernel/kernel Apr 24 17:53:43 OpenVPN openvpn[17092]: OpenVPN 2.4.1 amd64-portbld-freebsd10.3 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Apr 13 2017 Apr 24 17:53:43 OpenVPN openvpn[17092]: library versions: OpenSSL 1.0.1s-freebsd 1 Mar 2016, LZO 2.10 Apr 24 17:53:43 OpenVPN openvpn[17093]: NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x. Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet. Apr 24 17:53:43 OpenVPN openvpn[17093]: Diffie-Hellman initialized with 2048 bit key Apr 24 17:53:43 OpenVPN openvpn[17093]: Failed to extract curve from certificate (UNDEF), using secp384r1 instead. Apr 24 17:53:43 OpenVPN openvpn[17093]: ECDH curve secp384r1 added Apr 24 17:53:43 OpenVPN openvpn[17093]: Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Apr 24 17:53:43 OpenVPN openvpn[17093]: Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Apr 24 17:53:43 OpenVPN openvpn[17093]: ROUTE_GATEWAY 192.168.1.1/255.255.255.0 IFACE=epair0b HWADDR=e6:e0:f3:99:d3:4a Apr 24 17:53:43 OpenVPN openvpn[17093]: TUN/TAP device /dev/tun0 opened Apr 24 17:53:43 OpenVPN openvpn[17093]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0 Apr 24 17:53:43 OpenVPN openvpn[17093]: /sbin/ifconfig tun0 172.16.8.1 172.16.8.2 mtu 1500 netmask 255.255.255.255 up Apr 24 17:53:43 OpenVPN openvpn[17093]: /sbin/route add -net 172.16.8.0 172.16.8.2 255.255.255.0 Apr 24 17:53:43 OpenVPN openvpn[17093]: Could not determine IPv4/IPv6 protocol. Using AF_INET6 Apr 24 17:53:43 OpenVPN openvpn[17093]: Socket Buffers: R=[42080->42080] S=[9216->9216] Apr 24 17:53:43 OpenVPN openvpn[17093]: setsockopt(IPV6_V6ONLY=0) Apr 24 17:53:43 OpenVPN openvpn[17093]: UDPv6 link local (bound): [AF_INET6][undef]:1194 Apr 24 17:53:43 OpenVPN openvpn[17093]: UDPv6 link remote: [AF_UNSPEC] Apr 24 17:53:43 OpenVPN openvpn[17093]: GID set to nobody Apr 24 17:53:43 OpenVPN openvpn[17093]: UID set to nobody Apr 24 17:53:43 OpenVPN openvpn[17093]: MULTI: multi_init called, r=256 v=256 Apr 24 17:53:43 OpenVPN openvpn[17093]: IFCONFIG POOL: base=172.16.8.4 size=62, ipv6=0 Apr 24 17:53:43 OpenVPN openvpn[17093]: ifconfig_pool_read(), in='myMac,172.16.8.4', TODO: IPv6 Apr 24 17:53:43 OpenVPN openvpn[17093]: succeeded -> ifconfig_pool_set() Apr 24 17:53:43 OpenVPN openvpn[17093]: IFCONFIG POOL LIST Apr 24 17:53:43 OpenVPN openvpn[17093]: myMac,172.16.8.4 Apr 24 17:53:43 OpenVPN openvpn[17093]: Initialization Sequence Completed Apr 24 17:54:06 OpenVPN openvpn[17093]: x.x.x.x TLS: Initial packet from [AF_INET6]::ffff:x.x.x.x:35706, sid=f5e8b3b4 e78e0579 Apr 24 17:54:06 OpenVPN openvpn[17093]: x.x.x.x VERIFY OK: depth=1, CN=myMac CA Apr 24 17:54:06 OpenVPN openvpn[17093]: x.x.x.x VERIFY OK: depth=0, CN=myMac Apr 24 17:54:06 OpenVPN openvpn[17093]: x.x.x.x peer info: IV_VER=2.3.12 Apr 24 17:54:06 OpenVPN openvpn[17093]: x.x.x.x peer info: IV_PLAT=mac Apr 24 17:54:06 OpenVPN openvpn[17093]: x.x.x.x peer info: IV_PROTO=2 Apr 24 17:54:06 OpenVPN openvpn[17093]: x.x.x.x Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key Apr 24 17:54:06 OpenVPN openvpn[17093]: x.x.x.x Data Channel Encrypt: Using 256 bit message hash 'SHA256' for HMAC authentication Apr 24 17:54:06 OpenVPN openvpn[17093]: x.x.x.x Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key Apr 24 17:54:06 OpenVPN openvpn[17093]: x.x.x.x Data Channel Decrypt: Using 256 bit message hash 'SHA256' for HMAC authentication Apr 24 17:54:07 OpenVPN openvpn[17093]: x.x.x.x Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA Apr 24 17:54:07 OpenVPN openvpn[17093]: x.x.x.x [myMac] Peer Connection Initiated with [AF_INET6]::ffff:x.x.x.x:35706 Apr 24 17:54:07 OpenVPN openvpn[17093]: myMac/x.x.x.x MULTI_sva: pool returned IPv4=172.16.8.6, IPv6=(Not enabled) Apr 24 17:54:07 OpenVPN openvpn[17093]: myMac/x.x.x.x MULTI: Learn: 172.16.8.6 -> myMac/x.x.x.x Apr 24 17:54:07 OpenVPN openvpn[17093]: myMac/x.x.x.x MULTI: primary virtual IP for myMac/x.x.x.x: 172.16.8.6 Apr 24 17:54:09 OpenVPN openvpn[17093]: myMac/x.x.x.x PUSH: Received control message: 'PUSH_REQUEST' Apr 24 17:54:09 OpenVPN openvpn[17093]: myMac/x.x.x.x SENT CONTROL [myMac]: 'PUSH_REPLY,route 192.168.1.0 255.255.255.0,route 172.16.8.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 172.16.8.6 172.16.8.5,peer-id 0' (status=1)
2017-04-24 17:54:05 OpenVPN 2.3.12 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [PKCS11] [MH] [IPv6] built on Oct 9 2016 2017-04-24 17:54:05 library versions: OpenSSL 1.0.2j 26 Sep 2016, LZO 2.09 2017-04-24 17:54:05 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:1337 2017-04-24 17:54:05 Need hold release from management interface, waiting... 2017-04-24 17:54:05 *Tunnelblick: openvpnstart starting OpenVPN 2017-04-24 17:54:06 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:1337 2017-04-24 17:54:06 *Tunnelblick: Established communication with OpenVPN 2017-04-24 17:54:06 MANAGEMENT: CMD 'pid' 2017-04-24 17:54:06 MANAGEMENT: CMD 'state on' 2017-04-24 17:54:06 MANAGEMENT: CMD 'state' 2017-04-24 17:54:06 MANAGEMENT: CMD 'bytecount 1' 2017-04-24 17:54:06 MANAGEMENT: CMD 'hold release' 2017-04-24 17:54:06 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts 2017-04-24 17:54:06 Control Channel Authentication: using 'ta.key' as a OpenVPN static key file 2017-04-24 17:54:06 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication 2017-04-24 17:54:06 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication 2017-04-24 17:54:06 Socket Buffers: R=[196724->196724] S=[9216->9216] 2017-04-24 17:54:06 MANAGEMENT: >STATE:1493045646,RESOLVE,,, 2017-04-24 17:54:06 UDPv4 link local: [undef] 2017-04-24 17:54:06 UDPv4 link remote: [AF_INET]x.x.x.x:1194 2017-04-24 17:54:06 MANAGEMENT: >STATE:1493045646,WAIT,,, 2017-04-24 17:54:06 MANAGEMENT: >STATE:1493045646,AUTH,,, 2017-04-24 17:54:06 TLS: Initial packet from [AF_INET]x.x.x.x:1194, sid=d8d9b4a1 9d768cf6 2017-04-24 17:54:06 VERIFY OK: depth=1, CN=myMac CA 2017-04-24 17:54:06 Validating certificate key usage 2017-04-24 17:54:06 ++ Certificate has key usage 00a0, expects 00a0 2017-04-24 17:54:06 VERIFY KU OK 2017-04-24 17:54:06 Validating certificate extended key usage 2017-04-24 17:54:06 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication 2017-04-24 17:54:06 VERIFY EKU OK 2017-04-24 17:54:06 VERIFY OK: depth=0, CN=openvpn-server 2017-04-24 17:54:07 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key 2017-04-24 17:54:07 Data Channel Encrypt: Using 256 bit message hash 'SHA256' for HMAC authentication 2017-04-24 17:54:07 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key 2017-04-24 17:54:07 Data Channel Decrypt: Using 256 bit message hash 'SHA256' for HMAC authentication 2017-04-24 17:54:07 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA 2017-04-24 17:54:07 [openvpn-server] Peer Connection Initiated with [AF_INET]x.x.x.x:1194 2017-04-24 17:54:08 MANAGEMENT: >STATE:1493045648,GET_CONFIG,,, 2017-04-24 17:54:09 SENT CONTROL [openvpn-server]: 'PUSH_REQUEST' (status=1) 2017-04-24 17:54:09 PUSH: Received control message: 'PUSH_REPLY,route 192.168.1.0 255.255.255.0,route 172.16.8.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 172.16.8.6 172.16.8.5,peer-id 0' 2017-04-24 17:54:09 OPTIONS IMPORT: timers and/or timeouts modified 2017-04-24 17:54:09 OPTIONS IMPORT: --ifconfig/up options modified 2017-04-24 17:54:09 OPTIONS IMPORT: route options modified 2017-04-24 17:54:09 OPTIONS IMPORT: peer-id set 2017-04-24 17:54:09 OPTIONS IMPORT: adjusting link_mtu to 1573 2017-04-24 17:54:09 Opening utun (connect(AF_SYS_CONTROL)): Resource busy 2017-04-24 17:54:09 Opened utun device utun1 2017-04-24 17:54:09 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 2017-04-24 17:54:09 MANAGEMENT: >STATE:1493045649,ASSIGN_IP,,172.16.8.6, 2017-04-24 17:54:09 /sbin/ifconfig utun1 delete ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address 2017-04-24 17:54:09 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure 2017-04-24 17:54:09 /sbin/ifconfig utun1 172.16.8.6 172.16.8.5 mtu 1500 netmask 255.255.255.255 up
It appears Apple client logs are different than other OSes, so what I noticed may simply be due to it being an Apple OS, however, before I get into that, I overlooked something in your configs....
openvpn --show-tls
and ensure the ciphers below are listed in the output on both your server and client. tls-cipher 'TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384:TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:TLS-ECDH-RSA-WITH-AES-256-GCM-SHA384:TLS-ECDH-RSA-WITH-AES-256-CBC-SHA384:TLS-RSA-WITH-AES-256-GCM-SHA384:TLS-RSA-WITH-AES-256-CBC-SHA256:!aNULL:!eNULL:!LOW:!3DES:!MD5:!SHA:!EXP:!PSK:!SRP:!DSS:!RC4'
proto tcp
. tls-version-min 1.2
[root@OpenVPN /]# ipfw list
00100 nat 1 ip from 172.16.8.0/24 to any out via epair0b
00200 nat 1 ip from any to any in via epair0b
65535 allow ip from any to any
[root@OpenVPN /]# ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet 127.0.0.1 netmask 0xff000000
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
epair0b: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8<VLAN_MTU>
ether e6:e0:f3:99:d3:4a
inet 192.168.1.55 netmask 0xffffff00 broadcast 192.168.1.255
inet6 fe80::e4e0:f3ff:fe99:d34a%epair0b prefixlen 64 scopeid 0x2
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
status: active
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
options=80000<LINKSTATE>
inet 172.16.8.1 --> 172.16.8.2 netmask 0xffffff00
nd6 options=9<PERFORMNUD,IFDISABLED>
The exclusions are supported, but there's a bug that reports the log output you're seeing for those exclusion ciphers. OpenVPN devs are aware of it and will eventually patch the bug, but its low priority since it's not an actual issue and has no effect, it's just erroneous log output for the exclusion ciphers only.After I added the ciphers (without TLS-ECDH-RSA-WITH-AES-256-GCM-SHA384:TLS-ECDH-RSA-WITH-AES-256-CBC-SHA384:TLS-RSA-WITH-AES-256-GCM-SHA384:TLS-RSA-WITH-AES-256-CBC-SHA256 since they are not supported on both server and client, also apparently the exclusion ones too, as the log shows):
Server: https://pastebin.com/K2xTN8CL
Client: https://pastebin.com/vieFQe5A
Changed udp to tcp:
Server: https://pastebin.com/5GntgXQb
Client: https://pastebin.com/3y42UJiU
...This is really frustrating
# Server Log # #-------------------- # Client Connection request: Apr 24 20:12:51 OpenVPN openvpn[28351]: x.x.x.x [myMac] Peer Connection Initiated with [AF_INET6]::ffff:x.x.x.x:33559 Apr 24 20:12:51 OpenVPN openvpn[28351]: myMac/x.x.x.x MULTI_sva: pool returned IPv4=172.16.8.4, IPv6=(Not enabled) Apr 24 20:12:51 OpenVPN openvpn[28351]: myMac/x.x.x.x MULTI: Learn: 172.16.8.4 -> myMac/x.x.x.x Apr 24 20:12:51 OpenVPN openvpn[28351]: myMac/x.x.x.x MULTI: primary virtual IP for myMac/x.x.x.x: 172.16.8.4 Apr 24 20:12:52 OpenVPN openvpn[28351]: myMac/x.x.x.x PUSH: Received control message: 'PUSH_REQUEST' Apr 24 20:12:52 OpenVPN openvpn[28351]: myMac/x.x.x.x SENT CONTROL [myMac]: 'PUSH_REPLY,route 192.168.1.0 255.255.255.0,route-gateway 172.16.8.1,topology subnet,ping 10,ping-restart 120,ifconfig 172.16.8.4 255.255.255.0,peer-id 0,cipher AES-256-GCM' (status=1) Apr 24 20:12:52 OpenVPN openvpn[28351]: myMac/x.x.x.x Data Channel MTU parms [ L:1552 D:1450 EF:52 EB:406 ET:0 EL:3 ] Apr 24 20:12:52 OpenVPN openvpn[28351]: myMac/x.x.x.x Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key Apr 24 20:12:52 OpenVPN openvpn[28351]: myMac/x.x.x.x Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
# Client Log # #-------------------- # Connection with IPv6 : Mon Apr 24 20:12:53 2017 us=1130 Opening utun (connect(AF_SYS_CONTROL)): Resource busy Mon Apr 24 20:12:53 2017 us=2278 Opened utun device utun1 Mon Apr 24 20:12:53 2017 us=4175 do_ifconfig, tt->did_ifconfig_ipv6_setup=0 Mon Apr 24 20:12:53 2017 us=5286 MANAGEMENT: >STATE:1493053973,ASSIGN_IP,,172.16.8.4,,,, Mon Apr 24 20:12:53 2017 us=6816 /sbin/ifconfig utun1 delete # Then this error: ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address Mon Apr 24 20:12:53 2017 us=145454 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure Mon Apr 24 20:12:53 2017 us=146863 /sbin/ifconfig utun1 172.16.8.4 172.16.8.4 netmask 255.255.255.0 mtu 1500 up Mon Apr 24 20:12:53 2017 us=153270 /sbin/route add -net 172.16.8.0 172.16.8.4 255.255.255.0 add net 172.16.8.0: gateway 172.16.8.4 Mon Apr 24 20:12:53 2017 us=166752 /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw utun1 1500 1555 172.16.8.4 255.255.255.0 init # Connection Successful: # Why is there a 128.0.0.0 (loopback?) address? Is this specific to Macs? Mon Apr 24 20:12:58 2017 us=694193 /sbin/route add -net 0.0.0.0 172.16.8.1 128.0.0.0 add net 0.0.0.0: gateway 172.16.8.1 Mon Apr 24 20:12:58 2017 us=697584 /sbin/route add -net 128.0.0.0 172.16.8.1 128.0.0.0 add net 128.0.0.0: gateway 172.16.8.1 Mon Apr 24 20:12:58 2017 us=701216 MANAGEMENT: >STATE:1493053978,ADD_ROUTES,,,,,, Mon Apr 24 20:12:58 2017 us=701524 /sbin/route add -net 192.168.1.0 172.16.8.1 255.255.255.0 add net 192.168.1.0: gateway 172.16.8.1 Mon Apr 24 20:12:58 2017 us=705887 Initialization Sequence Completed Mon Apr 24 20:12:58 2017 us=706188 MANAGEMENT: >STATE:1493053978,CONNECTED,SUCCESS,172.16.8.4,x.x.x.x,1194,172.20.10.2,57923
The exclusions are supported, but there's a bug that reports the log output you're seeing for those exclusion ciphers. OpenVPN devs are aware of it and will eventually patch the bug, but its low priority since it's not an actual issue and has no effect, it's just erroneous log output for the exclusion ciphers only.
You're showing IPv6 addresses in your log output, which shouldn't be there. You can use IPv6 in OpenVPN, but there's additional config options that must be set... this is similar to a log another user posted somewhere in the last few pages where I saw the same thing and recommended they try the OpenVPN forum, as I've never seen IPv6 addresses in any server I've set up.
My suspicion is your issue is firewall/network related, not OpenVPN related.
Server Log
Code:# Server Log # #-------------------- # Client Connection request: Apr 24 20:12:51 OpenVPN openvpn[28351]: x.x.x.x [myMac] Peer Connection Initiated with [AF_INET6]::ffff:x.x.x.x:33559 Apr 24 20:12:51 OpenVPN openvpn[28351]: myMac/x.x.x.x MULTI_sva: pool returned IPv4=172.16.8.4, IPv6=(Not enabled) Apr 24 20:12:51 OpenVPN openvpn[28351]: myMac/x.x.x.x MULTI: Learn: 172.16.8.4 -> myMac/x.x.x.x Apr 24 20:12:51 OpenVPN openvpn[28351]: myMac/x.x.x.x MULTI: primary virtual IP for myMac/x.x.x.x: 172.16.8.4 Apr 24 20:12:52 OpenVPN openvpn[28351]: myMac/x.x.x.x PUSH: Received control message: 'PUSH_REQUEST' Apr 24 20:12:52 OpenVPN openvpn[28351]: myMac/x.x.x.x SENT CONTROL [myMac]: 'PUSH_REPLY,route 192.168.1.0 255.255.255.0,route-gateway 172.16.8.1,topology subnet,ping 10,ping-restart 120,ifconfig 172.16.8.4 255.255.255.0,peer-id 0,cipher AES-256-GCM' (status=1) Apr 24 20:12:52 OpenVPN openvpn[28351]: myMac/x.x.x.x Data Channel MTU parms [ L:1552 D:1450 EF:52 EB:406 ET:0 EL:3 ] Apr 24 20:12:52 OpenVPN openvpn[28351]: myMac/x.x.x.x Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key Apr 24 20:12:52 OpenVPN openvpn[28351]: myMac/x.x.x.x Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Client Log
Code:# Client Log # #-------------------- # Connection with IPv6 : Mon Apr 24 20:12:53 2017 us=1130 Opening utun (connect(AF_SYS_CONTROL)): Resource busy Mon Apr 24 20:12:53 2017 us=2278 Opened utun device utun1 Mon Apr 24 20:12:53 2017 us=4175 do_ifconfig, tt->did_ifconfig_ipv6_setup=0 Mon Apr 24 20:12:53 2017 us=5286 MANAGEMENT: >STATE:1493053973,ASSIGN_IP,,172.16.8.4,,,, Mon Apr 24 20:12:53 2017 us=6816 /sbin/ifconfig utun1 delete # Then this error: ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address Mon Apr 24 20:12:53 2017 us=145454 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure Mon Apr 24 20:12:53 2017 us=146863 /sbin/ifconfig utun1 172.16.8.4 172.16.8.4 netmask 255.255.255.0 mtu 1500 up Mon Apr 24 20:12:53 2017 us=153270 /sbin/route add -net 172.16.8.0 172.16.8.4 255.255.255.0 add net 172.16.8.0: gateway 172.16.8.4 Mon Apr 24 20:12:53 2017 us=166752 /Applications/Tunnelblick.app/Contents/Resources/client.up.tunnelblick.sh -9 -d -f -m -w -ptADGNWradsgnw utun1 1500 1555 172.16.8.4 255.255.255.0 init # Connection Successful: # Why is there a 128.0.0.0 (loopback?) address? Is this specific to Macs? Mon Apr 24 20:12:58 2017 us=694193 /sbin/route add -net 0.0.0.0 172.16.8.1 128.0.0.0 add net 0.0.0.0: gateway 172.16.8.1 Mon Apr 24 20:12:58 2017 us=697584 /sbin/route add -net 128.0.0.0 172.16.8.1 128.0.0.0 add net 128.0.0.0: gateway 172.16.8.1 Mon Apr 24 20:12:58 2017 us=701216 MANAGEMENT: >STATE:1493053978,ADD_ROUTES,,,,,, Mon Apr 24 20:12:58 2017 us=701524 /sbin/route add -net 192.168.1.0 172.16.8.1 255.255.255.0 add net 192.168.1.0: gateway 172.16.8.1 Mon Apr 24 20:12:58 2017 us=705887 Initialization Sequence Completed Mon Apr 24 20:12:58 2017 us=706188 MANAGEMENT: >STATE:1493053978,CONNECTED,SUCCESS,172.16.8.4,x.x.x.x,1194,172.20.10.2,57923
You can try increasing the server verbosity up to 5 or 6 to be sure, as anything 5 or above for the server will show r/w requests from clients. If it doesn't show any, it's likely a firewall/network issue.
- You may also want to go back a page and view the configs from @Samael here and @Lucas Rey here and if they work in place of yours, add back one option at a time until you find the problem option in either config... however, if one of those working configs don't work, it's definitely a firewall/network issue.
status /var/log/openvpn/openvpn-status.log
and client-to-client
It's not the same, as you have additional options set, such asI don't think there is problem with 128.0.0.0, I'm able connect to other public OpenVPN servers and it shows on the log.
Lots of r/w: https://pastebin.com/QRFAxjxN
But isn't that suppose to happen anyway since I'm able to connect?
My config is the same as Lucas Rey with exception of me havingstatus /var/log/openvpn/openvpn-status.log
andclient-to-client
mode server
, which I'm not sure why you have set, as it's not needed. Since we know the tutorial on page 1 works, it's something you've added or removed and I would recommend opening a thread on the OpenVPN forum. client-to-client
, so if client's aren't able to communicate with one another, or there's a routing issue, it's network/firewall related, not openvpn related.It's not the same, as you have additional options set, such asmode server
, which I'm not sure why you have set, as it's not needed. Since we know the tutorial on page 1 works, it's something you've added or removed and I would recommend opening a thread on the OpenVPN forum.
The openvpn server allows clients to see one another viaclient-to-client
, so if client's aren't able to communicate with one another, or there's a routing issue, it's network/firewall related, not openvpn related.
auth SHA256
Your logs show nothing but IPv6 traffic, which cannot be properly routed since you lack the IPv6 config options. Your OpenVPN server should not be passing IPv6 traffic, which implies you have a network routing issue to solve. If you're interested in IPv6 through OpenVPN, see IPv6 in OpenVPN, however I don't recommend it as it will only complicate a home user's life.Yeah I forgot to mention that I removed these unnecessary options. I added them because I thought they solved a HMAC error as suggested while google'ing but it turns out that I was only missingauth SHA256
Thanks anyway for your effort, I will post on OpenVPN forums.
I would just like to confirm, assuming that my config work at some point, would I also be able to browse the internet or just the LAN?
# Config Type # #------------------------------------------------ client # Connection # #------------------------------------------------ dev tun proto tcp remote x.duckdns.org 1194 # Speed # #------------------------------------------------ mssfix 0 fragment 0 tun-mtu 48000 # Reliability # #------------------------------------------------ float nobind comp-lzo persist-key persist-tun resolv-retry infinite # Encryption # #------------------------------------------------ auth SHA256 auth-nocache ca ca.crt cert myMac.crt key myMac.key # --- SSL --- # cipher AES-256-CBC tls-auth ta.key 1 # --- TLS --- # tls-version-min 1.2 remote-cert-tls server # Logging # #------------------------------------------------ verb 5
# Protocol # #------------------------------------------------ dev tun dev tun0 topology subnet proto tcp port 1194 # Routes # #------------------------------------------------ server 172.16.8.0 255.255.255.0 ifconfig 172.16.8.1 255.255.255.0 # Client Config # #------------------------------------------------ ifconfig-pool-persist /etc/openvpn/clients/ipp.txt # Pushed Routes # #------------------------------------------------ push "route 192.168.1.0 255.255.255.0" push redirect-gateway def1 push dhcp-option DNS 172.16.8.1 push dhcp-option DNS 192.168.1.1 push dhcp-option WINS 192.168.1.1 push dhcp-option DNS 8.8.8.8 push dhcp-option DNS 8.8.4.4 push dhcp-option NTP 129.6.15.30 # Encryption # #------------------------------------------------ # Diffie-Hellman: dh dh.pem # CA: ca ca.crt # Server: cert openvpn-server.crt key openvpn-server.key # SSL: cipher AES-256-CBC auth SHA256 tls-auth ta.key 0 # TLS: tls-server tls-version-min 1.2 tls-cipher 'TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-RSA-WITH-AES-256-CBC-SHA384:TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-256-CBC-SHA256:!aNULL:!eNULL:!LOW:!3DES:!MD5:!SHA:!EXP:!PSK:!SRP:!DSS:!RC4' # Logging # #------------------------------------------------ log-append /var/log/openvpn/openvpn.log status /var/log/openvpn/openvpn-status.log verb 4 # Connection Options # #------------------------------------------------ keepalive 10 120 comp-lzo # Connection Reliability # #------------------------------------------------ client-to-client persist-key persist-tun # Connection Speed # #------------------------------------------------ sndbuf 393216 rcvbuf 393216 fragment 0 mssfix 0 tun-mtu 48000 # Pushed Buffers # #------------------------------------------------ push sndbuf 393216 push rcvbuf 393216 # Permissions # #------------------------------------------------ user nobody group nogroup
Sun Apr 30 22:54:09 2017 us=386400 ECDH curve secp384r1 added Sun Apr 30 22:54:09 2017 us=386586 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Sun Apr 30 22:54:09 2017 us=386602 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication Sun Apr 30 22:54:09 2017 us=386617 TLS-Auth MTU parms [ L:1622 D:1172 EF:78 EB:0 ET:0 EL:3 ] Sun Apr 30 22:54:09 2017 us=386720 TUN/TAP device /dev/tun2 opened Sun Apr 30 22:54:09 2017 us=386732 do_ifconfig, tt->did_ifconfig_ipv6_setup=0 Sun Apr 30 22:54:09 2017 us=386750 /sbin/ifconfig tun2 172.15.8.1 172.15.8.2 mtu 1500 netmask 255.255.255.0 up ifconfig: interface tun2 does not exist Sun Apr 30 22:54:09 2017 us=388331 FreeBSD ifconfig failed: external program exited with error status: 1 Sun Apr 30 22:54:09 2017 us=388352 Exiting due to fatal error
port 10011 proto udp topology subnet dev tun ca /mnt/keys/ca.crt cert /mnt/keys/openvpn-server.crt #server public key key /mnt/keys/openvpn-server.key #server private key dh /mnt/keys/dh.pem #diffie-hellman parameters server 172.15.8.0 255.255.255.0 #purple network ifconfig-pool-persist /mnt/keys/ipp.txt push "route 192.168.1.0 255.255.255.0" #yellow network tls-auth /mnt/keys/ta.key 0 #crl-verify crl.pem keepalive 10 120 cipher AES-256-CBC auth SHA256 group nobody user nobody comp-lzo persist-key persist-tun verb 6
[root@OpenVPN /mnt/keys]# ifconfig lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6> inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 127.0.0.1 netmask 0xff000000 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> epair0b: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=8<VLAN_MTU> ether c6:25:1e:c1:20:66 inet 192.168.1.160 netmask 0xffffff00 broadcast 192.168.1.255 nd6 options=9<PERFORMNUD,IFDISABLED> media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>) status: active tun0: flags=8010<POINTOPOINT,MULTICAST> metric 0 mtu 1500 options=80000<LINKSTATE> nd6 options=9<PERFORMNUD,IFDISABLED>
dev tun0
, then restart the server. If that still doesn't work, reboot FreeNAS.Not only is that not whatroute
is for, it should not be needed. Please post your configs and log files, as no one can help you without the information I have repeatedly requested and you have repeatedly ignored. If you're not going to post the information requested of you, please stop posting in this thread.
route
should not be needed for what you were trying to do, nor is the proper use of route, ergo it wasn't the cause of your issues... you also still refuse to post your log files. Ask yourself this... why is it everyone else can get their vpn server and client to work properly without the way in which you were using route
, but you can't? --route network/IP [netmask] [gateway] [metric]
netmask default
gateway default
--route-gateway
or the second parameter to --ifconfig
when --dev tun
is specified. metric default
--route-metric
otherwise 0
. default
. vpn_gateway
--route-gateway
or the second parameter to --ifconfig
when --dev tun
is specified). net_gateway
remote_host
--remote address
if OpenVPN is being run in client mode, and is undefined in server mode.@vodka1983, as I previously stated,route
should not be needed for what you were trying to do, nor is the proper use of route, ergo it wasn't the cause of your issues... you also still refuse to post your log files. Ask yourself this... why is it everyone else can get their vpn server and client to work properly without the way in which you were usingroute
, but you can't?
Per the OpenVPN man page:
- route
- Add route to routing table after connection is established. Multiple routes can be specified. Routes will be automatically torn down in reverse order prior to TUN/TAP device close.
- This option is intended as a convenience proxy for the route(8) shell command, while at the same time providing portable semantics across OpenVPN's platform space.
--route network/IP [netmask] [gateway] [metric]
netmask default
- 255.255.255.255 or whatever the netmask is
gateway default
- taken from
--route-gateway
or the second parameter to--ifconfig
when--dev tun
is specified.metric default
- taken from
--route-metric
otherwise0
.
- The default can be specified by leaving an option blank or setting it to
default
.- The network and gateway parameters can also be specified as a DNS or /etc/hosts file resolvable name, or as one of three special keywords:
vpn_gateway
- The remote VPN endpoint address (derived either from
--route-gateway
or the second parameter to--ifconfig
when--dev tun
is specified).net_gateway
- The pre-existing IP default gateway, read from the routing table (not supported on all OSes).
remote_host
- The
--remote address
if OpenVPN is being run in client mode, and is undefined in server mode.