Posted: Thu Jan 29, 2015 22:58 Post subject: OpenVPN Bridge assistance
I am trying to configure an openvpn bridge similar to the one discussed in the link below (using 2 Buffalo whr-300hp2 routers with the latest brainslayer build installed), I want the bridge to issue an ip to the external router and all clients of the router and then connect them to a vlan on my local network. I have setup the vlan with all rules required and no dhcp, currently only the server router sits on this vlan. The idea here is that I want to setup the client, export the settings and reimport them into new routers so I can ship these to people and give them a small gateway into the network (this means no manually set IPs if possible). Ill be upgrading the server router once I have a proof of concept. The problem is, the server and client connect successfully but the PC connected to the client doesnt get an IP address and cant communicate over the network. If I manually set the PC's IP then it can ping the client router only on its router address (not its assigned bridge address nor can it ping the bridge gateway). Whats even wierder is that the server lists both the client router and PC as connected with IPs issued. Can anyone please help me and tell me what am I doing wrong?
Let me tell you what I’ve done and let’s see if it comes close to what you want. Btw, I’m using tomato, not dd-wrt. Shouldn’t matter, but just for the record, what I’m about to explain works for me, right here and now, as we speak.
I have two homes. At my second home I have an OpenVPN server configured for bridge mode (TAP). At my current home I have my primary router configured w/ a dedicated VLAN (one LAN port, port 4, for now) and VAP that are joined to a local bridge (br1), and which in turn is bridged to an OpenVPN client in bridge mode (TAP). On the local bridge (br1) I do NOT have DHCP enabled.
As a result, any wired client that uses port 4 of my primary router OR is a wireless client of that VAP, is bridged to the remote network of the other home and is configured by its DHCP server. It works perfectly. In fact, in some ways, it’s an easier configuration to setup than a routed (tun) OpenVPN tunnel.
Now if that’s what you’re looking for (or something close), perhaps I can provide some help.
The first thing I found a bit odd was this VLAN (w/ no DHCP server) that you said the OpenVPN server sits on. I don’t know what that’s all about if you expect remote clients to be bridged to your remote network and get configured. Not unless you created a whole new network for them. And in which case you WANT that network to have a DHCP server! How else can they be assigned IPs?!
So either I misread what you were trying to say there, or else that’s just an incorrect configuration. In my case, I want those clients to have access to my primary network, so no need for a special VLAN on the server side.
Another thing I don’t like about your current config is your attempts to override several items of the GUI in the Additional Config field. To me, that’s asking for trouble. It makes no sense to be doing things like enabling Redirect Gateway, then adding the same thing to the Additional Config field. Or doing the same thing w/ the IP pool. Perhaps in the end it will prove to be harmless, but for NOW, you should trust the GUI to do the right thing and ONLY add those things (if any) that you KNOW must be overridden/added to Additional Config.
Now granted, I’m using tomato and there could be some minor differences, but FWIW, the only thing I’ve added to Additional Config is directives for the CA, KEY, etc., that point to files in JFFS. I just prefer to store my files there rather than embed the documents in the GUI. But otherwise it’s empty.
I just get concerned when I see what appear to be seemingly arbitrary things added to Additional Config. Or even options that don’t make sense. For example, why is redirect-gateway even relevant in this config? Or client to client? You’re not interested in having these routers (which are the OpenVPN clients those directives are referring to) talk to each other, but rather having the clients BEHIND THEM talk to each other. And they are not clients of the OpenVPN server. They’re clients of the remote network that sits behind the OpenVPN server. That network will respond to their DHCP requests and determine how they are configured, including their default gateway. They will all have unfettered access to each other not because of any OpenVPN client-to-client directive, but simply because they share the same logical ethernet segment made available by the OpenVPN client to OpenVPN server tunnel.
Get my point?
So what I recommend (assuming my config is close to what you're after) is to keep it simple. Don’t jump ahead trying to anticipate what’s needed and add things like routes and other directives. Not unless you KNOW it's needed. This is pretty simple config once you properly visualize what’s happening. You’re more likely to screw it up by messing w/ it too much, then messing w/ it too little.
Btw, it might help to know the configuration of your dd-wrt OpenVPN client as well. I assume you bridged the OpenVPN client’s TAP interface to br0 (usually a GUI option).
eibgrad, I started out with nothing added into the additional config field and added those entries durring troubleshooting based on posts I found in other forums trying to get it to work, even clearing these does not help. Your implementation is very similar to what I am trying to do however I dont think it resolves my problem. After some further troubleshooting I found out some more about the problem. The bridge is forwarding broadcast and arp packets only, not addressed traffic so the clients fail to get an IP address. The server router has entries in the openvpn log for addresses issued to the client router and PC but they dont actually receive them for some reason. I have firewall disabled on both so I dont know what is causing this behavior.
“I have setup the vlan with all rules required and no dhcp, currently only the server router sits on this vlan.”
As I said before, this makes no sense. Why would you have the OpenVPN server sitting on its own VLAN w/ no DHCP server? How do you expect clients on the network behind the OpenVPN client to get configured on the network behind the OpenVPN server if in fact there is no DHCP server there?
I find these settings a bit odd too:
Pool start IP: 10.252.128.1
Pool end IP: 10.252.254.254
The OpenVPN server side is using an entire Class B network (255.255.0.0)?
And if you are using a separate VLAN for this bridge and OpenVPN server, is this the network you defined on that new VLAN? If so, the OpenVPN server's tunnel must also be bridged to that VLAN. I assume that by default it's always bridged to the default bridge (br0) unless you take steps to change it.
As I said, my OpenVPN server is running on the primary network of my other home, nothing special. That network is a common Class C network, 192.168.66.0/24, w/ a gateway IP of 192.168.66.1, and DNS server of 192.168.66.1. And my OpenVPN server config mirrors that simplicity:
Pool start IP: 192.168.66.230
Pool end IP: 192.168.66.234
So all I’ve done is reserve five (5) IPs (which reside outside the scope of the DHCP server on that side of the tunnel) for use by OpenVPN clients. Technically, you only need one (1) IP to get started. But as you add more routers, you’ll want to make more IPs available in the pool.
I’m just getting the impression that you’re not quite there yet in terms of visualizing this config correctly. Or else it’s me and I’m just not correctly interpreting your descriptions.
eibgrad, there is no dhcp on the vlan as the server router itself will be running dhcp for clients. Thats what the Pool start IP and Pool end IP settings are for, it is suposed to issue IPs to clients between this range (as it has been attempting as per my second screenshot, virtual IP column at the top). The problem is, the router believes it has issued these addresses as can be seen server side but the clients never actually receive them (or at least the attached PC doesn't). I think something is blocking this traffic as when I use wireshark I can only see broadcasts and arps from the main network.
The reason the address pool is so big is because I have some other networks in there statically set on the server side network. They are communicating and I can see traffic from them (broadcasts and arps only though) reach the client network.
See, this is where you're getting it wrong. At least if you expect it to work like my setup as I described earlier (that’s I went to trouble to describe it, to make sure we’re on the same page).
The only OpenVPN client in this setup is the router. The clients BEHIND the OpenVPN client are NOT OpenVPN clients! Therefore, as far as those clients behind the OpenVPN client are concerned, everything related to OpenVPN is irrelevant. They are merely clients of the remote network made available over the tunnel established by the OpenVPN client and OpenVPN server. And those clients need access to a DHCP server running on the remote network.
That's where you're messing up. You keep treating the clients behind the OpenVPN client of the router as if they too are OpenVPN clients. Again, they're NOT.
All you're doing here is using one OpenVPN client established by the router to create a tunnel. Think of it as a virtual ethernet cable from one router to another. After that, it just drops out of the picture. Clients behind the OpenVPN client of the router just simply use that connection as if it was an ethernet cable running from one router to the other.
eibgrad, if that were the case then why does the PC show as a client under the openvpn logs section of the web UI with an address issued too it (see the second attached picture). The server router sees both the client router and client pc and has issued addresses for both (or atleast thinks it had). I found a couple different documentation sources about this working but even without it I still get problems, I can manually set the client PC's IP but I can still only see arps and broadcasts, no addressed traffic.
I can't necessarily explain that status page because I don't know exactly what it's telling us. I do see two (2) IPs allocated from the pool, that's true. OTOH, both of those addresses are mapped to the same “real” address of 188.8.131.52.
If I had to guess what’s happening here? I’d bet you have NAT enabled on the OpenVPN client side. And so every request for DHCP is mapped to the OpenVPN client’s IP, and which in turn the OpenVPN server happily hands out yet another IP to that same OpenVPN client. IOW, OpenVPN server is seeing all these IPs as belonging to the OpenVPN client, not the clients behind the OpenVPN client.
Now granted, I making an educated guess here. That’s why I asked you previously to provide an image of your OpenVPN client config, not just the OpenVPN server. It’s easy to make mistakes on either side of this connection.
Here’s a direct quote from the OpenVPN documentation about the purpose of the server-bridge directive and the DHCP-Proxy option.
A helper directive similar to --server which is designed to simplify the configuration of OpenVPN's server mode in ethernet bridging configurations.
If --server-bridge is used without any parameters, it will enable a DHCP-proxy mode, where connecting OpenVPN clients will receive an IP address for their TAP adapter from the DHCP server running on the OpenVPN server-side LAN. Note that only clients that support the binding of a DHCP client with the TAP adapter (such as Windows) can support this mode. The optional nogw flag (advanced) indicates that gateway information should not be pushed to the client.
The reason I quoted this from the docs is because it makes clear what is the purpose of the IP Pool. If you specify DHCP-Proxy, the OpenVPN server will use the local DHCP server to configure OpenVPN clients. If you don’t use DHCP-Proxy, then it will configure those same OpenVPN clients based on Pool start IP, Pool end IP, etc. Nowhere in this description does it mention anything about NON OpenVPN clients being configured by this same facility. But yet, that’s what you’re claiming.
This doesn’t even make sense if you consider other factors. One of the problems often faced w/ bridged tunnels is preventing DHCP from crossing the tunnel (sometimes it’s not desirable). That’s why the dd-wrt OpenVPN server config offers the option to block DHCP (w/ firewall rules). Otherwise, those DHCP requests will end up being handled NOT by the OpenVPN server, but by the DHCP server of the remote network.
So your claims of the OpenVPN server configuring clients behind the OpenVPN client are not even consistent w/ this known problem, and the OpenVPN server’s attempt to address it w/ that Block DHCP option.