Keeping the same DHCP server address
-
Windows marking the network as public has nothing to do with outbound access, the windows firewall would block inbound access sure.
As to pushing your openvpn connection as default, this is just a check mark in the openvpn setup - see attached.
-
Windows marking the network as public has nothing to do with outbound access, the windows firewall would block inbound access sure.
As to pushing your openvpn connection as default, this is just a check mark in the openvpn setup - see attached.
Hi johnpoz! Yes, I do have that checked off.
-
well then your route should be pushed.. You might need to run the openvpn gui connection as admin to allow it to set routes. I don't push my default through my connection, but all my other routes to my networks get pushed just fine.
-
well then your route should be pushed.. You might need to run the openvpn gui connection as admin to allow it to set routes. I don't push my default through my connection, but all my other routes to my networks get pushed just fine.
Ahh, right. I'll give run as admin a shot. Thanks!
-
Thanks johnpoz, running as admin is necessary, but I still need to configure the client TAP adapter so that the Default Gateway is the same address as the DHCP server. If I don't do this, the client can't access network resources by their host names. Pinging remote host IP works fine. Pinging by host name is no go unless I config the TAP adapter accordingly.
Pushing "route-metric 512";push "route 0.0.0.0 0.0.0.0" only made Windows happy about accepting the connection as a Work network, it didn't resolve the client-to-host-name issue. It seems the only way this can work is to make sure the TAP's Default Gateway is the same addy as the DHCP server supplied by OVPN. Is there a way to reliably push this to the client? I'd really like to avoid the manual fiddly work on the client side if I can avoid it. -
are you using tap or tun? As to host name resolution that would be dns.. I resolve my home machines juts fine when I vpn in - and that has nothing to do with default route or any routes. It has to do if you hand out what dns to use, etc.
this is from my work box, that I am currently vpn'd into my home network from.
C:>nslookup
Default Server: pfsense.local.lan
Address: 192.168.1.253i5-w7.local.lan
Server: pfsense.local.lan
Address: 192.168.1.253Name: i5-w7.local.lan
Address: 192.168.1.100exit
-
I'm using tun. Re: host name resolution, I'm having OVPN hand out our workplace DNS servers to the clients. I verified that the client TAP adapter knows of our DNS servers by running ipconfig /all. This VPN is for accessing our workplace network.
-
Well if your doing queries to your dns that has the name resolution you want then that is all you should need. Can you query the dns you hand out.. Your not trying to do broadcast for netbios names are you?
-
Well if your doing queries to your dns that has the name resolution you want then that is all you should need. Can you query the dns you hand out.. Your not trying to do broadcast for netbios names are you?
I do have OVPN enabled for netbios over tcp/ip, type:bnode. Could this be where it's hosing up? Ok to turn it off?
-
your not going to broadcast over segments anyway. You would have to tap to be able to broadcast.
-
your not going to broadcast over segments anyway. You would have to tap to be able to broadcast.
I just turned off the netbios option and my test client works as expected. fist pump
Thanks again for your help, johnpoz!
-
And I forgot to mention, before testing the client I removed the default gateway addy from the TAP adapter. Even though Windows moved the connection to Public, I could still access what I needed to on our work network.
