Page 1 of 1

SOLVED: VPN connection fails after installing Samba

Posted: Wed Oct 26, 2011 8:18 am
by alloydog
I had OpenVPN working. Tested the connection from inside the office LAN and from a remote PC. The office PC runs Ubuntu and the Network Manager indicated a connection was made. The remote PC runs Windows and the OpenVPN client GUI gave messages that the connection was made and the taskbar icon showed two green "PCs". I tested it a couple of times and in all cases it worked. So, I am pretty sure the OpenVPN server is running correctly.

I then installed Samba on to the file server. After that I cannot get the clients to connect through the VPN.
The Ubuntu PC in the LAN reports that the connection times-out, while the remote Windows PC returns "Connection reset by peer" error, indicating not connection cannot be made.

I have editted the Samba configuration file to allow the VPN IP range.

Another issue I have, which might be related, is that once OpenVPN has been installed, resvolvconf does not seem to work. After installing OpenVPN, regular connection to internet, from the file server, is lost - that is applications such as apt-get and wget cannot access the internet. I can fix this each time by stopping OpenVPN and manually editting resolv.conf by adding the gateway IP address. these changes are lost when the server is restarted.

smb.conf

Code: Select all

[global]
	log file = /var/log/samba/log.%m
	passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
	obey pam restrictions = yes
	map to guest = bad user
	encrypt passwords = yes
	public = yes
	passwd program = /usr/bin/passwd %u
	passdb backend = tdbsam
	dns proxy = no
	netbios name = heikkinen
	writeable = yes
	server string = samba server
	unix password sync = yes
	workgroup = heikkinen
	os level = 20
	security = share
	syslog = 0
	panic action = /usr/share/samba/panic-action %d
	usershare allow guests = yes
	max log size = 1000
	pam password change = yes
	hosts allow = 192.168.1.0/24 10.8.0.0/24 127.0.0.1 #added to allow OpenVPN server access

   interfaces = 192.168.1.0/24 10.8.0.0/24 

[printers]
   comment = All Printers
   browseable = no
   path = /var/spool/samba
   printable = yes
   guest ok = no
   read only = yes
   create mask = 0700

[print$]
   comment = Printer Drivers
   path = /var/lib/samba/printers
   browseable = yes
   read only = yes
   guest ok = no

[homes]
	comment = Home directories
	path = /home
server.conf

Code: Select all

port 1194
proto udp
dev tun
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key  # This file should be kept secret
dh /etc/openvpn/easy-rsa/keys/dh1024.pem
server 10.8.0.0 255.255.255.0
user nobody
group nobody
ifconfig-pool-persist ipp.txt
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
log-append /var/log/openvpn.log
verb 4 
daemon

Re: VPN connection fails after installing Samba

Posted: Wed Oct 26, 2011 12:33 pm
by janjust
what happens if you stop the samba server - does the VPN start working again?
what shows up in the client and server logs when the samba server is running? do you see any messages at all?

SOLVED: VPN connection fails after installing Samba

Posted: Thu Oct 27, 2011 7:23 am
by alloydog
OK, looks like I misread the signals... First thing I did this morning was to check ifconfig. It turns out that there was no tunnel (tun0) being created.

I removed smbd from /etc/init.d and restarted everything. Again, no tunnel was created.
As I had also just added "nobody" as user and group to server.conf, I commented them out and tried again. But this time I just stopped the VPN, then restarted it with /usr/sbin/openvpn --config /etc/openvpn/server.conf.
This time the tunnel was created and I could connect a client PC to the VPN.

I replaced smbd back to /etc/init.d and rebooted the server. Again the tunnel was not created.
This time I again restarted the VPN with /usr/sbin/openvpn --config /etc/openvpn/server.conf and the tunnel was created.

So, it seems Samba wasn't to blame after all.