Topic: OpenVPN & DHCP

The content of this topic has been archived on 2 May 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Page 1 of 1

Post #1

kikazzi

7 Aug 2007, 23:14

I've gone through the installation for OpenVPN on my router twice over the last two weeks trying to get my VPN connection up and running. Unfortunately, I haven't had any luck. I've figured how to break it and how to get it to partially work. I get the following messages when trying to connect:

The server reports:

Tue Aug  7 13:40:42 2007 OpenVPN 2.0.9 mipsel-linux [SSL] [LZO] [EPOLL] built on Feb 13 2007
Tue Aug  7 13:40:42 2007 WARNING: file '/etc/secret.key' is group or others accessible
Tue Aug  7 13:40:42 2007 Static Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Aug  7 13:40:42 2007 Static Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Aug  7 13:40:42 2007 Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Aug  7 13:40:42 2007 Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Aug  7 13:40:42 2007 TUN/TAP device tap0 opened
Tue Aug  7 13:40:42 2007 Data Channel MTU parms [ L:1576 D:1450 EF:44 EB:4 ET:32 EL:0 ]
Tue Aug  7 13:40:42 2007 Local Options hash (VER=V4): '8b888ddc'
Tue Aug  7 13:40:42 2007 Expected Remote Options hash (VER=V4): '8b888ddc'
Tue Aug  7 13:40:42 2007 UDPv4 link local (bound): [undef]:1194
Tue Aug  7 13:40:42 2007 UDPv4 link remote: [undef]
Tue Aug  7 13:41:20 2007 Peer Connection Initiated with 64.90.196.88:1719
Tue Aug  7 13:41:20 2007 Initialization Sequence Completed

Client Log:

Tue Aug 07 13:39:19 2007 OpenVPN 2.0.9 Win32-MinGW [SSL] [LZO] built on Oct  1 2006
Tue Aug 07 13:39:19 2007 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA.  OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Tue Aug 07 13:39:19 2007 Static Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Aug 07 13:39:19 2007 Static Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Aug 07 13:39:19 2007 Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Aug 07 13:39:19 2007 Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Aug 07 13:39:19 2007 TAP-WIN32 device [OpenVPN] opened: \\.\Global\{1DE2142B-DC85-4E16-B545-137922458420}.tap
Tue Aug 07 13:39:19 2007 TAP-Win32 Driver Version 8.4 
Tue Aug 07 13:39:19 2007 TAP-Win32 MTU=1500
Tue Aug 07 13:39:19 2007 Successful ARP Flush on interface [5] {1DE2142B-DC85-4E16-B545-137922458420}
Tue Aug 07 13:39:19 2007 Data Channel MTU parms [ L:1576 D:1450 EF:44 EB:4 ET:32 EL:0 ]
Tue Aug 07 13:39:19 2007 Local Options hash (VER=V4): '8b888ddc'
Tue Aug 07 13:39:19 2007 Expected Remote Options hash (VER=V4): '8b888ddc'
Tue Aug 07 13:39:19 2007 UDPv4 link local: [undef]
Tue Aug 07 13:39:19 2007 UDPv4 link remote: x.x.x.x:1194
Tue Aug 07 13:39:28 2007 Peer Connection Initiated with x.x.x.x:1194
Tue Aug 07 13:39:30 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Tue Aug 07 13:39:30 2007 Route: Waiting for TUN/TAP interface to come up...
Tue Aug 07 13:39:31 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Tue Aug 07 13:39:31 2007 Route: Waiting for TUN/TAP interface to come up...
Tue Aug 07 13:39:32 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Tue Aug 07 13:39:32 2007 Route: Waiting for TUN/TAP interface to come up...
Tue Aug 07 13:39:33 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Tue Aug 07 13:39:33 2007 Route: Waiting for TUN/TAP interface to come up...
Tue Aug 07 13:39:34 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Tue Aug 07 13:39:34 2007 Route: Waiting for TUN/TAP interface to come up...
Tue Aug 07 13:39:35 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Tue Aug 07 13:39:35 2007 Route: Waiting for TUN/TAP interface to come up...
Tue Aug 07 13:39:37 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Tue Aug 07 13:39:37 2007 Route: Waiting for TUN/TAP interface to come up...
Tue Aug 07 13:39:38 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Tue Aug 07 13:39:38 2007 Route: Waiting for TUN/TAP interface to come up...
Tue Aug 07 13:39:39 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Tue Aug 07 13:39:39 2007 Route: Waiting for TUN/TAP interface to come up...
Tue Aug 07 13:39:40 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Tue Aug 07 13:39:40 2007 Route: Waiting for TUN/TAP interface to come up...
Tue Aug 07 13:39:41 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Tue Aug 07 13:39:41 2007 Route: Waiting for TUN/TAP interface to come up...
Tue Aug 07 13:39:42 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Tue Aug 07 13:39:42 2007 Route: Waiting for TUN/TAP interface to come up...
Tue Aug 07 13:39:43 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Tue Aug 07 13:39:43 2007 Route: Waiting for TUN/TAP interface to come up...
Tue Aug 07 13:39:44 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Tue Aug 07 13:39:44 2007 Route: Waiting for TUN/TAP interface to come up...
Tue Aug 07 13:39:45 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Tue Aug 07 13:39:45 2007 Route: Waiting for TUN/TAP interface to come up...
Tue Aug 07 13:39:46 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Tue Aug 07 13:39:46 2007 Route: Waiting for TUN/TAP interface to come up...
Tue Aug 07 13:39:47 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Tue Aug 07 13:39:47 2007 Route: Waiting for TUN/TAP interface to come up...
Tue Aug 07 13:39:48 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Tue Aug 07 13:39:48 2007 Route: Waiting for TUN/TAP interface to come up...
Tue Aug 07 13:39:49 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Tue Aug 07 13:39:49 2007 Route: Waiting for TUN/TAP interface to come up...
Tue Aug 07 13:39:50 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Tue Aug 07 13:39:50 2007 Route: Waiting for TUN/TAP interface to come up...
Tue Aug 07 13:39:50 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Tue Aug 07 13:39:50 2007 Route: Waiting for TUN/TAP interface to come up...
Tue Aug 07 13:39:52 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Tue Aug 07 13:39:52 2007 Route: Waiting for TUN/TAP interface to come up...
Tue Aug 07 13:39:53 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Tue Aug 07 13:39:53 2007 Route: Waiting for TUN/TAP interface to come up...
Tue Aug 07 13:39:54 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Tue Aug 07 13:39:54 2007 Route: Waiting for TUN/TAP interface to come up...
Tue Aug 07 13:39:55 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Tue Aug 07 13:39:55 2007 Route: Waiting for TUN/TAP interface to come up...
Tue Aug 07 13:39:56 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Tue Aug 07 13:39:56 2007 Route: Waiting for TUN/TAP interface to come up...
Tue Aug 07 13:39:57 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Tue Aug 07 13:39:57 2007 Route: Waiting for TUN/TAP interface to come up...
Tue Aug 07 13:39:58 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Tue Aug 07 13:39:58 2007 Route: Waiting for TUN/TAP interface to come up...
Tue Aug 07 13:40:00 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Tue Aug 07 13:40:00 2007 Initialization Sequence Completed With Errors ( see http://openvpn.net/faq.html#dhcpclientserv )
Tue Aug 07 13:42:18 2007 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Aug 07 13:42:19 2007 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Aug 07 13:42:19 2007 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Aug 07 13:42:20 2007 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Aug 07 13:42:21 2007 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)
Tue Aug 07 13:42:22 2007 read UDPv4: Connection reset by peer (WSAECONNRESET) (code=10054)

/etc/server.ovpn (I've tried theis with tap0, same thing)

# Which TCP/UDP port should OpenVPN listen on?
port 1194

# TCP or UDP server?
proto udp

# "dev tap" will create an ethernet tunnel.
# try tap0 if tap isn't working
dev tap

# The keepalive directive causes ping-like
# messages to be sent back and forth over
# the link so that each side knows when
# the other side has gone down.
# Ping every 10 seconds, assume that remote
# peer is down if no ping received during
# a 120 second time period.
keepalive 10 120

# Enable compression on the VPN link.
# If you enable it here, you must also
# enable it in the client config file.
;comp-lzo

# The persist options will try to avoid
# accessing certain resources on restart
# that may no longer be accessible because
# of the privilege downgrade.
;persist-key
;persist-tun

# Output a short status file showing
# current connections, truncated
# and rewritten every minute.
status openvpn-status.log

# Set the appropriate level of log
# file verbosity.
#
# 0 is silent, except for fatal errors
# 4 is reasonable for general usage
# 5 and 6 can help to debug connection problems
# 9 is extremely verbose
verb 3

# Silence repeating messages.  At most 20
# sequential messages of the same message
# category will be output to the log.
;mute 20

#Static Key
secret /etc/secret.key

/etc/firewall.user

#!/bin/sh
# Copyright (C) 2006 OpenWrt.org

iptables -F input_rule
iptables -F output_rule
iptables -F forwarding_rule
iptables -t nat -F prerouting_rule
iptables -t nat -F postrouting_rule

# The following chains are for traffic directed at the IP of the
# WAN interface

iptables -F input_wan
iptables -F forwarding_wan
iptables -t nat -F prerouting_wan

### Open port to WAN
## -- This allows port 22 to be answered by (dropbear on) the router
iptables -t nat -A prerouting_wan -p tcp --dport 22 -j ACCEPT
iptables        -A input_wan      -p tcp --dport 22 -j ACCEPT

### Port forwarding
## -- This forwards port 8080 on the WAN to port 80 on 192.168.1.2
# iptables -t nat -A prerouting_wan -p tcp --dport 8080 -j DNAT --to 192.168.1.2
# iptables        -A forwarding_wan -p tcp --dport 80 -d 192.168.1.2 -j ACCEPT

### DMZ
## -- Connections to ports not handled above will be forwarded to 192.168.1.2
# iptables -t nat -A prerouting_wan -j DNAT --to 192.168.1.2
# iptables        -A forwarding_wan -d 192.168.1.2 -j ACCEPT

### OpenVPN
## allow connections from outside
iptables -t nat -A prerouting_wan -p udp --dport 1194 -j ACCEPT
iptables        -A input_wan      -p udp --dport 1194 -j ACCEPT
## allow input/forwarding for the VPN interfaces, see http://openvpn.net/faq.htm
## also needs ip_forward, see http://openvpn.net/faq.html#ip-forward and http://
iptables -A INPUT   -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT
iptables -A INPUT   -i tap+ -j ACCEPT
iptables -A FORWARD -i tap+ -j ACCEPT

Client OpenVPN config:

dev tap

proto udp

# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.
remote x.x.x.x 1194

# 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

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

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

# original: secret secret.key
secret key.txt

# 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

I don't get an IP address initially and then get a bizzare one after all the messages. I've verified that the DHCP client is on at the two clients I've tested the VPN on and that windows firewall is off. I don't have a 3rd party firewall. Machine A is on a remote network that is open as far as VPN connections go (tested, good) and Machine B is on the internal network (same error messages after modifying the client for float and local IP).

I've been searching all over the net and on this site but just can't find the answer to this issue. I'm assuming that my router is failing to do something on connection, but I don't know what. Any ideas would be greatly appreciated.

(Last edited by kikazzi on 7 Aug 2007, 23:19)

Post #2

kikazzi

8 Aug 2007, 15:22

Any thoughts on this? Basically my connection begins through the router (both respond to eachother), but then something fails -
Tue Aug 07 13:39:31 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down
Tue Aug 07 13:39:31 2007 Route: Waiting for TUN/TAP interface to come up...

OpenVPN says this is a DHCP issue, but I've verified all the steps they've suggested to get it working. Could OpenWRT not be pushing DHCP to the VPN connection?

Post #3

OpenWrter

9 Aug 2007, 21:09

I would assume if you have two routers with DHCP up, than you have some sort of IP address conflict. Your logs look all in order when it hits this part:

Tue Aug 07 13:39:30 2007 Route: Waiting for TUN/TAP interface to come up...
Tue Aug 07 13:39:31 2007 TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down

I usually get:

Thu Aug 09 13:08:09 2007 Route: Waiting for TUN/TAP interface to come up...
Thu Aug 09 13:08:10 2007 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Thu Aug 09 13:08:10 2007 route ADD 192.168.153.0 MASK 255.255.255.0 10.10.153.17
Thu Aug 09 13:08:10 2007 Route addition via IPAPI succeeded
Thu Aug 09 13:08:10 2007 route ADD 10.10.153.1 MASK 255.255.255.255 10.10.153.17
Thu Aug 09 13:08:10 2007 Route addition via IPAPI succeeded
Thu Aug 09 13:08:10 2007 Initialization Sequence Completed

So, there may be something wrong with the communication between the two, possibly a server/client config error. I would try to setup both server/client on both servers, then try from both ends to establish a connection.

Post #4

kikazzi

15 Aug 2007, 17:00

I don't have 2 routers with DHCP up, AFAIK. I think for some reason OpenVPN on my router is not doing something it needs to be doing. Could you post your server config and your client config? I feel like I am missing something that will push an IP address to my client

I've been working on this for the last week, trying new configurations, starting from scratch, etc. Any help would be appreciated. Also, I am not using the --server parameter in my OpenWRT openvpn. Is that correct?

Also, could you post your server log for the connection? Mine goes this far -
Wed Aug 15 10:01:40 2007 Peer Connection Initiated with x.x.x.x:1947
Wed Aug 15 10:01:42 2007 Initialization Sequence Completed
Is that normal?

(Last edited by kikazzi on 15 Aug 2007, 17:03)

Post #5

kikazzi

15 Aug 2007, 17:07

The thing I really don't understand is why this doesn't work from within my OpenWRT network. As I said, I have a machine directly plugged into the router (192.168.1.10 ip) and have it try a direct, in network connection to OpenVPN (at 192.168.1.1). It gets the exact same problem with the connection - same server log, same
Route: Waiting for TUN/TAP interface to come up...
TEST ROUTES: 0/0 succeeded len=-1 ret=0 a=0 u/d=down

Post #6

OpenWrter

15 Aug 2007, 21:38

It could also be that they are on the same subnet. 192.168.1.xx going to the 192.168.1.xx network may be causing the problem. Try setting one of them to the 192.168.2.xx subnet.

Post #7

sorenstoutner

17 Aug 2007, 06:17

kikazzi,

In /etc/server.opvn, change "dev tap" to "dev tap0". When it is set as "dev tap" it creates a new tap that is one higher than the tap created by the script and bridged with br0. I've also updated the wiki at http://wiki.openwrt.org/OpenVPNHowTo with an explanation.

(Last edited by sorenstoutner on 17 Aug 2007, 06:18)

Post #8

kikazzi

17 Aug 2007, 17:42

sorenstoutner wrote:

kikazzi,
In /etc/server.opvn, change "dev tap" to "dev tap0". When it is set as "dev tap" it creates a new tap that is one higher than the tap created by the script and bridged with br0. I've also updated the wiki at http://wiki.openwrt.org/OpenVPNHowTo with an explanation.

Ok, I tried this, with server as TAP0, client as TAP0, and both as TAP0. There was no change. I'm wondering if my server is failing to do something, because on 3 different computers with 3 different builds on 2 different networks, I get the exact same error.
I read somewhere that the server log should note that it is assigning an IP address. Here is my log with the verbosity cranked up a bit (server):

Fri Aug 17 10:39:00 2007 us=25119 TUN/TAP device tap0 opened
Fri Aug 17 10:39:00 2007 us=29012 TUN/TAP TX queue length set to 100
Fri Aug 17 10:39:00 2007 us=33659 Data Channel MTU parms [ L:1576 D:1450 EF:44 EB:4 ET:32 EL:0 ]
Fri Aug 17 10:39:00 2007 us=37562 Local Options String: 'V4,dev-type tap,link-mtu 1576,tun-mtu 1532,proto UDPv4,cipher BF-CBC,auth SHA1,keysize 128,secret'
Fri Aug 17 10:39:00 2007 us=40872 Expected Remote Options String: 'V4,dev-type tap,link-mtu 1576,tun-mtu 1532,proto UDPv4,cipher BF-CBC,auth SHA1,keysize 128,secret'
Fri Aug 17 10:39:00 2007 us=52843 Local Options hash (VER=V4): '8b888ddc'
Fri Aug 17 10:39:00 2007 us=56950 Expected Remote Options hash (VER=V4): '8b888ddc'
Fri Aug 17 10:39:00 2007 us=60559 Socket Buffers: R=[32767->65534] S=[32767->65534]
Fri Aug 17 10:39:00 2007 us=64276 UDPv4 link local (bound): [undef]:1194
Fri Aug 17 10:39:00 2007 us=68285 UDPv4 link remote: [undef]
Fri Aug 17 10:39:12 2007 us=150018 UDPv4 READ [60] from 64.90.196.88:3671: DATA len=60
Fri Aug 17 10:39:12 2007 us=155234 Peer Connection Initiated with 64.90.196.88:3671
Fri Aug 17 10:39:12 2007 us=159011 Initialization Sequence Completed
Fri Aug 17 10:39:12 2007 us=163525 UDPv4 WRITE [156] to 64.90.196.88:3671: DATA len=156
Fri Aug 17 10:39:12 2007 us=167771 UDPv4 READ [380] from 64.90.196.88:3671: DATA len=380
Fri Aug 17 10:39:12 2007 us=172713 UDPv4 READ [380] from 64.90.196.88:3671: DATA len=380
Fri Aug 17 10:39:16 2007 us=782956 UDPv4 READ [380] from 64.90.196.88:3671: DATA len=380

and so on, back and forth with the read/writes
no mention of an IP address assignment, even though the client is set for DHCP. Is this how my server output should look?

Post #9

sorenstoutner

17 Aug 2007, 20:00

Did you create the script file /etc/openvpnbridge?

#!/bin/sh

#/etc/openvpnbridge
# OpenVPN Bridge Config File
# Creates TAP devices for use by OpenVPN and bridges them into OpenWRT Bridge
# Taken from http://openvpn.net/bridge.html

# Define Bridge Interface
# Preexisting on OpenWRT
br="br0"

# Define list of TAP interfaces to be bridged,
# for example tap="tap0 tap1 tap2".
tap="tap0"

case "$1" in
up)
# Make sure module is loaded
insmod tun

# Build tap devices
for t in $tap; do
openvpn --mktun --dev $t
done

# Add TAP interfaces to OpenWRT bridge

for t in $tap; do
brctl addif $br $t
done

#Configure bridged interfaces

for t in $tap; do
ifconfig $t 0.0.0.0 promisc up
done
;;
down)
for t in $tap; do
ifconfig $t 0.0.0.0 down
done

for t in $tap; do
brctl delif $br $t
done

for t in $tap; do
openvpn --rmtun --dev $t
done

rmmod tun
;;
*)
echo "$0 {up|down}"
;;
esac

You need to make it executable and then create a startup script to call it. This adds tap0 to br0. Your DHCP server be default will offer addresses to anything on br0. I did this setup last night and had a lot of problems until I figured out that my script was bridging tap0 to br0 and then my server.ovpn was creating a new tap (tap1) that wasn't bridged. That's why changing the device in server.ovpn to tap0 is important.

There are further instructions on the wiki at http://wiki.openwrt.org/OpenVPNHowTo

Post #10

kikazzi

17 Aug 2007, 22:44

That was it! I forgot to make my openvpnbridge file an executable! I am such a moron >< Thank you so much, I'm up and getting an IP address now!

My question now is, is there a way to route a specific port range of traffic over the VPN? For example, I would like to route all World of Warcraft port traffic over the VPN >.> Is there a way to do this besides the full gateway-redirect?

The discussion might have continued from here.

Page 1 of 1