Can't access other network machines via VPN

[dinomic]

From my Win 7 x64, I'm able to connect to my Amahi box remotely via VPN. However, I can't access any other machines or the router's web console.

Basically, my network uses an IP range of 192.168.1.x. When I connect via the HDAConnect VPN client, I get served back an IP in the range 10.8.0.x.

So, when connected via VPN, I try to tracert to any of the other machines on the home network, and the names get resolved to the right (fixed) IPs, but the tracert falls over after the HDA node (which is using an IP in the 10.8.0.x range).

Prior to using Amahi, I had set up a VPN using my Server2008R2 machine, and this was serving back IPs in the same range as the network, and all worked well. So could this (ie being served back an IP that is not in the same range as the home network) be the issue when trying to access other machines via an Amahi VPN connection??

[tomdchi]

I know this is a bit old but here is the answer for anyone that has found this thread through google. You need to follow directions at http://wiki.amahi.org/index.php/VPN_Bridging.

[dinomic]

I know this is a bit old but here is the answer for anyone that has found this thread through google. You need to follow directions at http://wiki.amahi.org/index.php/VPN_Bridging.

I wish I hadn't tried that page, now! In the code suggested for openvpn-startup, it has a hard-coded reference to "eth0", which is dead on my machine. I didn't notice this until it completely killed all my networking! (Also, I don't like the idea of the client's HDAConnect file needing to have a hard-coded IP in it - why can't the server supply this?).

I've now changed openvpn-startup to refer to "eth1", but whenever I restart the openvpn service, it complains. Also, when connecting from a client, the log in HDAConnect bounces around with "waiting for TUN/TAP interface tocome up..." for a few times, and then eventually connects "normally", but on a 10.8.0.x range.

I wish I'd stuck to Win2008R2 providing my VPN now. Can't really go back, because the IP ranges are controlled by the HDA now, and the HDA doesn't provide the same flexibility for DHCP ranges as do some routers.