Just moved from [url=https://forums.openvpn.net/topic9270.html]routing[/url] to bridging. Problem: When enabling DNS/WINS in the client, I can't use the local network anymore, only the VPN connection works. When disabling DNS/WINS in the client, I can use the local network, but VPN doesn't work anymore. Possible client settings: [img]http://i43.tinypic.com/30svh9l.jpg[/img] Options: Ignore/restore/restart connection. [size=85](Ignoring NetBIOS is needed otherwise it keeps restarting the connection.)[/size] [b]Client config:[/b] [code] client dev tap proto tcp remote X.X.X.X 443 resolv-retry infinite nobind persist-key persist-tun http-proxy ZZZZ 8080 ca ca.crt cert client1.crt key client1.key ns-cert-type server comp-lzo verb 3 [/code] [b]Server config:[/b] [code] port 443 proto tcp dev tap up "/etc/openvpn/bridge-start.sh" down" /etc/openvpn/bridge-stop.sh" ca ca.crt cert server.crt key server.key # This file should be kept secret dh dh1024.pem server-bridge keepalive 30 120 comp-lzo max-clients 2 persist-key persist-tun status statuslog.log log log.log verb 3 [/code] I use the up and down scripts from http://openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethernet-bridging.html#linuxscript, with one modification. I added [code] dhclient br0 [/code]into the up script. Otherwise networking doesn't work correct. My normal gateway (=router) does the DHCP. The VPN clients is given a LAN address. Random testing could take a lot of time. So does anyone has a clue? Something with gateways?

[quote]When enabling DNS/WINS in the client, I can't use the local network anymore, only the VPN connection works.[/quote] if you ping a local pc ,doesnt respond? keep in mind that the remote dhcp alters your resolver settings,if it is configured to send dns & wins options. [quote]When disabling DNS/WINS in the client, I can use the local network, but VPN doesn't work anymore.[/quote] what exactly do you mean by "disabling" dns/wins on the client? are you stopping dns client service? what OS your openvpn client has? EDIT i noticed tunneblick... OS X. Michael.

Local pinging: I can't test it with 100% result, I'm at a school with a very very bad network infrastructure. Tunnelblick at Mac OSX yes. It's about these options: [img]http://i40.tinypic.com/25gvs5d.jpg[/img] Do not set name server = working LAN etc, but not working VPN. Set nameserver = working VPN, but not working LAN.

No local connection anymore when OpenVPN bridged enabled

SaturnusDJ

Just moved from routing to bridging.

Problem: When enabling DNS/WINS in the client, I can't use the local network anymore, only the VPN connection works.
When disabling DNS/WINS in the client, I can use the local network, but VPN doesn't work anymore.

Possible client settings:

Options: Ignore/restore/restart connection.
(Ignoring NetBIOS is needed otherwise it keeps restarting the connection.)

Client config:

client

dev tap

proto tcp

remote 	X.X.X.X 443

resolv-retry infinite

nobind

persist-key
persist-tun

http-proxy ZZZZ 8080

ca ca.crt
cert client1.crt
key client1.key

ns-cert-type server
comp-lzo
verb 3

Server config:

port 443
proto tcp
dev tap

up "/etc/openvpn/bridge-start.sh"
down" /etc/openvpn/bridge-stop.sh"

ca ca.crt
cert server.crt
key server.key  # This file should be kept secret
dh dh1024.pem

server-bridge

keepalive 30 120
comp-lzo
max-clients 2
persist-key
persist-tun
status statuslog.log
log log.log
verb 3

I use the up and down scripts from http://openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethernet-bridging.html#linuxscript, with one modification. I added

dhclient br0

into the up script. Otherwise networking doesn't work correct.

My normal gateway (=router) does the DHCP. The VPN clients is given a LAN address.

Random testing could take a lot of time. So does anyone has a clue? Something with gateways?

maikcat

can you tell me the local ips for both client/server?

Michael.

SaturnusDJ

Server: 192.168.1.21
Gateway: 192.168.1.1
Subnet: 255.255.255.0

Addresses are pulled from the Gateway DHCP. Available from around 192.168.1.13 to 192.168.1.254.

At my remote location:
Client ip: 10.120.40.210 (and such).

Weird thing: When VPN enabled, 192.168.1.21 doesn't answer to pings/traceroutes.

maikcat

When enabling DNS/WINS in the client, I can't use the local network anymore, only the VPN connection works.

if you ping a local pc ,doesnt respond?

keep in mind that the remote dhcp alters your resolver settings,if it is configured to
send dns & wins options.

When disabling DNS/WINS in the client, I can use the local network, but VPN doesn't work anymore.

what exactly do you mean by "disabling" dns/wins on the client?
are you stopping dns client service?

what OS your openvpn client has?
EDIT
i noticed tunneblick... OS X.

Michael.

SaturnusDJ

Local pinging: I can't test it with 100% result, I'm at a school with a very very bad network infrastructure.

Tunnelblick at Mac OSX yes.
It's about these options:

Do not set name server = working LAN etc, but not working VPN.
Set nameserver = working VPN, but not working LAN.

maikcat

if you ping a local pc after connecting to vpn,doesnt respond?

i have never used macs , so the setting that you alter i really dont
know what it changes exactly..

if you use nslookup after you choose do not set nameserver
which is the default dns server that your system queries?

Michael.

SaturnusDJ

Just tried pinging the local gateway of the remote location while connected to VPN, this works. So I guess there is a default routing problem.

Nice thinking Michael, result:
When 'Do not set nameserver' the LAN nameserver (10.214.x.x) is kept.
When 'Set nameserver' the nameserver is set to 192.168.1.1.

Now we know this, what would be a solution. 🙂

maikcat

i recall that others also had similar resolver problems and someone
mentioned a dual resolver workaround but i dont have a link to this topic..

i will search later i will post the link..

Michael.

SaturnusDJ

Thanks!

Isn't it somehow possible to filter?
192.168.1.* -> VPN
Others -> LAN

Sounds like a 'route -add,' but it should be performed automatically when connecting/disconnecting, because manually every time will take lots of time.

SaturnusDJ

Any idea yet? 🙂
I tried some client settings, no fix.

Mimiko

Isn't it somehow possible to filter?
192.168.1.* -> VPN
Others -> LAN

By default the route 192.168.1.0/24 in bridge mode is automatically added to clients routing table. You can check this by lookig on client's system routing table.
When connected to VPN use "ping 192.168.1.1" and "ping some_client_LAN's_worksation_IP", using IP's not the names to see the connection and post results.

SaturnusDJ

True. But other routes don't exist anymore afterwards, so everything goes to 192.168.1.0.
Nameservers at the remote location get kicked out of /etc/resolv.conf when connecting VPN.
I think the same goes for netstat -r (= route -n @ OSX), I can look at the details monday.

When not setting the nameserver when connecting VPN, everything for the remote location ofcourse continues to work as it should, but VPN is unreachable.

Mimiko

I've asked to post some results of "ping". Please do it if you whant help.
Also post the routing table whent the VPN is connected.

SaturnusDJ

netstat -r before VPN connect:

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            10.120.44.1        UGSc           39        0     en0
10.120.44/22       link#4             UCS             3        0     en0
10.120.44.1        0:25:b4:34:ca:58   UHLWIi         38        6     en0   1184
10.120.44.189      localhost          UHS             1        0     lo0
10.120.47.255      ff:ff:ff:ff:ff:ff  UHLWbI          0        5     en0
127                localhost          UCS             0        0     lo0
localhost          localhost          UH              1      243     lo0
169.254            link#4             UCS             1        0     en0
169.254.255.255    0:25:b4:34:ca:58   UHLSWi          0        0     en0   1179

netstat -r after VPN connect:

Internet:
10.120.44/22       link#4             UCS             3        0     en0
10.120.44.189      localhost          UHS             0        0     lo0
127                localhost          UCS             0        0     lo0
localhost          localhost          UH              3      277     lo0
169.254            link#4             UCS             1        0     en0
169.254.255.255    0:25:b4:34:ca:58   UHLSWi          0        0     en0   1138
192.168.1          link#6             UC              0        0    tap0
192.168.1.14       localhost          UHS             0        0     lo0

Ping to pc at local network:

PING 10.120.44.1 (10.120.44.1): 56 data bytes
64 bytes from 10.120.44.1: icmp_seq=0 ttl=255 time=6.690 ms
64 bytes from 10.120.44.1: icmp_seq=1 ttl=255 time=8.113 ms
64 bytes from 10.120.44.1: icmp_seq=2 ttl=255 time=8.170 ms
64 bytes from 10.120.44.1: icmp_seq=3 ttl=255 time=9.420 ms

Ping to pc at vpn network:

PING 192.168.1.2 (192.168.1.2): 56 data bytes
64 bytes from 192.168.1.2: icmp_seq=0 ttl=64 time=21.796 ms
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=26.953 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=32.289 ms
64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=22.720 ms

(Others succeed too.)

/etc/resolv.conf before VPN connect:

domain xxxx-college.intern
nameserver 10.214.1.6
nameserver 10.214.1.7
nameserver 10.214.2.10
nameserver 10.214.2.11

/etc/resolv.conf after VPN connect:

search openvpn
nameserver 192.168.1.1

Server config:

up "/etc/openvpn/bridge-start.sh"
down "/etc/openvpn/bridge-stop.sh"

port 443
proto tcp
dev tap

ca ca.crt
cert lightning.crt
key lightning.key  # This file should be kept secret
dh dh1024.pem

server-bridge

;push "redirect-gateway def1 bypass-dhcp"
;push "dhcp-option DNS 192.168.1.1"

keepalive 30 180
comp-lzo
max-clients 2
persist-key
persist-tun
status status.log
log         log.log
verb 3

Client config:

client

dev tap
proto tcp
remote 	x.x.x.x 443

resolv-retry infinite

nobind
persist-key
persist-tun
http-proxy xxxx 8080

ca ca.crt
cert client1.crt
key client1.key

ns-cert-type server

comp-lzo
verb 3

🙂
Mac OSX client by the way.

SaturnusDJ

Ok this is strange. It looks like I accidentally found a fix:

Browsing is however slower than without VPN connected.

Edit:
And isn't working anymore... :x wtf. I'll play with it.

Mimiko

So the connection is working. All is about nameservers.
Is really in OpnVPN server's config file the options push "dhcp-option DNS 192.168.1.1" commented out?
Its most likely that the systems does not handle correctly the nameservers. I have such an issue on Android 2.2.

SaturnusDJ

Yes, it's absolutely turned off. 🙂

I missed your new reply and edited my previous message with: "And isn't working anymore... :x wtf. I'll play with it."

So I'm screwed again.

Lucky, the client log was still there and this is what causes the fix:

Mon Feb 13 12:20:07 2012 *Tunnelblick process-network-changes: ServerAddresses changed from
<array> {
0 : 192.168.1.1
}
 to (pre-VPN)
<array> {
0 : 10.214.1.6
1 : 10.214.1.7
2 : 10.214.2.10
3 : 10.214.2.11
}
Mon Feb 13 12:20:07 2012 *Tunnelblick process-network-changes: SearchDomains changed from
<array> {
0 : openvpn
}
 to (pre-VPN)

Mon Feb 13 12:20:07 2012 *Tunnelblick process-network-changes: DomainName changed from
openvpn
 to (pre-VPN)
x-college.intern

Exacly what you expect when setting the network settings like in the image. But, now it's not working anymore.
So, this for sure is a client side problem. Let's see what I can do otherwise I guess I'll need to head to the Tunnelblick forums.

Topic at Tunnelblick opened. I'll keep you up to date. Let me know when you have an idea.

SaturnusDJ

What is your setup?

Currently (until Tunnelblick developers comment) I suspect:
1. Differences of subnets
2. Class differences of networks
3. Proxy
(Client side.)

Because at a different, less strict, remote location that differs in the above the current setup is working fine.