Hi, thanks for the pointers ...
At 1st check per your advice, I _think_ it's a missing route.
To be sure, I added
ccd-exclusive
to @Server config, and restarter the server.
I also checked sysctls; verifying for BOTH @Server & @Client
sysctl -a | grep ip_forward
net.ipv4.ip_forward = 1
net.ipv4.ip_forward_use_pmtu = 0
At start of the client VPN, making the connection to the server, the
logs look basically unchanged, and the connection, to me, looks OK,
including the CCD info.
@Server
-------------------
Mon Jul 7 05:44:56 2014 client.vpn.mydomain.com/C.C.C.C:1194
TLS: new session incoming connection from [AF_INET]C.C.C.C:1194
Mon Jul 7 05:44:56 2014 client.vpn.mydomain.com/C.C.C.C:1194
VERIFY OK: depth=1, C=US, ST=California, L=San Jose,
O=mydomain.com, OU=mydomain.com, CN=Easy-RSA CA,
[email protected]
Mon Jul 7 05:44:56 2014 client.vpn.mydomain.com/C.C.C.C:1194
VERIFY OK: depth=0, C=US, ST=California, L=San Jose,
O=mydomain.com, OU=mydomain.com, CN=client.vpn.mydomain.com,
[email protected]
Mon Jul 7 05:44:56 2014 client.vpn.mydomain.com/C.C.C.C:1194
peer info: IV_VER=2.3_git
Mon Jul 7 05:44:56 2014 client.vpn.mydomain.com/C.C.C.C:1194
peer info: IV_PLAT=linux
Mon Jul 7 05:44:56 2014 client.vpn.mydomain.com/C.C.C.C:1194
peer info: IV_LZ4=1
Mon Jul 7 05:44:56 2014 client.vpn.mydomain.com/C.C.C.C:1194
peer info: IV_SNAPPY=1
Mon Jul 7 05:44:56 2014 client.vpn.mydomain.com/C.C.C.C:1194
peer info: IV_LZO=1
Mon Jul 7 05:44:56 2014 client.vpn.mydomain.com/C.C.C.C:1194
peer info: IV_COMP_STUB=1
Mon Jul 7 05:44:56 2014 client.vpn.mydomain.com/C.C.C.C:1194
Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256
bit key
Mon Jul 7 05:44:56 2014 client.vpn.mydomain.com/C.C.C.C:1194
Data Channel Encrypt: Using 512 bit message hash 'SHA512' for
HMAC authentication
Mon Jul 7 05:44:56 2014 client.vpn.mydomain.com/C.C.C.C:1194
Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256
bit key
Mon Jul 7 05:44:56 2014 client.vpn.mydomain.com/C.C.C.C:1194
Data Channel Decrypt: Using 512 bit message hash 'SHA512' for
HMAC authentication
Mon Jul 7 05:44:56 2014 client.vpn.mydomain.com/C.C.C.C:1194
TLS: move_session: dest=TM_ACTIVE src=TM_UNTRUSTED reinit_src=1
Mon Jul 7 05:44:56 2014 client.vpn.mydomain.com/C.C.C.C:1194
TLS: tls_multi_process: untrusted session promoted to
semi-trusted
Mon Jul 7 05:44:57 2014 client.vpn.mydomain.com/C.C.C.C:1194
Control Channel: TLSv1.2, cipher TLSv1/SSLv3
ECDHE-ECDSA-AES256-GCM-SHA384
Mon Jul 7 05:44:59 2014 client.vpn.mydomain.com/C.C.C.C:1194
PUSH: Received control message: 'PUSH_REQUEST'
Mon Jul 7 05:44:59 2014 client.vpn.mydomain.com/C.C.C.C:1194
send_push_reply(): safe_cap=940
Mon Jul 7 05:44:59 2014 client.vpn.mydomain.com/C.C.C.C:1194
SENT CONTROL [client.vpn.mydomain.com]: 'PUSH_REPLY,route
192.168.0.0 255.255.255.0,route-gateway 10.0.0.1,topology
subnet,ping 10,ping-restart 120,ifconfig 10.0.0.2 S.S.S.S'
(status=1)
-------------------
and, @Client
-------------------
Mon Jul 7 05:44:56 2014 OpenVPN 2.3_git
[git:master/96b9538711789355] x86_64-suse-linux-gnu [SSL
(OpenSSL)] [LZO] [SNAPPY] [LZ4] [EPOLL] [MH] [IPv6] built on Jun
28 2014
Mon Jul 7 05:44:56 2014 library versions: OpenSSL 1.0.1h 5 Jun
2014, LZO 2.08
Mon Jul 7 05:44:56 2014 MANAGEMENT: TCP Socket listening on
[AF_INET]127.0.0.1:1195
Mon Jul 7 05:44:56 2014 Control Channel Authentication: using
'/usr/local/etc/openvpn/mydomain.ta.key' as a OpenVPN static key
file
Mon Jul 7 05:44:56 2014 Outgoing Control Channel
Authentication: Using 512 bit message hash 'SHA512' for HMAC
authentication
Mon Jul 7 05:44:56 2014 Incoming Control Channel
Authentication: Using 512 bit message hash 'SHA512' for HMAC
authentication
Mon Jul 7 05:44:56 2014 NOTE: chroot will be delayed because of
--client, --pull, or --up-delay
Mon Jul 7 05:44:56 2014 NOTE: UID/GID downgrade will be delayed
because of --client, --pull, or --up-delay
Mon Jul 7 05:44:56 2014 TCP/UDP: Preserving recently used
remote address: [AF_INET]S.S.S.S:1194
Mon Jul 7 05:44:56 2014 Socket Buffers: R=[536870912->131072]
S=[536870912->131072]
Mon Jul 7 05:44:56 2014 UDPv4 link local (bound):
[AF_INET]C.C.C.C:1194
Mon Jul 7 05:44:56 2014 UDPv4 link remote:
[AF_INET]S.S.S.S:1194
Mon Jul 7 05:44:56 2014 TLS: Initial packet from
[AF_INET]S.S.S.S:1194, sid=d8cd44e5 1775003f
Mon Jul 7 05:44:56 2014 VERIFY OK: depth=1, C=US,
ST=California, L=San Jose, O=mydomain.com, OU=mydomain.com,
CN=Easy-RSA CA, [email protected]
Mon Jul 7 05:44:56 2014 Validating certificate key usage
Mon Jul 7 05:44:56 2014 ++ Certificate has key usage 00a0,
expects 00a0
Mon Jul 7 05:44:56 2014 VERIFY KU OK
Mon Jul 7 05:44:56 2014 Validating certificate extended key
usage
Mon Jul 7 05:44:56 2014 ++ Certificate has EKU (str) TLS Web
Server Authentication, expects TLS Web Server Authentication
Mon Jul 7 05:44:56 2014 VERIFY EKU OK
Mon Jul 7 05:44:56 2014 VERIFY OK: depth=0, C=US,
ST=California, L=San Jose, O=mydomain.com, OU=mydomain.com,
CN=vpn.server.mydomain.com, [email protected]
Mon Jul 7 05:44:56 2014 Data Channel Encrypt: Cipher
'AES-256-CBC' initialized with 256 bit key
Mon Jul 7 05:44:56 2014 Data Channel Encrypt: Using 512 bit
message hash 'SHA512' for HMAC authentication
Mon Jul 7 05:44:56 2014 Data Channel Decrypt: Cipher
'AES-256-CBC' initialized with 256 bit key
Mon Jul 7 05:44:56 2014 Data Channel Decrypt: Using 512 bit
message hash 'SHA512' for HMAC authentication
Mon Jul 7 05:44:56 2014 Control Channel: TLSv1.2, cipher
TLSv1/SSLv3 ECDHE-ECDSA-AES256-GCM-SHA384
Mon Jul 7 05:44:56 2014 [vpn.server.mydomain.com] Peer
Connection Initiated with [AF_INET]S.S.S.S:1194
Mon Jul 7 05:44:59 2014 SENT CONTROL [vpn.server.mydomain.com]:
'PUSH_REQUEST' (status=1)
Mon Jul 7 05:44:59 2014 PUSH: Received control message:
'PUSH_REPLY,route 192.168.0.0 255.255.255.0,route-gateway
10.0.0.1,topology subnet,ping 10,ping-restart 120,ifconfig
10.0.0.2 S.S.S.S'
Mon Jul 7 05:44:59 2014 OPTIONS IMPORT: timers and/or timeouts
modified
Mon Jul 7 05:44:59 2014 OPTIONS IMPORT: --ifconfig/up options
modified
Mon Jul 7 05:44:59 2014 OPTIONS IMPORT: route options modified
Mon Jul 7 05:44:59 2014 OPTIONS IMPORT: route-related options
modified
Mon Jul 7 05:44:59 2014 ROUTE_GATEWAY C.C.C.1/255.255.255.0
IFACE=eth0 HWADDR=6c:d2:16:a3:c4:ee
Mon Jul 7 05:44:59 2014 TUN/TAP device tun0 opened
Mon Jul 7 05:44:59 2014 TUN/TAP TX queue length set to 100
Mon Jul 7 05:44:59 2014 do_ifconfig, tt->ipv6=0,
tt->did_ifconfig_ipv6_setup=0
Mon Jul 7 05:44:59 2014 /usr/local/sbin/unpriv-ip link set dev
tun0 up mtu 1500
Mon Jul 7 05:44:59 2014 /usr/local/sbin/unpriv-ip addr add dev
tun0 10.0.0.2/18 broadcast 191.0.0.182
Mon Jul 7 05:44:59 2014 /usr/local/sbin/unpriv-ip route add
192.168.0.0/24 via 10.0.0.1
Mon Jul 7 12:44:59 2014 chroot to '/usr/local/etc/openvpn' and
cd to '/' succeeded
Mon Jul 7 12:44:59 2014 GID set to nobody
Mon Jul 7 12:44:59 2014 UID set to nobody
Mon Jul 7 12:44:59 2014 Initialization Sequence Completed
-------------------
checking the existing routes
@Server
ip route
default via S.S.S.1 dev eth0
10.0.0.0/24 dev tun0 proto kernel scope link src
10.0.0.1
S.S.S.0/24 dev eth0 proto kernel scope link src
S.S.S.S
127.0.0.0/8 dev lo scope link
169.254.0.0/16 dev eth0 scope link
and @Client
ip route
default via C.C.C.1 dev eth0
default via 192.168.1.1 dev eth1
10.0.0.0/18 dev tun0 proto kernel scope link src
10.0.0.2
C.C.C.0/24 dev eth0 proto kernel scope link src
C.C.C.C
127.0.0.0/8 dev lo scope link
169.254.0.0/16 dev eth0 scope link
192.168.0.0/24 via 10.0.0.1 dev tun0
192.168.1.0/24 dev eth1 proto kernel scope link src
192.168.1.1
I notice 2 things,
@Server route is missing any 192.168.x.x routes. Seems to me that
should be there, right? If yes, where/how in this Openvpn config should
that be added?
and,
@Client, the "10.0.0.0/18 dev tun0" route seems an enexpectedly large
address range, and in the logs, 'broadcast 191.0.0.182' seems an odd
address.
Mon Jul 7 05:44:59 2014 /usr/local/sbin/unpriv-ip addr add dev
tun0 10.0.0.2/18 broadcast 191.0.0.182
It's being assigned @ connect by the client
systemctl stop openvpn
ip route | grep "/18"
(empty)
systemctl start openvpn
ip route | grep "/18"
10.0.0.0/18 dev tun0 proto kernel scope link src
10.0.0.2
Why the /18? Shouldn't it just be 10.0.0.0/24?
Thanks,
PG
On Mon, Jul 7, 2014, at 01:38 AM, Darin Luckie wrote:
> Actually, this is most likely due to the fact that both server and client
> do not have routing enables. In Linux you need to enable the sysctl in
> order to do so (google for your distro).
> > On Jul 7, 2014, at 3:19 AM, Jan Just Keijser <[email protected]> wrote:
> > most likely the CCD file is not being picked up; I always advise people
> > to use absolute paths for the 'client-config-dir' option, in your case
> > client-config-dir /usr/local/etc/openvpn/ccd/ instead of
> > client-config-dir ccd/
> >
> > another way of checking if the CCD file is picked up is by adding
> > ccd-exclusive
> >
> > If there is no CCD file then the client is refused access - thus, if the
> > server is misconfigured and cannot find the right file, the client won't
> > be able to connect.
> >
> > If the CCD file IS being picked up then check the server side routing
> > table after the VPN connects *AND* check the client side routing table
> > and firewall rules.
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Openvpn-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-users
