LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices


Reply
  Search this Thread
Old 02-11-2016, 02:16 PM   #1
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 10,748
Blog Entries: 4

Rep: Reputation: 3965Reputation: 3965Reputation: 3965Reputation: 3965Reputation: 3965Reputation: 3965Reputation: 3965Reputation: 3965Reputation: 3965Reputation: 3965Reputation: 3965
Any OpenVPN+TunnelBlick+Bridge gurus out there?


I'm trying to configure OpenVPN with TunnelBlick (a very nice OS/X client, despite its odd name ...) in "bridge" mode, to allow "road warrior" access from outside for clients who expect to be able to use Bonjour (device and printer discovery), "Command-K show network," and screen sharing.

The OpenVPN client is on a computer at 192.168.1.199. Everything is OS/X. This computer is not a two-NIC gateway/firewall. It's an ordinary device on the machine, and the AirPort router sends "UDP 1174" traffic directly to it.

When I connect to the wireless of the coffee-shop next door (literally ...), and connect ... using client and server that are known to have exactly the same settings ... I find several strange things:

(1) "Command-K" will show only one computer: the "test server" that is running OpenVPN. In other words, when the VPN is connected, one "network device" is(!) visible.

(2) If I do "netstat -r," I find that there is a tap0 device, and that it has captured "192.169.1.*." Indeed, "route get 192.168.1.199 shows the traffic routed through tap0. Other routes are routed as-expected through the ethernet card.

(3) Now the problem: I cannot ping anything inside the VPN. Everything times out. I can ping outside normally.

Because I do see the (one) computer in the Network display, I conclude that the two sides are indeed talking and passing traffic. But I can't ping to anything inside, and I also can't connect.

Relevant configuration parameters on the server include:
Code:
server-bridge 192.168.1.199  255.255.255.0  192.168.1.70 192.168.1.90
push "route 192.168.1.199 255.255.255.0"
Edit: The first directive is incorrect. An IP-address conflict is created. Also, routing does not apply (and should not be used against this range of addresses), since "bridge mode" is a switch appliance, not a router. See post #3, below.

Most of the scant "bridge-mode road warrior" examples didn't include route, but I really seem to go nowhere without it.

Last edited by sundialsvcs; 02-12-2016 at 03:35 PM.
 
Old 02-11-2016, 06:11 PM   #2
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 10,748

Original Poster
Blog Entries: 4

Rep: Reputation: 3965Reputation: 3965Reputation: 3965Reputation: 3965Reputation: 3965Reputation: 3965Reputation: 3965Reputation: 3965Reputation: 3965Reputation: 3965Reputation: 3965
You can target this question by helping me find a clear and simple explanation of: "when my traffic arrives at the input port of the OpenVPN server, exactly how does it get to ... and get back from ... whatever it is going to? Particularly in the case of "ping?" The specific scenario that I am dealing with is:
  1. The OpenVPN server lives inside a firewall as one of many "office computers," and it does things besides OpenVPN. (The firewall routes the outward-facing port only to it.)
  2. The objective is, in classic "road warrior" style, to safely expose "the office network" to traveling programmers. That means, "bridge mode."
  3. The network and the office are small.
  4. For various reasons, we don't want to purchase hardware to do this.
Anything that is specific to OS/X ("pf") versus Linux ("iptables") commands would be hugely helpful.

I'm sure that "the perfect OpenVPN web page" ... excluding the obvious one ... must be waiting for me to have not yet discovered it. As usual (I've been here before, but it was ipSEC), I am "tantalizingly close" but fast running out of time.

I know that the two sides are connecting, and that I can in fact see one "Network" object so I also know they are communicating correctly. It must be a routing issue.

Incidentally, I based my efforts on the "openvpn-for-osx" project which is now on GitHub. I didn't execute their script directly but I basically walked through all of its steps. (No, I am not gonna generate 4096-bit DH parameters again! )

Last edited by sundialsvcs; 02-11-2016 at 06:12 PM.
 
Old 02-12-2016, 12:41 PM   #3
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 10,748

Original Poster
Blog Entries: 4

Rep: Reputation: 3965Reputation: 3965Reputation: 3965Reputation: 3965Reputation: 3965Reputation: 3965Reputation: 3965Reputation: 3965Reputation: 3965Reputation: 3965Reputation: 3965
Well, I figured it out ... with a lot of help that came from reading An OpenVPN Primer several times.

The basic problem that I had was that the address-range in the --server-bridge (or --server, if you are using that) is not "the public address of this computer on the local network!" Doing so creates an IP-address conflict.

This directive is supposed to be specifying the gateway-address and the client-address range of a physically non-existent "secure subnet, somewhere else," that is actually a figment of OpenVPN's imagination. When you connect to VPN, you become "part of that subnet" as seen by the other side. Like all subnets within your local network, this range of addresses must be unique and must not conflict with anyone else's address on your internal network ... on either side. (This was my mistake.)

OpenVPN uses "tap" and "tun" virtual devices:
  • tap (think "telephone wiretap" or "a bugged room") is a virtual switch which sucks-up everything that it hears on one side ... IP-traffic or otherwise ... and spews it out on the other side. This is bridge mode.
  • tun(-"nel") is a virtual IP router, which presents a range of connected IP-addresses in a "secure subnet somewhere else" and provides connectivity to them through a "gateway address" on the local network. Only IP-traffic is carried. This is tunnel mode.

In both cases, the "OpenVPN on the other side" has an IP-address on "this" side that can be used to communicate with it. This address corresponds to "the 'device' itself."

In bridge mode, the connection acts like a switch ... a "telephone wiretap" that snaps up everything that it hears ... IP or otherwise ... and sends it to the other side, where the data is spewed out so that anyone on that side can also hear it. Any sort of traffic ... IP or not ... can be transported, just like a physical "switch," and it goes both ways.

In tunnel mode, the connection acts as an IP (only...) router ... and, like any router, it has only one physical presence on the net to which it is attached: a "gateway address" to which traffic must be routed in order to get that traffic to go to the "subnet" on its other side. Ordinary TCP/IP routing must be used ... somewhere ... to cause all IP traffic in this address-range to be sent to the "phantom router's" gateway address. (Just as would be the case with a physical box.) Most commonly, the VPN client "sets up" this routing when you connect (using rules built-in to your configuration and/or "pushed" from the host), then tears it down again when you disconnect. But it is also possible to configure the physical router on your subnet to do the same thing.

- - -

Another critical mistake that I made was specifying route statements to "the other subnet" while in bridge (equals "switch") mode. When you've got a switch on your network, the other network is "just there," and all types of traffic pass through it, not just IP. A switch does not "route" anything because it promiscuously "carries" everything. The notion of "routing" does not apply to any type of "switch" appliance, real or virtual.

The only reason why you would need to specify routing in bridge mode is to advise clients of the presence of routed subnets (furnished by other routers on those subnets) which are only available when the VPN-switch is connected ... as you might wish to do with a physical switch-appliance that (for some weird reason) is not always turned-on.

Last edited by sundialsvcs; 02-12-2016 at 05:00 PM.
 
Old 02-12-2016, 04:34 PM   #4
sundialsvcs
LQ Guru
 
Registered: Feb 2004
Location: SE Tennessee, USA
Distribution: Gentoo, LFS
Posts: 10,748

Original Poster
Blog Entries: 4

Rep: Reputation: 3965Reputation: 3965Reputation: 3965Reputation: 3965Reputation: 3965Reputation: 3965Reputation: 3965Reputation: 3965Reputation: 3965Reputation: 3965Reputation: 3965
"Oh yeah... one other small thing ..."

Like every man page, the page for openvpn (which is conveniently HTML-formatted online at "openvpn.net") ...

... has an EXAMPLES section, at the bottom.

R-e-a-d ... i-t. ... F-i-r-s-t. ... ...

Last edited by sundialsvcs; 02-12-2016 at 04:35 PM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
openvpn bridge konkura Linux - Networking 3 02-24-2014 02:37 PM
Error When converting Routing OpenVPN to bridge mode openvpn danmartinj Linux - Software 0 11-06-2009 09:23 AM
Please could you post a working configuration for a OPENVPN with bridge ? frenchn00b Linux - Server 15 09-14-2009 01:53 PM
OpenVPN bridge problem acetone802000 Linux - Networking 2 05-18-2007 04:31 AM
LXer: How to bridge networks with OpenVPN LXer Syndicated Linux News 0 11-22-2006 04:03 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Networking

All times are GMT -5. The time now is 04:09 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration