[SOLVED] Help with OpenVPN LDAP setup

browley

Hi All,

I've been trying to implement OpenVPN on my Centos 5 box. I'm running OpenVPN 2.2.2 and OpenVPN-auth-ldap 2.0.3. Right now I'm having an issue when outside of our LAN. A quick overview: we have a Sonicwall as our router (192.168.101.1), DNS/OpenLDAP is provided through Centos (192.168.101.17), the testing OpenVPN server is a dev box (192.168.101.14), and we have a DHCP range of 192.168.101.2-222, with the last ~30 addresses reserved for OpenVPN pool. I've punched a UDP hole on the sonicwall firewall to allow any UDP 1194 traffic through to the dev box and disabled iptables and SELinux on the dev box. For simplicity, lets say my ldap domain is bob.local. Here are my configs--

/etc/openvpn/server.conf:

port 1194
proto udp
dev tap0
mode server
ca ca.crt
cert server.crt
key server.key  # This file should be kept secret
dh dh1024.pem
ifconfig-pool-persist ipp.txt
server-bridge 192.168.101.14 255.255.255.0 192.168.101.223 192.168.101.253
push "route 192.168.101.1 255.255.255.0" #not sure if this is right, assuming the VPN tunnel needs LAN route info?
push "dhcp-option DNS 192.168.101.17"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
client-to-client
duplicate-cn
keepalive 10 60
cipher AES-128-CBC   # AES
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
log-append  /var/log/openvpn.log
verb 6
plugin /usr/lib64/openvpn/plugin/lib/openvpn-auth-ldap.so "/etc/openvpn/auth/ldap.conf"
client-cert-not-required

/etc/openvpn/auth/ldap.conf:

<LDAP>
	# LDAP server URL
	# Use ldap://xx.xx.xx.xx,yy.yy.yy.yy for multiple servers
	URL		ldap://192.168.101.14:389

	# Bind DN (If your LDAP server doesn't support anonymous binds)
	BindDN		cn=root,dc=bob,dc=local

	# Bind Password
	# Password	SecretPassword
	Password	<Password here, plain text>

	# Network timeout (in seconds)
	Timeout		15

	# Enable Start TLS
	# TLSEnable	yes
	TLSEnable	no

	# Follow LDAP Referrals (anonymously)
	FollowReferrals yes

	# TLS CA Certificate File
	TLSCACertFile	/usr/local/etc/ssl/ca.pem

	# TLS CA Certificate Directory
	TLSCACertDir	/etc/ssl/certs

	# Client Certificate and key
	# If TLS client authentication is required
	TLSCertFile	/usr/local/etc/ssl/client-cert.pem
	TLSKeyFile	/usr/local/etc/ssl/client-key.pem

	# Cipher Suite
	# The defaults are usually fine here
	# TLSCipherSuite	ALL:!ADH:@STRENGTH
</LDAP>

<Authorization>
	BaseDN		"ou=People,dc=bob,dc=local"
	# Initials here is a hack attribute I added, will eventually shift this to requiring a VPN group...
	SearchFilter	"(&(uid=%u)(initials=vpn))"
	RequireGroup	false
	#PFTable	ips_vpn_users
	<Group>
		BaseDN		"ou=Groups,dc=bob,dc=local"
		SearchFilter	"(|(cn=developers)(cn=artists))"
		MemberAttribute	uniqueMember
		# Add group members to a PF table (disabled)
		#PFTable	ips_vpn_eng
	</Group>
</Authorization>

Windows 7 client .ovpn file:

client
dev tap0
proto udp
remote <ip address edited for paranoia>
resolv-retry infinite
nobind
persist-key
persist-tun
ca keys/ca.crt
#cert client.crt
#key client.key
ns-cert-type server
;tls-auth ta.key 1
comp-lzo
cipher AES-128-CBC
verb 3
auth-user-pass

When on the LAN, I have been able to connect locally to the OpenVPN server no problem by changing the Windows 7 .ovpn config to the local 192.168.101.14 address. Speaking of which, would connecting to the OpenVPN server on the LAN side potentially cause a routing hole of death since the same computer is technically routable on 2 points of the LAN? Either way, the Client get's an IP address and is able to get through. Connecting from outside is where I hit a brick wall. When connecting outside I get the following (note I edited my external IP out, thus .xx.yyy)--

Wed Jun 13 19:56:46 2012 us=626357 MULTI: multi_create_instance called
Wed Jun 13 19:56:46 2012 us=626520 146.115.xx.yyy:51004 Re-using SSL/TLS context
Wed Jun 13 19:56:46 2012 us=626574 146.115.xx.yyy:51004 LZO compression initialized
Wed Jun 13 19:56:46 2012 us=626687 146.115.xx.yyy:51004 Control Channel MTU parms [ L:1590 D:138 EF:38 EB:0 ET:0 EL:0 ]
Wed Jun 13 19:56:46 2012 us=626710 146.115.xx.yyy:51004 Data Channel MTU parms [ L:1590 D:1450 EF:58 EB:135 ET:32 EL:0 AF:3/1 ]
Wed Jun 13 19:56:46 2012 us=626745 146.115.xx.yyy:51004 Local Options String: 'V4,dev-type tap,link-mtu 1590,tun-mtu 1532,proto UDPv4,comp-lzo,cipher AES-128-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Wed Jun 13 19:56:46 2012 us=626758 146.115.xx.yyy:51004 Expected Remote Options String: 'V4,dev-type tap,link-mtu 1590,tun-mtu 1532,proto UDPv4,comp-lzo,cipher AES-128-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Wed Jun 13 19:56:46 2012 us=626784 146.115.xx.yyy:51004 Local Options hash (VER=V4): '26e19fc0'
Wed Jun 13 19:56:46 2012 us=626814 146.115.xx.yyy:51004 Expected Remote Options hash (VER=V4): 'b498be7c'
Wed Jun 13 19:56:46 2012 us=626863 146.115.xx.yyy:51004 UDPv4 READ [14] from 146.115.xx.yyy:51004: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Wed Jun 13 19:56:46 2012 us=626888 146.115.xx.yyy:51004 TLS: Initial packet from 146.115.xx.yyy:51004, sid=d5c468da b55018af
Wed Jun 13 19:56:46 2012 us=626928 146.115.xx.yyy:51004 UDPv4 WRITE [26] to 146.115.xx.yyy:51004: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] pid=0 DATA len=0
Wed Jun 13 19:56:46 2012 us=626976 146.115.xx.yyy:51004 write UDPv4 []: Network is unreachable (code=101)
Wed Jun 13 19:56:48 2012 us=35940 146.115.xx.yyy:51004 UDPv4 WRITE [14] to 146.115.xx.yyy:51004: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ ] pid=0 DATA len=0
Wed Jun 13 19:56:48 2012 us=36040 146.115.xx.yyy:51004 write UDPv4 []: Network is unreachable (code=101)
Wed Jun 13 19:56:49 2012 us=148421 146.115.xx.yyy:51004 UDPv4 READ [14] from 146.115.xx.yyy:51004: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Wed Jun 13 19:56:49 2012 us=148565 146.115.xx.yyy:51004 UDPv4 WRITE [22] to 146.115.xx.yyy:51004: P_ACK_V1 kid=0 [ 0 ]
Wed Jun 13 19:56:49 2012 us=148609 146.115.xx.yyy:51004 write UDPv4 []: Network is unreachable (code=101)
Wed Jun 13 19:56:51 2012 us=41281 146.115.xx.yyy:51003 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Wed Jun 13 19:56:51 2012 us=41351 146.115.xx.yyy:51003 TLS Error: TLS handshake failed
Wed Jun 13 19:56:51 2012 us=41504 146.115.xx.yyy:51003 SIGUSR1[soft,tls-error] received, client-instance restarting

So what I'm seeing here is "Network is unreachable (code=101)" and therefore the TLS handshake at the end fails. Not sure if I'm looking at the right error here but either way I did some googling and couldn't come up with any substantial fixes as most of the solutions I found were already in my config. This leads me to believe that my config must be screwed up somewhere. Any help would be much appreciated. I CAN confirm that the LDAP plugin is working as the ldap logs show show a successful bind via the bind credentials in the ldap.conf file and a successful return result of the username/password provided from the client when connecting on the LAN side. THANK YOU for any help/guidance!

EDIT: This is working using this and the config below. It was something screwy with the state of the centos machine that a reboot fixed.

browley

Figured out part of it, at least connecting remotely. Part of the problem I figured out after much network configuration was that the default gateway was being nuked every time the bridge adapter came up. Thus, once the remote end initiated connected, there was no route back from the OpenVPN server to my remote host. This was fixed by adding the following line to the bridge-start script

eth_ip="192.168.101.14"
eth_netmask="255.255.255.0"
eth_broadcast="192.168.101.255"
eth_gateway="192.168.101.1"
<snip>
#Last line
route add default gw $eth_gateway

Now I can at least connect, here is the view from the server:

Fri Jun 15 12:53:02 2012 us=93491 146.115.xx.yyy:54954 UDPv4 WRITE [101] to 146.115.44.232:54954: P_DATA_V1 kid=0 DATA len=100

This leads me to my next problem where I cannot ping anything other hosts after connecting. In other words, I can ping the OpenVPN server (192.168.101.14) but not the gateway (192.168.101.1) or any box behind the firewall. I tried adding the route via the conf

push "route 192.168.101.0 255.255.255.0"

But this doesn't "feel" right. Because my OpenVPN server (192.168.101.14) is in the DHCP range of my router (192.168.101.2-192.168.101.221), basically all I want to do is tell OpenVPN clients that the DHCP range from the internal gateway is routeable through the bridge. I would think that the server-bridge derivative would do that from above. Either way the "route" option seems superfluous. The answer is probably obvious but my question is: how do I set the config so, for anything in the 192.168.101.2-192.168.101.221 range, either my OpenVPN server routes to those addresses or hands off the responsibility to the gateway?

nawab.asghar

An excellent document that recently helped me doing this is :
https://community.openvpn.net/openvpn/wiki/RoutedLans