Halfway to openvpn

dgermann · 09-11-2008, 09:46 AM

billymayday--

I think you are on to something. The question for me is how to fix it.

My network layout--not sure how to answer. Physically we have a router connecting to the internet. Behind that is a network switch, and behind that are the various computers. These two computers are PCs, each running Ubuntu 8.04.1 (the latest version, up to date with all updates added).

Software wise, I am able to connect the two machines via ssh, and indeed that is how I test the client side: I run ssh to the client and from there run the commands. I have occasionally run to the other room and run the commands from there (disconnecting the ssh connection first) but I get the same results.

Here are the results from ifconfig this morning:

Code:

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.66.77.1  P-t-P:10.66.77.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

I don't see any major differences with yours, do you?

So I changed the local setting to 10.66.77.1, and this gets me past the connection refused message, but still no connection, as this output from the client side shows:

Code:

root@earth:~# openvpn /etc/openvpn/client.conf 
Thu Sep 11 10:23:25 2008 OpenVPN 2.1_rc7 i486-pc-linux-gnu [SSL] [LZO2]

 [EPOLL] built on Jun 11 2008
Thu Sep 11 10:23:25 2008 /usr/bin/openssl-vulnkey -q -b 1024 -m <modulus omitted>
Thu Sep 11 10:23:25 2008 Control Channel Authentication: using 
'/etc/openvpn/keys/ta.key' as a OpenVPN static key file
Thu Sep 11 10:23:25 2008 Outgoing Control Channel Authentication: Using 
160 bit message hash 'SHA1' for HMAC authentication
Thu Sep 11 10:23:25 2008 Incoming Control Channel Authentication: Using 
160 bit message hash 'SHA1' for HMAC authentication
Thu Sep 11 10:23:25 2008 LZO compression initialized
Thu Sep 11 10:23:25 2008 Control Channel MTU parms [ L:1558 D:166 EF:66 
EB:0 ET:0 EL:0 ]
Thu Sep 11 10:23:25 2008 Data Channel MTU parms [ L:1558 D:1450 EF:58 
EB:135 ET:0 EL:0 AF:3/1 ]
Thu Sep 11 10:23:25 2008 Local Options hash (VER=V4): '9e7066d2'
Thu Sep 11 10:23:25 2008 Expected Remote Options hash (VER=V4): 
'162b04de'
Thu Sep 11 10:23:25 2008 NOTE: UID/GID downgrade will be delayed 
because of --client, --pull, or --up-delay
Thu Sep 11 10:23:25 2008 Socket Buffers: R=[110592->131072] 
S=[110592->131072]
Thu Sep 11 10:23:25 2008 UDPv4 link local: [undef]
Thu Sep 11 10:23:25 2008 UDPv4 link remote: 10.66.77.1:1194
Thu Sep 11 10:24:25 2008 TLS Error: TLS key negotiation failed to occur 
within 60 seconds (check your network connectivity)
Thu Sep 11 10:24:25 2008 TLS Error: TLS handshake failed
Thu Sep 11 10:24:25 2008 TCP/UDP: Closing socket
Thu Sep 11 10:24:25 2008 SIGUSR1[soft,tls-error] received, process 
restarting

Makes no obvious difference to disconnect ssh, walk back to other computer and run it from there.

My router shows this static route:

Code:

YES (active)	tunnel (name)	10.66.77.1 (destination)	192.168.0.2 (gateway)

Switching these last two around, the client gets:

Code:

root@earth:~# openvpn /etc/openvpn/client.conf 
Thu Sep 11 10:37:07 2008 OpenVPN 2.1_rc7 i486-pc-linux-gnu [SSL] [LZO2] 
[EPOLL] built on Jun 11 2008
Thu Sep 11 10:37:07 2008 /usr/bin/openssl-vulnkey -q -b 1024 -m 
<modulus omitted>
Thu Sep 11 10:37:08 2008 Control Channel Authentication: using 
'/etc/openvpn/keys/ta.key' as a OpenVPN static key file
Thu Sep 11 10:37:08 2008 Outgoing Control Channel Authentication: Using 
160 bit message hash 'SHA1' for HMAC authentication
Thu Sep 11 10:37:08 2008 Incoming Control Channel Authentication: Using 
160 bit message hash 'SHA1' for HMAC authentication
Thu Sep 11 10:37:08 2008 LZO compression initialized
Thu Sep 11 10:37:08 2008 Control Channel MTU parms [ L:1558 D:166 EF:66 
EB:0 ET:0 EL:0 ]
Thu Sep 11 10:37:08 2008 Data Channel MTU parms [ L:1558 D:1450 EF:58 
EB:135 ET:0 EL:0 AF:3/1 ]
Thu Sep 11 10:37:08 2008 Local Options hash (VER=V4): '9e7066d2'
Thu Sep 11 10:37:08 2008 Expected Remote Options hash (VER=V4): 
'162b04de'
Thu Sep 11 10:37:08 2008 NOTE: UID/GID downgrade will be delayed 
because of --client, --pull, or --up-delay
Thu Sep 11 10:37:08 2008 Socket Buffers: R=[110592->131072] 
S=[110592->131072]
Thu Sep 11 10:37:08 2008 UDPv4 link local: [undef]
Thu Sep 11 10:37:08 2008 UDPv4 link remote: 10.66.77.1:1194
Thu Sep 11 10:38:08 2008 TLS Error: TLS key negotiation failed to occur 
within 60 seconds (check your network connectivity)
Thu Sep 11 10:38:08 2008 TLS Error: TLS handshake failed
Thu Sep 11 10:38:08 2008 TCP/UDP: Closing socket
Thu Sep 11 10:38:08 2008 SIGUSR1[soft,tls-error] received, process 
restarting

My router instructions say:

Code:

 To Set Up A Static Route:

   1. Click the Add button.
   2. Type a route name for this static route in the Route Name box 
under the table.
      (This is for identification purposes only.)
   3. Select Private if you want to limit access to the LAN only.
   4. Select Active to make this route effective.
   5. Type the Destination IP Address of the final destination.
   6. Type the IP Subnet Mask for this destination.
      If this is for a single host, type 255.255.255.255.
   7. Type the Gateway IP Address, which must be a router on the same 
segment.
   8. Type a number between 2 and 15 
as the Metric value.
      This represents the number of 
other routers on your network. Usually, 
setting this to 2 or 3 works the best, 
but if this is a direct connection, set 
it to 2.
   9. Click Apply to have the static route entered into the table.

For #8 I chose 2. I am worried about #7: I do not know what that means, or how I can fix it, if it is the problem.

So is this progress, or something else?

Thanks for your help, billymayday!

dgermann · 09-11-2008, 09:56 AM

Hi--

Well, I spoke too soon. The reason the client could not connect is that the server was not up. My openvpn.log shows:

Code:

Options error: --local addresses must be distinct from --ifconfig addresses
Use --help for more information.

So it would seem that the change in the server.conf file for local was not correct.

Maybe there are clues in what we did. See any?

billymayday · 09-11-2008, 03:27 PM

What are the IPs of the two machines?

I assume they are connected via the switch, is that correct?

Can you please put a line break or 2 in point 8 to fix the display?

billymayday · 09-11-2008, 03:34 PM

local should be the IP if the NIC that you want the server to listen on. I don't believe you even need this set if you want it to listen on all interfaces, so comment that line out for now and try restarting.

Have you changed server.conf much (apart from that) from what you posted?

dgermann · 09-11-2008, 09:14 PM

billymayday--

OK, did that fix the display on your end, too?

Have only made the changes to server.conf mentioned in this thread, and I think I returned everything to where it was, so that should be an exact replica of where it is now--except for commenting out the local line as you suggested.

Yes, mine says in the comments that the local is optional.

The server, doug2, is currently 192.168.0.2; the client, earth, is 192.168.0.112. Both are dhcp, so these are not static addresses.

Yes, the two computers are connected physically through the network switch, a Linksys 16 port Workgroup Switch.

After commenting out the local line, the server started successfully, but the client reports:

Code:

root@earth:~# openvpn /etc/openvpn/client.conf 
Thu Sep 11 22:05:27 2008 OpenVPN 2.1_rc7 i486-pc-linux-gnu [SSL] [LZO2]
 [EPOLL] built on Jun 11 2008
Thu Sep 11 22:05:27 2008 /usr/bin/openssl-vulnkey -q -b 1024 -m 
<modulus omitted>
Thu Sep 11 22:05:27 2008 Control Channel Authentication: using 
'/etc/openvpn/keys/ta.key' as a OpenVPN static key file
Thu Sep 11 22:05:27 2008 Outgoing Control Channel Authentication: Using 
160 bit message hash 'SHA1' for HMAC authentication
Thu Sep 11 22:05:27 2008 Incoming Control Channel Authentication: Using 
160 bit message hash 'SHA1' for HMAC authentication
Thu Sep 11 22:05:27 2008 LZO compression initialized
Thu Sep 11 22:05:27 2008 Control Channel MTU parms [ L:1558 D:166 EF:66 
EB:0 ET:0 EL:0 ]
Thu Sep 11 22:05:27 2008 Data Channel MTU parms [ L:1558 D:1450 EF:58 
EB:135 ET:0 EL:0 AF:3/1 ]
Thu Sep 11 22:05:27 2008 Local Options hash (VER=V4): '9e7066d2'
Thu Sep 11 22:05:27 2008 Expected Remote Options hash (VER=V4): 
'162b04de'
Thu Sep 11 22:05:27 2008 NOTE: UID/GID downgrade will be delayed 
because of --client, --pull, or --up-delay
Thu Sep 11 22:05:27 2008 Socket Buffers: R=[110592->131072] 
S=[110592->131072]
Thu Sep 11 22:05:27 2008 UDPv4 link local: [undef]
Thu Sep 11 22:05:27 2008 UDPv4 link remote: 10.66.77.1:1194
Thu Sep 11 22:06:27 2008 TLS Error: TLS key negotiation failed to occur 
within 60 seconds (check your network connectivity)
Thu Sep 11 22:06:27 2008 TLS Error: TLS handshake failed
Thu Sep 11 22:06:27 2008 TCP/UDP: Closing socket
Thu Sep 11 22:06:27 2008 SIGUSR1[soft,tls-error] received, process 
restarting

So, like Edison, we are learning many things which do not work. <grin>

You are really helping me, billymayday, making me feel I am not alone on this. Thanks!

dgermann · 09-11-2008, 09:23 PM

Hi--

Is it possible there is a problem in the client.conf, a mismatch perhaps? Or would it make sense to start turning off some options in the server.conf and see if a more basic setup would allow a connection?

Here is my client.conf:

Code:

root@earth:~# cat /etc/openvpn/client.conf 
##############################################
# Sample client-side OpenVPN 2.0 config file #
# for connecting to multi-client server.     #
#                                            #
# This configuration can be used by multiple #
# clients, however each client should have   #
# its own cert and key files.                #
#                                            #
# On Windows, you might want to rename this  #
# file so it has a .ovpn extension           #
##############################################

# Specify that we are a client and that we
# will be pulling certain config file directives
# from the server.
client

# Use the same setting as you are using on
# the server.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
;dev tap
dev tun

# Windows needs the TAP-Win32 adapter name
# from the Network Connections panel
# if you have more than one.  On XP SP2,
# you may need to disable the firewall
# for the TAP adapter.
;dev-node MyTap

# Are we connecting to a TCP or
# UDP server?  Use the same setting as
# on the server.
;proto tcp
proto udp

# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.
remote 10.66.77.1 1194
;remote my-server-2 1194

# Choose a random host from the remote
# list for load-balancing.  Otherwise
# try hosts in the order specified.
;remote-random

# Keep trying indefinitely to resolve the
# host name of the OpenVPN server.  Very useful
# on machines which are not permanently connected
# to the internet such as laptops.
resolv-retry infinite

# Most clients don't need to bind to
# a specific local port number.
nobind

# Downgrade privileges after initialization (non-Windows only)
user nobody
group nobody

# Try to preserve some state across restarts.
persist-key
persist-tun

# If you are connecting through an
# HTTP proxy to reach the actual OpenVPN
# server, put the proxy server/IP and
# port number here.  See the man page
# if your proxy server requires
# authentication.
;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]

# Wireless networks often produce a lot
# of duplicate packets.  Set this flag
# to silence duplicate packet warnings.
;mute-replay-warnings

# SSL/TLS parms.
# See the server config file for more
# description.  It's best to use
# a separate .crt/.key file pair
# for each client.  A single ca
# file can be used for all clients.
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/mike.crt
key /etc/openvpn/keys/mike.key  # This file should be kept secret

# Verify server certificate by checking
# that the certicate has the nsCertType
# field set to "server".  This is an
# important precaution to protect against
# a potential attack discussed here:
#  http://openvpn.net/howto.html#mitm
#
# To use this feature, you will need to generate
# your server certificates with the nsCertType
# field set to "server".  The build-key-server
# script in the easy-rsa folder will do this.
ns-cert-type server

# If a tls-auth key is used on the server
# then every client must also have the key.
;tls-auth ta.key 1
tls-auth /etc/openvpn/keys/ta.key 1

# Select a cryptographic cipher.
# If the cipher option is used on the server
# then you must also specify it here.
;cipher x
cipher AES-256-CBC

# Enable compression on the VPN link.
# Don't enable this unless it is also
# enabled in the server config file.
comp-lzo

# Set log file verbosity.
verb 3

# Silence repeating messages
mute 20
root@earth:~#

Thanks!

billymayday · 09-12-2008, 01:39 AM

Good news is I can more or less generate the same error. Not consistently though, but I think that's OK

Try adding something like

Code:

iptables -A INPUT -i tun0 -j ACCEPT
iptables -A OUTPUT -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -j ACCEPT

to your firewall (you may not need to, but I do)

Note that "remote" needs to be the server you are trying to connect to, so

Code:

remote 192.168.0.2 1194

I also think you need to restart your networking between attempts, because failed attempts seem to stuff things up pretty badly.

Finally, I think you really need to try it from outside your network, because I can't get it to work internally (but your error is one of the problems I can generate when I try it internally).

You will need to forward udp port 1194 to your server at the router don't forget.

Do you really need to lug the box elsewhere? Do you have a laptop you can take home or a PC there (there are windows and mac clients if that helps).

Yes, display is good thanks.

dgermann · 09-12-2008, 09:57 AM

billymayday--

Well, I think you have gotten us just about there!

I am still inside, have not changed the firewall, but I did change the client.conf to the 192.168 address as you suggest and I got this on the client:

Code:

Fri Sep 12 10:44:49 2008 Initialization Sequence Completed

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.66.77.6  P-t-P:10.66.77.5  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

At this point it looks like both are connected, but I cannot ping, in each case getting:

Code:

From client:


root@earth:~# ping 10.66.77.1
PING 10.66.77.1 (10.66.77.1) 56(84) bytes of data.
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted

--- 10.66.77.1 ping statistics ---


3 packets transmitted, 0 received, 100% packet loss, time 1999ms

root@earth:~# ping 10.66.77.2
PING 10.66.77.2 (10.66.77.2) 56(84) bytes of data.
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted

--- 10.66.77.2 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3009ms

From server:

root@doug2:~# ping 10.66.77.6
PING 10.66.77.6 (10.66.77.6) 56(84) bytes of data.
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted

--- 10.66.77.6 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2009ms

root@doug2:~# ping 10.66.77.5
PING 10.66.77.5 (10.66.77.5) 56(84) bytes of data.
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted

--- 10.66.77.5 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2010ms

So now I have a different sort of problem, but that seems good. Major progress you have given me!

Thanks billymayday! You found the first problem. Are you game to tackle this next one? <grin>

billymayday · 09-12-2008, 06:23 PM

From what I can see on the net, it looks like this is probably a firewall issue (on the client machine). Turn the firewall off and test it that way (don't forget to turn it back on).

If that doesn't work, can you post

ifconfig

and

route

Cheers - BM

dgermann · 09-13-2008, 05:50 PM

billymayday--

You got it! Thank you, thank you, thank you!

It was a firewall issue, and firestarter has a special set of instructions just for openvpn, here.

Once I put that in both sides, it worked!

Now all I have to do is work through the mounting of the volumes the person needs, then the issues of getting through my router and such, but that seems almost easy now. If those really turn into issues, I will post those separately.

Thank you very much for all your help, billymayday: you made all the difference in the world!