Bridged, client stuck in "Obtaining configuration"

settholo

Hello,
I'm trying to set a bridged configuration, but the client (windows 7) is stuck at "obtaining configuration".

Here is my server (debian) conf:

proto udp
dev tap0

ca /opt/openvpn/cert/keys/ca.crt
cert /opt/openvpn/cert/keys/myServer.crt
key /opt/openvpn/cert/keys/myServer.key
dh /opt/openvpn/cert/keys/dh1024.pem
#ifconfig-pool-persist ipp.txt

server-bridge 192.168.0.22 255.255.255.0 192.168.0.100 192.168.0.200
client-to-client
duplicate-cn
keepalive 10 120
comp-lzo
#user nobody
#group nobody
persist-key
persist-tun
status openvpn-status.log
log /etc/openvpn/openvpn.log
verb 6
mute 50

I added the following rules to the firewall:

iptables -A INPUT -i tap0 -j ACCEPT
iptables -A INPUT -i br0 -j ACCEPT
iptables -A FORWARD -i br0 -j ACCEPT

my etc/networking/interfaces is:



# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
iface br0 inet static
        address 192.168.0.22
        netmask 255.255.255.0
        network 192.168.0.0
        broadcast 192.168.0.255
        gateway 192.168.0.1
        bridge_ports eth0 tap0
        pre-up openvpn --mktun --dev tap0
        post-down openvpn --rmtun --dev tap0

allow-hotplug eth0
auto br0

The log is:

Sun Jul  7 02:08:13 2013 us=103318 MULTI: multi_create_instance called
Sun Jul  7 02:08:13 2013 us=103404 84.75.24.125:50141 Re-using SSL/TLS context
Sun Jul  7 02:08:13 2013 us=103447 84.75.24.125:50141 LZO compression initialized
Sun Jul  7 02:08:13 2013 us=103858 84.75.24.125:50141 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Sun Jul  7 02:08:13 2013 us=103894 84.75.24.125:50141 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Sun Jul  7 02:08:13 2013 us=103955 84.75.24.125:50141 Local Options String: 'V4,dev-type tap,link-mtu 1574,tun-mtu 1532,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Sun Jul  7 02:08:13 2013 us=103980 84.75.24.125:50141 Expected Remote Options String: 'V4,dev-type tap,link-mtu 1574,tun-mtu 1532,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Sun Jul  7 02:08:13 2013 us=104042 84.75.24.125:50141 Local Options hash (VER=V4): 'f7df56b8'
Sun Jul  7 02:08:13 2013 us=104076 84.75.24.125:50141 Expected Remote Options hash (VER=V4): 'd79ca330'
Sun Jul  7 02:08:13 2013 us=104169 84.75.24.125:50141 TLS: Initial packet from [AF_INET]84.75.24.125:50141, sid=8fa654b9 59e58ddd
Sun Jul  7 02:08:13 2013 us=174386 84.75.24.125:50141 VERIFY OK: depth=1, Sun Jul  7 02:08:13 2013 us=192441 84.75.24.125:50141 WARNING: 'dev-type' is used inconsistently, local='dev-type tap', remote='dev-type tun'
Sun Jul  7 02:08:13 2013 us=192481 84.75.24.125:50141 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1574', remote='link-mtu 1542'
Sun Jul  7 02:08:13 2013 us=192501 84.75.24.125:50141 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1532', remote='tun-mtu 1500'
Sun Jul  7 02:08:13 2013 us=192781 84.75.24.125:50141 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sun Jul  7 02:08:13 2013 us=192804 84.75.24.125:50141 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Jul  7 02:08:13 2013 us=192888 84.75.24.125:50141 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sun Jul  7 02:08:13 2013 us=192903 84.75.24.125:50141 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sun Jul  7 02:08:13 2013 us=195800 84.75.24.125:50141 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Sun Jul  7 02:08:13 2013 us=195846 84.75.24.125:50141 [client] Peer Connection Initiated with [AF_INET]84.75.24.125:50141
Sun Jul  7 02:08:15 2013 us=217776 client/84.75.24.125:50141 PUSH: Received control message: 'PUSH_REQUEST'
Sun Jul  7 02:08:15 2013 us=217875 client/84.75.24.125:50141 SENT CONTROL [client]: 'PUSH_REPLY,route-gateway 192.168.0.22,ping 10,ping-restart 120,ifconfig 192.168.0.100 255.255.255.0' (status=1)

The local dhcp serves from 192.168.0.50 to 192.168.0.99. I want the openvpn server to assign to the remote site client addresses from 192.168.0.100 to 192.168.0.200.
Where am I wrong?
Thanks for the help...

mwandelaar

I guess there are some inconsistencies between the server and client-configs, as your server is complaining:

02:08:13 2013 us=192441 84.75.24.125:50141 WARNING: 'dev-type' is used inconsistently, local='dev-type tap', remote='dev-type tun'
Sun Jul  7 02:08:13 2013 us=192481 84.75.24.125:50141 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1574', remote='link-mtu 1542'
Sun Jul  7 02:08:13 2013 us=192501 84.75.24.125:50141 WARNING: 'tun-mtu' is used inconsistently, local='tun-mtu 1532', remote='tun-mtu 1500'

Please first check the configfiles for using the same configuration, as these differences usually are the cause for not exchanging data.

settholo

Hello, thank you to help me.
Unfortunately I'm not getting where I'm wrong, here is my client configuration:

client
dev tap
proto udp
remote my_server_name 1194
nobind
ca ca.crt
cert client.crt
key client.key
comp-lzo
verb 3

Thanks again

mwandelaar

Can you increase the verbose-level on the client and post the logging from the client?

It looks like your client is either not capable of running tap or it's mixing-up some other settings.
Which software-versions are you running on both the server and client?

settholo

Hello,

running the client configuration:

client
dev tap
dev-type tap
proto udp
remote my_server_address 1194
nobind
ca ca.crt
cert client.crt
key client.key
comp-lzo
status openvpn-status.log
log openvpn.log
verb 6

I guess that I was messing up in some other way... Anyway it's getting the configuration. The problem I'm facing now is that I can reach only the vpn server and not the other resources on the lan, and that is the sense of configuring the bridging.
If for example I have a client in the "local" lan with ip 192.168.0.23 and my "remote" host connected to the vpn server is configured ( correctly ) with the 192.168.0.100 I expect them to be able to communicate.
I noticed that the server is not pushing anything regarding the gateway, so I'm wondering if this is the reason.
Any help on how to do that?
Thank you, cheers

settholo

In fact I cannot reach the vpn server as well...

settholo

That solved partially the problem:

local 192.168.0.22
proto udp
dev tap0
link-mtu 1542

ca /opt/openvpn/cert/keys/ca.crt
cert /opt/openvpn/cert/keys/myServer.crt
key /opt/openvpn/cert/keys/myServer.key
dh /opt/openvpn/cert/keys/dh1024.pem
#ifconfig-pool-persist ipp.txt

server-bridge 192.168.0.1 255.255.255.0 192.168.0.100 192.168.0.200
push "redirect-gateway"
client-to-client
duplicate-cn
keepalive 10 120
comp-lzo
#user nobody
#group nobody
#persist-key
#persist-tun
status openvpn-status.log
log /etc/openvpn/openvpn.log
verb 4
mute 50

Partially because now all the traffic is going through the vpn, and I want only the 192.168.0.0 traffic in my vpn, the other should go through each client internet connection.
If someone can help, it's appreciated...
Thanks

mwandelaar

As far as i can see right now, this is a setup which should work.
Can you, when connected,
- reach the vpn-server over it's vpn-address?
- reach another vpn-client?
- reach a machine on the local lan?

On the other hand, if the vpn-server is 192.168.0.1 AND your router has the same ip-address, you might have a conflict, which can really mess-up your traffic.

Once again, please increase verbose logging of both client and server and post the logs here.