Notices


Reply
Thread Tools
Posts: 433 | Thanked: 274 times | Joined on Jan 2010
#1
I have openVPN set up on N900, to connect back to my Win XP home desktop (also running openVPN). The VPN is set up as tap (so I can browse to other PC's on my LAN) and I've got the network bridge setup on on XP.

I can connect the VPN and the N900 gets allocated an IP by my home router (netgear DG834PN flashed with DGTeam firmware). The router is set to serve DHCP, and I've restricted the pool of local LAN IP's, with the VPN server config allocating a separate pool to connecting VPN clients. That is all working fine and I can ping/Remote Desktop/VNC into my local machines on their local IP's over the VPN (while on a 3G connection) no problems. Also managed to mount local share on the server via wizzard mounter (albeit painfully slow to fresh contents of folders with many entries).

One additional thing I want to do is to be able to route ALL ip traffic over the VPN tunnel (not just stuff aimed at ip's on my local LAN) - so that when I'm on public wifi or gprs, I can surf securely when needed.

I've set my XP's .conf to do this (push redirect-gateway def1). However in practice I can't access the internet via my home DSL this way, it fails . I've read a lot on here about the fact that maemo doesn't properly set the deault gateway, but I'm using openVPN applet which includes a fix for that.

I initially thought that the problem may be that I needed to NAT the traffic on XP that comes from the VPN client so it can find its way out to the net over my LAN - I set IPEnableRouter in the registry and installed & configured NAT and enabled routing & remote Access service on XP, but no joy.

After much random hacking about, I have managed to get my VPN client onto the internet via my home router - but only by running udhcpc -fnq -i tap0 in xterm while the VPN is active. This causes my router's DHCP to serve a new IP to the client from the "main" pool of local IP addresses, replacing the VPN-specific IP it received when openVPN connected.

My networking skillz are pretty weak, and my head is now hurting. Given that I've made it work, I *know* there must be some elegant solution to this, but I can't see it for looking right now.

If any guru out there can advise how I should change things so that I don't need to negotiate a new lease form my DHCP server while on the VPN in order to route to internet via home DSL connection in the above scenario, I'd be very grateful.

Full details:

Router is 192.168.0.1, and DHCP serves 192.168.0.2 to 192.168.0.99
XP box is 192.168.0.10 (static IP).

server .ovpn config file on XP is:
Code:
local 192.168.0.10
port 1194
proto udp
dev tap
dev-node openVPN
ca "c:\\program files\\openvpn\\easy-rsa\\keys\\ca.crt"
cert "c:\\program files\\openvpn\\easy-rsa\\keys\\server.crt"
key "c:\\program files\\openvpn\\easy-rsa\\keys\\server.key" 
dh "c:\\program files\\openvpn\\easy-rsa\\keys\\dh1024.pem"

ifconfig-pool-persist ipp.txt
server-bridge 192.168.0.10 255.255.255.0 192.168.0.150 192.168.0.160
push "redirect-gateway def1"
push "dhcp-option DNS 192.168.0.1"
keepalive 10 120
comp-lzo
max-clients 2
;user nobody
;group nobody
persist-key
persist-tun
status openvpn-status.log
;log         openvpn.log
;log-append  openvpn.log
verb 6
;mute 20
client .ovpn on N900 is:

Code:
script-security 2
up /etc/openvpn/maemo-update-resolvconf
down /etc/openvpn/maemo-update-resolvconf
resolv-retry infinite
client
remote xxxxxxxxxx.no-ip.org 1194
dev tap0
nobind
persist-key
persist-tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/n900.crt
key /etc/openvpn/n900.key
comp-lzo
verb 3
here is the situation with VPN active on a 3G connection, BEFORE I negotiate the new lease:

Code:
/etc/openvpn # ping vaio
PING vaio (192.168.0.10): 56 data bytes
64 bytes from 192.168.0.10: seq=0 ttl=128 time=250.824 ms
64 bytes from 192.168.0.10: seq=1 ttl=128 time=118.927 ms
^C
--- vaio ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 118.927/184.875/250.824 ms
/etc/openvpn # ping www.google.com
PING www.google.com (74.125.230.144): 56 data bytes
^C
--- www.google.com ping statistics ---
13 packets transmitted, 0 packets received, 100% packet loss
/etc/openvpn # route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
<my_DSL_static_IP> 10.94.53.135 255.255.255.255 UGH 0 0 0 gprs0
10.94.53.135 * 255.255.255.255 UH 0 0 0 gprs0
192.168.0.0 * 255.255.255.0 U 0 0 0 tap0
default vaio 128.0.0.0 UG 0 0 0 tap0
128.0.0.0 vaio 128.0.0.0 UG 0 0 0 tap0
default 10.94.53.135 0.0.0.0 UG 0 0 0 gprs0
default * 0.0.0.0 U 0 0 0 gprs0
/etc/openvpn # ifconfig
gprs0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.94.53.135 P-t-P:10.94.53.135 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MTU:1400 Metric:1
RX packets:188 errors:0 dropped:0 overruns:0 frame:0
TX packets:152 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:24247 (23.6 KiB) TX bytes:17188 (16.7 KiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:2501 errors:0 dropped:0 overruns:0 frame:0
TX packets:2501 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:213922 (208.9 KiB) TX bytes:213922 (208.9 KiB)

phonet0 Link encap:UNSPEC HWaddr 15-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
UP POINTOPOINT RUNNING NOARP MTU:4000 Metric:1
RX packets:28311 errors:0 dropped:0 overruns:0 frame:0
TX packets:18103 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:2373868 (2.2 MiB) TX bytes:804857 (785.9 KiB)

tap0 Link encap:Ethernet HWaddr B2:54:A5:CB:9C:59
inet addr:192.168.0.150 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::b054:a5ff:fecb:9c59/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:104 errors:0 dropped:0 overruns:0 frame:0
TX packets:43 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:7359 (7.1 KiB) TX bytes:3827 (3.7 KiB)
and again, after I've obtained the new lease:

Code:
/etc/openvpn # udhcpc -fnq -i tap0
udhcpc (v0.9.9-pre) started
Sending discover...
Sending select for 192.168.0.7...
Lease of 192.168.0.7 obtained, lease time 259200
/etc/udhcpc/default.script: exec: line 7: /etc/udhcpc/default.zeroconf.dhcpup: not found
Resetting default routes
adding dns 208.67.222.222
adding dns 208.67.220.220
/etc/openvpn # ping vaio
PING vaio (192.168.0.10): 56 data bytes
64 bytes from 192.168.0.10: seq=0 ttl=128 time=256.988 ms
64 bytes from 192.168.0.10: seq=1 ttl=128 time=134.002 ms
^C
--- vaio ping statistics ---
3 packets transmitted, 2 packets received, 33% packet loss
round-trip min/avg/max = 134.002/195.495/256.988 ms
/etc/openvpn # ping www.google.com
PING www.google.com (74.125.230.145): 56 data bytes
64 bytes from 74.125.230.145: seq=0 ttl=54 time=518.769 ms
64 bytes from 74.125.230.145: seq=1 ttl=54 time=185.974 ms
64 bytes from 74.125.230.145: seq=2 ttl=54 time=295.166 ms
^C
--- www.google.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 185.974/333.303/518.769 ms
/etc/openvpn # route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
<my_DSL_static_IP> 10.94.53.135 255.255.255.255 UGH 0 0 0 gprs0
10.94.53.135 * 255.255.255.255 UH 0 0 0 gprs0
192.168.0.0 * 255.255.255.0 U 0 0 0 tap0
default router 0.0.0.0 UG 0 0 0 tap0
default 10.94.53.135 0.0.0.0 UG 0 0 0 gprs0
default * 0.0.0.0 U 0 0 0 gprs0
/etc/openvpn # ifconfig
gprs0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.94.53.135 P-t-P:10.94.53.135 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MTU:1400 Metric:1
RX packets:259 errors:0 dropped:0 overruns:0 frame:0
TX packets:180 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10
RX bytes:34098 (33.2 KiB) TX bytes:20926 (20.4 KiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:2501 errors:0 dropped:0 overruns:0 frame:0
TX packets:2501 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:213922 (208.9 KiB) TX bytes:213922 (208.9 KiB)

phonet0 Link encap:UNSPEC HWaddr 15-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
UP POINTOPOINT RUNNING NOARP MTU:4000 Metric:1
RX packets:28571 errors:0 dropped:0 overruns:0 frame:0
TX packets:18299 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:2389392 (2.2 MiB) TX bytes:810693 (791.6 KiB)

tap0 Link encap:Ethernet HWaddr B2:54:A5:CB:9C:59
inet addr:192.168.0.7 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::b054:a5ff:fecb:9c59/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:172 errors:0 dropped:0 overruns:0 frame:0
TX packets:65 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:12744 (12.4 KiB) TX bytes:6758 (6.5 KiB)

/etc/openvpn #
__________________
n900: "with power comes responsibility".

If you buy a niche, highly modifiable smartphone and proceed to mess it up by blindly screwing around, don't just blame the phone, also blame yourelf.

Last edited by Pigro; 2011-03-10 at 15:47. Reason: added wizzard mounter info
 

The Following 3 Users Say Thank You to Pigro For This Useful Post:
Posts: 3 | Thanked: 0 times | Joined on Mar 2011
#2
Wow, this post is pretty timely. I just bought an N900 about 5 days ago. We have an existing OpenVPN network Bridging setup at my office and I just got around to trying to connect to it through my N900. I am connecting alright, but I haven't been able to route my internet connection through there. I will try out some parts of your conf file, hope it works for me.
 
Posts: 433 | Thanked: 274 times | Joined on Jan 2010
#3
ah - thought this thread was going to die without trace :-)

quick update - the "udhcpc -fnq -i tap0" command does, as I said, result in being able to browse the net, but I'm not happy about it and I wouldn't reccomend it as an approach (at least until someone more net-admin savvy can confirm it's not risky ... I really don't understand well if there are any security implications to it grabbing a new ip from my router/DHCP server when it already has one form the VPN pool).

Meantime, I've come up with another bodge - I've setup a proxy server (freeProxy) on the same XP Box that hosts my openVPN. Once I'm connected to my VPN from the N900, I open a browser window (which fails, as expected) and then I just set it to use the local proxy server 192.168.0.10 using about:config.

As examples:
network.proxy.http=192.168.0.10
network.proxy.http.port=995
network.proxy.ssl=192.168.0.10
network.proxy.ssl.port=995
(the above can be set from settings->internet connections->connections->(select your connection)->edit etc. and they will be retained even if the proxy is disabled)
network.proxy.type=1 (default=0 for no proxy)

Once you enable the proxy, you can still access all addresses on the local LAN OK and you can browse the internet too via the proxy. It's another crap solution (and in fact little better than just setting the browser to use my proxy via my router's public IP, port forwarded to my XP box, with no need of VPN at all), but it may be of some use in the scenario whre you need to be on the VPN for access to internal servers but simultaneously need an internet connection.

Note #1 - the network.proxy.type value is NOT persistant - i.e. it resets back to zero every time a new browser window is opened. Not sure why, just another bit of random cr@p to befuddle me during testing I guess :-)

Note #2: All my testing has been done at home, over my gprs connection (haven't got around to trying it from a public wifi yet even though that was the point of me setting it up) - From other stuff I've read here, there may be different/less/no issues getting net access over VPN if connecting via WiFi so please check before changing anything on your work LAN ...

Please report back on your own success (or otherwise), and avoid my clumsy hacks if at all possible :-)
__________________
n900: "with power comes responsibility".

If you buy a niche, highly modifiable smartphone and proceed to mess it up by blindly screwing around, don't just blame the phone, also blame yourelf.

Last edited by Pigro; 2011-03-10 at 15:43.
 

The Following User Says Thank You to Pigro For This Useful Post:
Posts: 433 | Thanked: 274 times | Joined on Jan 2010
#4
two small updates:

1) don't know what I did but I now have internet via my home router while connected via VPN - my .conf files haven't changed at all, I hacked around with the various permenant & temp resolv.conf files, trying to manually force my router to be used as the default gateway ... it didn't appear to make any difference other than one random time and I gave up after a while. Shortly thereafter I disabled a windows service on my XP box (routing and remote access, which I'd previously manually set to enabled when frigging with NAT over the bridge). I don't know if either/both of the above had some effect - but sometime thereafter, things started to "just work", and have stayed that way since.

2) unrelated to this thread, but I was also having an intermittant problem with the VPN clent connecting to the server over gprs. I spent AGES triple/quadruple checking my NAT & port forwarding on my router; my Windows Firewall exceptions on the server; I changed between UDP/TCP, changed the listening port, forced binding to the bridge adapter, changed the client to use my servers static IP instead of the associated domain name ... nothing helped, I ALWAYS got the client comm's hitting my router EVERY time, but the openVPN server was only seeing the traffic about 30% of the time. Was on the point of going mad when I finally checked peerblock (P2P software to avoid making torrent connections to undesirable IP's) ... I had set this up ages ago on my XP box with an "allow" exeception for the range of public IP's that my mobile telco (Vodafone) always allocated me when I connected (PeerBlock blocks every frigging Vodafone IP by default!!). Turns out that they'd started allocating me IP's from a different block sometimes, and peer Block was just silently blocking the ones for which I hadn't set an exception. Oh well, only took me 5 days of frustration before I sussed it out :-(
__________________
n900: "with power comes responsibility".

If you buy a niche, highly modifiable smartphone and proceed to mess it up by blindly screwing around, don't just blame the phone, also blame yourelf.

Last edited by Pigro; 2011-03-14 at 18:11.
 
Posts: 3 | Thanked: 0 times | Joined on Mar 2011
#5
Sorry I haven't gotten back to you in a while. Actually, I accidentally bricked my phone a couple of days ago, and it's taken me quite a while to get it up and running. again. Will definitely get around to trying that again in a day or two.

In the meantime, keep the information flowing!
 
Posts: 36 | Thanked: 45 times | Joined on Jan 2010 @ Belgium
#6
I never tried this config with the N900. However I do have experience in those kinds of setup (IPsec, SSL VPN...).
Given the fact that when using your "standard" dhcp, it works, I wonder if you have correctly defined the default gateway in your dhcp for openVPN.

The second point of attention is the network range you used for the openvpn. You need to ensure that the rest of your infrastructure konws how to route back your traffic to the openVPN subnet.
 

The Following User Says Thank You to mno@8 For This Useful Post:
Posts: 433 | Thanked: 274 times | Joined on Jan 2010
#7
Originally Posted by mno@8 View Post
I never tried this config with the N900. However I do have experience in those kinds of setup (IPsec, SSL VPN...).
Given the fact that when using your "standard" dhcp, it works, I wonder if you have correctly defined the default gateway in your dhcp for openVPN.

The second point of attention is the network range you used for the openvpn. You need to ensure that the rest of your infrastructure konws how to route back your traffic to the openVPN subnet.
Thanks, but as per subsequent posts to the original, I knew it was a default gateway issue (maemo seems to have an inherent problem with that over gprs, thats why there are the extra up/down scripts in the client .conf to try and fix it).

Anyway, I sorted it out - though can't 100% say HOW I did so - but thanks anyway for the feedback, appreciated :-)
__________________
n900: "with power comes responsibility".

If you buy a niche, highly modifiable smartphone and proceed to mess it up by blindly screwing around, don't just blame the phone, also blame yourelf.
 
Posts: 129 | Thanked: 32 times | Joined on Jun 2010
#8
anyways to get a mount script to run straight after the openvpn connection established?
 
Posts: 433 | Thanked: 274 times | Joined on Jan 2010
#9
haven't tried it, but I presume adding an up or route-up in the client .conf file to call a script with the mount command within it would work? may require route-delay too to cover timing issues.
__________________
n900: "with power comes responsibility".

If you buy a niche, highly modifiable smartphone and proceed to mess it up by blindly screwing around, don't just blame the phone, also blame yourelf.
 
Garcel's Avatar
Posts: 160 | Thanked: 181 times | Joined on Mar 2011
#10
Can anyone can give me a good vpn & its conf files for the open vpn. thanks in advance guys.
 
Reply


 
Forum Jump


All times are GMT. The time now is 04:39.