Posted: Fri Jan 15, 2016 18:29 Post subject: OpenVPN Bridged Site-to-Site (TAP) Routing Configuration?
Sorry posted in the wrong forum sections. Please move --> Advanced Networking
I have setup my Netgear R8000 & R7000 with DD-WRT v3.0-r28800M kongac (01/14/16) and have configured both the R8000 server and R7000 client with a bridged (TAP) OpenVPN setup. The connection between the two gateways is successful as shown on the both OpenVPN status pages, but I can't access anything from the server side subnet 172.16.4.0/24 from my client side subnet 172.16.5.0/24 and visa-versa.
If telnet/ssh into the (server at 172.16.4.1) from there I can only ping the other machines on the same 172.16.4.0/24 subnet and the single client IP 172.16.5.1 but not any other machines on the 172.16.5.0/24 subnet.
If telnet/ssh into the (client at 172.16.5.1) from there I can ping any machine and the server on either subnet 172.16.5.0/24 and 172.16.4.0/24 but the machines behind the DD-WRT client (at home) can't ping anything from behind the DD-WRT server (at work) side network?
I have NAT disabled on the DD-WRT client, because I would rather not have every machine hind behind a singe IP. But If I enable NAT for testing purposes, my machines (at home) on the client side network 172.16.5.0/24 can access the server side (at work) subnet 172.16.4.0/24. The server side still can't access the client side network though.
Would someone mind looking over my network diagram and server/client configurations and help me get this issue sorted out?
I hope this makes sense? Please ask if you have any questions.
I'll post the OpenVPN server and client configurations in the next two posts...
Thank you very much:!:
Robert aka Mrengles
Last edited by mrengles on Fri Jan 15, 2016 19:39; edited 2 times in total
I had the wrong Gateway for my Static Route on the DD-WRT OpenVPN Server You can see the image above shows 172.16.4.1, but it should be 172.16.4.51.
The Static Routing Gateway should be the same IP as the DD-WRT OpenVPN Client when setting up a Site-To-Site OpenVPN at last with my (this) particular setup. Its works this way at least.
Now I just need to figure out how to get OpenVPN -> Client -> Bridge TAP to br0 working.
Does anyone have any ideas what Firewall or other settings might be needed?
When I enable Bridge TAP on br0 on the client side DD-WRT gateway I loose access to the server and client subnets again, but the Bonjour and broadcasted servers show they just are not accessible to connect.
What's the point of a bridged VPN if both sides are using different IP networks (172.16.4.0/24 and 172.16.5.0/24)?
That's why the two sides can't see each other unless you NAT. Then one side has its source IP changed to the other network and voila, it sees it. For all intents and purposes, by NAT'ing, you're turning that bridged VPN into a routed VPN. That begs the question, why not just make it a routed VPN in the first place?
What you've done w/ this bridged VPN is comparable to having two different IP networks on the same ethernet switch. Neither can see the other. Not unless you do one of two things. Either bind every device to both networks (which while it works, makes no sense), or assuming they share the same default gateway, binding that default gateway to both networks, in which case the router routes between the two networks, albeit both in and out on the same physical ethernet segment (again it works, but doesn't make much sense).
IOW, it's pointless to have a bridged VPN unless both sides are on the same IP network. Otherwise, you just end up having to invent creative ways to turn it back into a routed configuration (e.g., NAT).
So either keep the two IP networks different and use a routed VPN, or else make both sides the same IP network and use a bridged VPN. But mixing the two is asking for trouble.
I think the real problem is you need to ask yourself what are you trying to accomplish?
If you simply would like to have the resources on the other subnet available to you routed vpn is the way to go. Only the traffic that is destine for the other subnet gets transmitted across the VPN which in my opinion is the most efficient way to do this, otherwise as Per Yugve Berg said all the broadcasts are going to be going back and forth over the VPN hogging up what little upload bandwidth you have available. My wide area network upload bandwidth at 50 megabits seems like not enough some days if there are several interoffice phone calls in progress as well as heavy database queries, and then I cant imagine stacking all the network noise on top of that.
When you say you want to much out of the VPN what is not delivering?
And I assume you got this all up and running by now.
I think the problem is just not having a full appreciation of the differences between a bridged and routed VPN.
As I said in my prior post, when you bridge networks together, what you're doing is joining them at the ethernet level. And the inference/assumption is that all those bridged devices will share the same IP network (e.g., 192.168.1.0/24). If they don't, if some devices are on one IP network and other devices on another IP network, the two networks can't see each other. In contrast, when both sides are using different networks, then you use a routed VPN.
But that's just the technical differences. What you have to decide is WHY you should choose one over the other. And that requires deeper analysis. You need to decide what you're trying to accomplish. That what will drive your decision. There are advantages and disadvantages w/ either option.
A bridged VPN is less secure in the sense that once you have devices sharing the same ethernet network, that have full access to those resources like any wired/wireless user connected locally. But whether that's a good or bad thing depends on your expectations. If I'm inviting my neighbor to have access to a few resources on my network (NAS, media player), there's no need to bridge the two networks. In fact, I can't firewall off the other resources I don't want him to have access to unless it's a routed VPN. OTOH, if I'm connecting two homes that I own, then obviously I fully trust both sides, and so bridging the VPN perhaps is the better choice, esp. if I need things like network discovery to work across the VPN (that only works w/ bridged VPNs, not routed).
But even so, a routed VPN is still more likely to be the better option.
I have two homes, each connected over OpenVPN. Each side can connect to the other as a routed VPN. They're not even bi-directional (i.e., site-to-site, where one tunnel works in both directions). I don't want to create a dependency between the two sides. There may be times when I don't want the tunnel working in one direction or the other. For example, when I have renters at one home and only want to offer them guest access. So I disable the OpenVPN client on that side. But I can still gain access to that network from the other side using the local OpenVPN client.
So what would be a good case for a bridged VPN?
Suppose you had a company of 100 ppl. You decided you needed more space, so you opened a satellite office across town and sent half the staff over there to work. Wired/wireless is not really an option, but there's always the internet. In this case, it would be silly to place the new office on a completely different IP network and use a routed OpenVPN. If it wasn't for this issue of distance, you've have everyone on the same ethernet network. The only purpose the bridged OpenVPN is serving is as a "virtual ethernet cable" between the local switches at each location.
Contrast that to two different companies, XYZ.com and ABC.com. They too are connected over OpenVPN, but it's routed. And that's because there's no need to insist that both sides be using the same IP network just to gain access to a few resources. In fact, each side typically wants to limit access w/ local firewalls. A bridged VPN would require both sides to use the same IP network and provide unfiltered access. So a bridged VPN is out of the question.
IOW, deciding between a bridged vs. routed VPN is not just a casual, thoughtless, cosmetic substitution of one for the other, like choosing between red and blue. They are not just different means to the same ends, but different ends achieved through different means.