OpenVPN configuration issue

tiedyeguy64 · 11-13-2009, 08:18 PM

I currently have a small office server running Debian Lenny, Samba 3, & dnsmasq (DNS/DHCP). All office based XP clients have access. I now need to add XP road warrior access via VPN, and have installed openvpn. (It was installed per this howto.) All appreaed to go well at both server & client ends (using my XP machine @ home for testing.)

When I start the vpn connection, it appears to connect, I get notified that a TCP connection has been established, but then it resets & closes the socket. It waits 5 seconds, tries to reestablish, and continues in this loop.

I have searched for the openvpn log, but cannot find it in /var/log/ or any other location.

Any help would be much appreciated.

myclient internal IP (at home): 192.168.10.2

office internal network on 192.168.20.xxx
myserver public IP (static): 111.111.111.111
myserver IP (lan): 192.168.20.100
office gateway: 192.168.20.1

Server.conf file:

Quote:

port 443
proto tcp
dev tap
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/myserver.crt
key /etc/openvpn/easy-rsa/keys/myserver.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem
ifconfig-pool-persist ipp.txt
server-bridge 192.168.20.1 255.255.255.0 192.168.20.151 192.168.20.160
push "route 10.0.0.0 255.0.0.0"
keepalive 10 120
comp-lzo
persist-key
persist-tun
status /var/log/openvpn-status.log
verb

Client.ovpn file:

Quote:

client
dev tap
proto tcp
remote 111.111.111.111 443
resolv-retry infinite
nobind
pkcs12 myclient.p12
ns-cert-type server
comp-lzo
verb

Snippet of connection window messages:

Quote:

LZO Compression initialized
Control channel MTU parms [ L:1576 D:140 EF:40 EB:0 ET:0 EL:0 ]
Data Channel MTU parms [ L:1576 D:1450 EF:44 EB:135 ET:32 EL:0 AF:3/1 ]
Local Options hash (ver=v4): '31fdf004'
Expected remote options hash (ver=v4): '3e6d1056'
Attempting to establish connection with 111.111.111.111:443
TCP connection established with 111.111.111.111:443
TCPv4_client link local: [undef]
TCPv4_client link remote: 111.111.111.111:443
Connection reset, restarting [-1]
TCP/UDP closing socket
SIGUSR1[soft,connecting-reset] received, process restarting
Restart pause, 5 second(s)

I notice the [undef] notification, but am not sure what it relates to.

Thanks for any tips.

scheidel21 · 11-16-2009, 09:34 AM

Are you trying to connect to the VPN from within your office LAN? When I was initially trying to test OpenVPN here I connected from inside the LAN and had the same issue. If i used UDP it would stay connected but I had no Internetr connection and eventually the UDP connection would reset as well. When I realized what I was doing, I hooked the laptop up to a Cell Internet conenction with a public IP then connected and it worked fine.

tiedyeguy64 · 11-16-2009, 04:20 PM

I have actually been trying from several locations:
Server located in office: served by comcast business class. The SMC gateway is wide open, and I have confirmed with Comcast that they are not blocking anything. They even double checked the gateway to be sure it is configured correctly. Behind that sits a Belkin F5D7230-4 wireless router (not my choice, so please be kind!) I have verified that port 1194 is open for both udp & tcp, and that the port points to the server hosting the VPN software.

I also brought in a Linksys wrt54g, flashed with the openvpn version of DD-WRT, and replaced the Belkin router with it.

I have tried connecting from clients within the office (on the intranet), via an open wireless access point in the area, from my home computer, and from a wireless access point near my home.

I can now get as far as trying to establish the TCP connection - here is the last part of the logs I have learned pretty much by heart...

Quote:

Mon Nov 16 16:02:38 2009 us=264968 TLS: tls_session_init: entry
Mon Nov 16 16:02:38 2009 us=264980 PID packet_id_init seq_backtrack=0 time_backtrack=0
Mon Nov 16 16:02:38 2009 us=265019 PID packet_id_init seq_backtrack=0 time_backtrack=0
Mon Nov 16 16:02:38 2009 us=265034 TLS: tls_session_init: new session object, sid=e7e437a2 ee7156d0
Mon Nov 16 16:02:38 2009 us=291232 Control Channel MTU parms [ L:1544 D:140 EF:40 EB:0 ET:0 EL:0 ]
Mon Nov 16 16:02:38 2009 us=291278 MTU DYNAMIC mtu=1450, flags=2, 1544 -> 1450
Mon Nov 16 16:02:38 2009 us=291298 REMOTE_LIST len=1 current=0
Mon Nov 16 16:02:38 2009 us=291321 [0] 173.13.127.197:1194
Mon Nov 16 16:02:38 2009 us=293000 RESOLVE_REMOTE flags=0x0001 phase=1 rrs=0 sig=-1 status=1
Mon Nov 16 16:02:38 2009 us=293023 Data Channel MTU parms [ L:1544 D:1450 EF:44 EB:135 ET:0 EL:0 AF:3/1 ]
Mon Nov 16 16:02:38 2009 us=293060 Local Options String: 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Mon Nov 16 16:02:38 2009 us=293075 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_SERVER,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Mon Nov 16 16:02:38 2009 us=293105 Local Options hash (VER=V4): '69109d17'
Mon Nov 16 16:02:38 2009 us=309518 Expected Remote Options hash (VER=V4): 'c0103fa8'
Mon Nov 16 16:02:38 2009 us=309568 STREAM: RESET
Mon Nov 16 16:02:38 2009 us=309589 STREAM: INIT maxlen=1544
Mon Nov 16 16:02:38 2009 us=309666 Attempting to establish TCP connection with 173.13.127.197:1194
Mon Nov 16 16:02:42 2009 us=339680 TCP: connect to 173.13.127.197:1194 failed, will try again in 5 seconds
Mon Nov 16 16:02:47 2009 us=338594 REMOTE_LIST len=1 current=0
Mon Nov 16 16:02:47 2009 us=338644 [0] 173.13.127.197:1194
Mon Nov 16 16:02:48 2009 us=385034 TCP: connect to 173.13.127.197:1194 failed, will try again in 5 seconds

I am giving up for today, but need to get this resolved. Thanks for any thoughts or links you can think of...

scheidel21 · 11-17-2009, 08:13 AM

Ok, first let me ask a couple of questions to clear some idiosynchrosies up. Are you trying to use a bridged VPN or a routed VPN? By looking at your initial config posting it appears you are using a bridged VPN, but then looking at the log you posted in reply to me yu are trying to use a routed VPN. What kind of client are you using, Mac, Linux or Windows? Without providing me the WAN IP, could you provide the private IP address subnets you have, i.e. your Work LAN, and your home LAN? Theoretically if you are using a routed VPN solution you should be able to connect a client from within the LAN you are connecting to, practically speaking it is a bad idea. Bridged VPNs will not work at all if trying to connect from within the LAN you are connected to. Because a bridged VPN will set up a routing table to go through the VPN for all traffic destined for the LAN, but since you are all ready on the LAN you confuse the computer and it basically loses contact with the LAN itself.

This is my working bridged udp VPN

Code:

# listen on? (optional)
local 192.168.100.11
port 1194
# TCP or UDP server?
proto udp
dev tap0
;dev-node MyTap

ca /etc/openvpn/keys/hesco/ca.crt
cert /etc/openvpn/keys/hesco/hesco-server.crt
key /etc/openvpn/keys/hesco/hesco-server.key  # This file should be kept secret
dh /etc/openvpn/keys/hesco/dh2048.pem

#ifconfig-pool-persist ipp.txt
;server-bridge 192.168.100.12 255.255.255.0 10.8.0.50 10.8.0.100
server-bridge

push "route 192.168.168.0 255.255.255.0"
client-to-client

keepalive 10 120
cipher AES-128-CBC   # AES
comp-lzo

user nobody
group nogroup
persist-key
persist-tun

status openvpn-status.log
verb 3

I also have another bridged VPN on a second internal network configured using TCP and having the openVPN server hand out IP addresses instead of a DHCP server this network functions as well.

Here is one of the client configs for our windows machines to connect.

Code:

client

dev tap
dev-node HESCOVPN
proto udp
remote the.ip.add.ress 1194

resolv-retry infinite
nobind
persist-key
persist-tun
mute-replay-warnings

ca ca.crt
cert alexs.crt
key alexs.key
ns-cert-type server

cipher AES-128-CBC 
comp-lzo

verb 3

This works but only if connecting from outside our LAN from a network that does not know how to route directly to our 192.168.100.0/24 subnet.

tiedyeguy64 · 11-17-2009, 10:10 AM

Some good news...last night I decided to strip things down and essentially start over again. I deleted all certificates, deleted all configuration files (server & client), and uninstalled OpenVPN on my home computer (XP Pro). I also discovered that dnsmasq was not correctly pushing the gateway address out to clients; not sure why, but it is working now (the config was correct).

I then followed the the info here, and recreated the keys, and installed the windows gui version on my home machine. I then used the sample config files, modifying them per my particulars, and boosted verbose=6 for increased logging - which was invaluable.

At first, I had issues with the client not finding the TAP device. After a few various attempts, I decided to delete all the TAP devices on my client, and recreate a single one. And everything worked.

I still need to fine tune my connection, modify Samba and OpenVPN to allow full access, and then roll it out to the road warriors, but I now feel there is progress.

My setup is:
Server: Deb Lenny with dnsmaq, openvpn, samba. This is on a Comcast business grade connection, via the Comcast required SMC8014 gateway. My network sits behind the gateway on a fairly low end belkin router (not my choice).
Clients: All running XP Pro.
Bridged mode: Running Samba, and clients need to be able to browse the local network

After reviewing the files, I believe the example I originally used had crossed the server-bridge line and the push route line - and I ended up crossing the ip addresses. Add to that the incorrect gateway routing from dnsmasq.

Now that I have a working connection, I need to fine tune my config files & my samba configuration to allow the remote hosts to log into my samba domain and browse to resources.

As a followup, here are my working config files:

Server:

Quote:

local 192.168.27.99 ;my server's internal lan ip
port 1194
proto tcp
dev tap
;dev-node MyTap
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
ifconfig-pool-persist ipp.txt
server-bridge 10.8.0.4 255.255.255.0 10.8.0.50 10.8.0.100
push "route 192.168.27.0 255.255.255.0"
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
log-append /var/log/openvpn.log
verb 6

Client:

Quote:

client
dev tap
;dev-node MyTAP
proto tcp
remote my-server-ip 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client1.crt
key client1.key
comp-lzo
verb 6

Notice the commented dev-node lines; my initial tries had many failed connections, with the final error line stating that the MyTAP device could not be found. I discovered I had installed multiple tap devices on my client machine, and even if you name a specific one, for some reason the openvpn client attaches to the first unused device. By deleting all of them, and installing only a single one, I did not need to name the particular device, and it worked correctly.

If you have any further suggestions, I would love to hear them, as this is still very much a work in progress...

scheidel21 · 11-17-2009, 12:06 PM

Actually the dev-node keyword let's you specify a specific tap device in Windows, for instance all of my remote connections have a tap device called HESCOVPN and my dev-node entry specifies this, one of my remote connectors actually connect over openVPN to our LAN then uses openVPN over the VPN connection to connect to another internal network, so he has 2 tap devices on his machine.

tiedyeguy64 · 11-18-2009, 07:15 AM

I understand from reading the howto's etc from the openvpn pages that the method you mention is supposed to work. I could not get it to work, though - my win openvpn client continually did not find the device I had named in my dev-tap line...it kept defaulting to the first generic TAP device.

I finally found a forum post (I cannot remember where just at the moment) that mentioned this particular issue. The poster had the same issue as I do, and was not able to resolve it without a workaround - deleting all the TAP devices, and then creating a single one - and openvpn then binds to that sole device.

It may not be the "proper" way, but as a work-around it is managing to get me working for the moment.

I still need to tweak things to finish up, and part of that is going to be finessing as much as possible to do things the preferred way - including naming the TAP devices, etc. I also still need to modify settings so my clients can attach to Samba - that's my focus for today!