OK, this one is confusing me. Hopefully someone can help...

Here is my basic setup:

Server: Home Router w/ DD-WRT firmware
Client1: Ubuntu
Client2: 770


Currently I have my home router and ubuntu desktop working perfectly using OpenVPN.
My ubuntu box forwards all traffic and nameserver requests through my home router.

On my 770, I am using roughly the same configuration as my desktop, but its not completely working.

OpenVPN initializes OK for the most part;

At some point it says the 'tap0' device is created.
The only errors I get are while it tried to much with the route (Network is unreachable error)

After initialization/startup of OpenVPN, I basically have no connectivity.


Now I had this same issue on my desktop, and I eventually realized that after OpenVPN is done starting up, I manually have to run:

> sudo dhclient tap0

Then it resets the routing table and /etc/resolv.conf file properly (for some reason dhclient never gets a reply if its run during OpenVPN startup, has to be done after).

I suspect I have basically the same problem on the 770, but there is no 'dhclient' that i can find. The closest thing I've seen is 'udhcpc', which doesnt seem to do anything at all. No console output whatsoever.

My route table on the 770 stays unchanged from my normal net configuration (everything goes to my normal gateway on wlan0).

I also can't ping my openvpn gateway (192.168.1.1 ... yes I know, i'm very unoriginal here!)

Since 192.168.1.1 (the OpenVPN gateway) is unreachable, those route errors show up in my openvpn startup ('route add * gw 192.168.1.1' fails because 192.168.1.1 is unreachable).

IIRC, on my desktop, 192.168.1.1 is only reachable after manually doing the 'sudo dhclient tap0' command.


...so, what is the equivelant to dhclient on the 770? anyone else had this problem before?


thanks for any help!

Well, figures that 5 min after posting this, I make some progress... imagine my surprise when googling "man udhcoc" provided answers!

"dhclient tap0"
can be replaced on the 770 with
"udhcpc -fnq -i tap0"

(f = foreground / don't fork, n = do it now, or exit/fail, q = quit after getting a dhcp reply)

It looks like I should be able to tweak the settings to just run constantly and monitor tap0.

Anyway, after running that command manually, my route table is now correct. I get "default" traffic routed to "192.168.1.1" which is indeed my openvpn gateway.

I still don't get a proper nameserver setup, like I do on my regular desktop...
/etc/resolv.conf points to 127.0.0.1
and
/tmp/resolv.conf.wlan0 points to my 'old' (non-openvpn) nameserver
and no other /tmp/resolv.conf.* exists (wouldnt it have been awesome if a resolv.conf.tap0 was created pointing to 192.168.1.1!)

So now figuring out the nameserver is the last piece of the puzzle...

Is there a specific reason why you need a tap device (bridging mode) instead of a tun device? Does your openvpn server has the: push "dhcp-option DNS 192.168.1.1" Option or does your dhcp Server actually provide a dns entry?

actually my openvpn server has:

push "dhcp-option DNS 65.24.7.3"
push "dhcp-option DNS 65.24.7.6"
(these are Time Warner cable / Road Runner DNS servers)

But on both Windows and Linux clients, it doesn't pick up the setting correctly.
The DHCP request gets "192.168.1.1" back from the openvpn server as a name server, and it seems to work correctly.

As for tap vs tun, I don't remember why I picked one over the other. Maybe I just copy/pasted the config from somewhere... or maybe there was some issue supporting Windows? Anyway, I currently have it working correctly from 3 clients simultaniously:
Ubuntu Linux
Nokia 770
Windows XP

the difference between tun and tap is that one is routed on layer 3 and one is bridged on layer 2 - normally layer 3 configuration (tun device) is more simple and sufficient. layer 2 bridging is only useful if you need some protocols like ipx supported. I guess you dont get the dhcp reply from your openvpn. Because of the bridging you are in your local network and get the dhcp reply from your router and this one listens on 192.168.1.1 and forwards the dns requests to your provider like for clients in the lan.