Hello, first let me introduce the scenario: I am running two home networks (two locations) that each have a direct connection to the internet and run an OpenWRT router with dnsmasq to do DHCP and DNS services. In addition OpenWRT connects the two sites in bridge mode such that both sites have full access two all services on both sides (OK, at present only one network has a server, but this may change) while maintaining direct connectivity to the internet. Some devices (two laptops and an android phone) roam between the two locations. The typical problem with bridge scenario is that there should be just one DHCP as – at least with dnsmasq - there is no way to restrict service to the local network. An alternative is to run two DHCP servers that ignore certain devices that are not considered to be local, however then roaming devices will get a poor connection to the internet via the bridge only, and none at all when the bridge fails. If we number the solutions 1) one DHCP server, 2) classifying the clients, then the other standard solutions I am aware of are: 3) don´t use a bridge but routing, but that limits connectivity to IP based services, and broadcast/multicast based services can be an issue. E.g. WOL does not pass transparently. 4) filter DHCP via ebtables – but this requires to recompile the OpenWRT kernel, can cause performance issues for all bridged networks, and I also have no experience with that kind of configuration. 5) use the undocumented packet filter in OpenVPN, but it looks like this is also difficult to script… Thus I came up with the idea to modify OpenVPN to suppress DHCP requests received from the local network. OpenVPN receives the DHCP request via device tap0, and the processing is in [code]process_incoming_tun (struct context *c) { // some code omitted… /* Show packet content */ dmsg (D_TUN_RW, "TUN READ [%d]", BLEN (&c->c2.buf)); // check for DHCP request packets. Ingore the possibility of IP options. // drop just host->server for the usecase of suppressing non local DHCP hosts // check UDP and port first, then IP and MAC header, for speed if ((c->c2.buf.len >= 38) && (c->c2.buf.data[c->c2.buf.offset+37]== 67) // UDP destination && (c->c2.buf.data[c->c2.buf.offset+36]== 00) && (c->c2.buf.data[c->c2.buf.offset+35]== 68) // UDP source && (c->c2.buf.data[c->c2.buf.offset+34]== 00) && (c->c2.buf.data[c->c2.buf.offset+23]==0x11) // UDP protocol identifier && (c->c2.buf.data[c->c2.buf.offset+14]==0x45) // IP version and header length, ignoring the possibility of options && (c->c2.buf.data[c->c2.buf.offset+13]==0x00) // MAC encapsulation of IP && (c->c2.buf.data[c->c2.buf.offset+12]==0x08)) { msg (D_TUN_RW, "discarded DHCP request [%d] : %s", BLEN (&c->c2.buf), PROTO_DUMP (&c->c2.buf, &gc)); c->c2.buf.len = 0; // discard frame } if (c->c2.buf.len > 0) { // more code omitted… }[/code]I installed that on both sides of the bridge and at least for the limited testing I did so far it works nicely. Of course one can argue whether this is the correct approach to address the issue, but as I point out above, several other options are not adequate in my opinion, and when I look at the OpenVPN documentation, OpenVPN is quite aware of DHCP for the routing scenario and supports plenty of options – why not add an option to suppress DHCP requests in the bridging scenario. I am willing to contribute a modification that adds a configuration option (e.g. filterdhcprequests), but before investing more time, I would like to understand the process and collect feedback on both the approach and the specific implementation. Of course I would also appreciate someone experienced in processing optons and the process to take this up and implement it... Best regards, Joachim

Hi Stephen, [quote="gladiatr72"]So, yeah: Consider kicking the tunnel up to layer 3 and solving all of your networking design problems rather than patching OpenVPN :) [/quote]Wrong - the network design should support the applications I want to run, to the extend possible and with reasonable service level. And not v.v. as you suggest, a "proper" design limit what applications I can run or what service level will result. And ultimatley I don´t care whether it is configuration or code, this is a matter of standardization most of the time, and sometimes also of performance. I really explained what I want to do - maybe read once more? I want direct connection to the internet for each location, and the experience of one local network spanning the two locations for applications like windows networking, including NetBios, mDNS, UPnP and WOL, for which the broadcast/multicast definition is important. You can suggest to run several application level gateways to address this, but the question is whether this is more effective than running a "non-standard" design as I suggest. Actually I spent more time researching the internet for suggestions than it took me to patch OpenVPN, and I assume - I´d did not try - it took me less time doing the patch than to recompile the kernel with ebtables and learn how to configure it - thus I picked that route because I expected it to take less time and provide better performance and not because I am a programmer (actually not my primary job). I observed lots of discussions where an expert responded like you, and the discussion ended without a solution. I´d really want to encourage others to say whether they are interested in a solution like this, or experts to really outline a solution that is practical. Thanks & Best regards, Joachim

Just one question, which for sure will be asked in the meeting. [b]Why isn't normal firewalling sufficient? Why do we need to do this kind of firewalling inside OpenVPN?[/b] I am very sceptical to such a change, it looks more like bloating OpenVPN code base in my eyes. But that is my personal opinion.

OpenVPN to filter DHCP requests in bridge mode

jol

Hello,

first let me introduce the scenario: I am running two home networks (two locations) that each have a direct connection to the internet and run an OpenWRT router with dnsmasq to do DHCP and DNS services. In addition OpenWRT connects the two sites in bridge mode such that both sites have full access two all services on both sides (OK, at present only one network has a server, but this may change) while maintaining direct connectivity to the internet. Some devices (two laptops and an android phone) roam between the two locations.

The typical problem with bridge scenario is that there should be just one DHCP as – at least with dnsmasq - there is no way to restrict service to the local network. An alternative is to run two DHCP servers that ignore certain devices that are not considered to be local, however then roaming devices will get a poor connection to the internet via the bridge only, and none at all when the bridge fails.

If we number the solutions 1) one DHCP server, 2) classifying the clients, then the other standard solutions I am aware of are: 3) don´t use a bridge but routing, but that limits connectivity to IP based services, and broadcast/multicast based services can be an issue. E.g. WOL does not pass transparently. 4) filter DHCP via ebtables – but this requires to recompile the OpenWRT kernel, can cause performance issues for all bridged networks, and I also have no experience with that kind of configuration. 5) use the undocumented packet filter in OpenVPN, but it looks like this is also difficult to script…

Thus I came up with the idea to modify OpenVPN to suppress DHCP requests received from the local network. OpenVPN receives the DHCP request via device tap0, and the processing is in

process_incoming_tun (struct context *c)
{
// some code omitted…
  /* Show packet content */
  dmsg (D_TUN_RW, "TUN READ [%d]", BLEN (&c->c2.buf));

// check for DHCP request packets. Ingore the possibility of IP options.
// drop just host->server for the usecase of suppressing non local DHCP hosts
// check UDP and port first, then IP and MAC header, for speed

  if ((c->c2.buf.len >= 38) 
	&& (c->c2.buf.data[c->c2.buf.offset+37]==  67) // UDP destination
	&& (c->c2.buf.data[c->c2.buf.offset+36]==  00)
	&& (c->c2.buf.data[c->c2.buf.offset+35]==  68) // UDP source
	&& (c->c2.buf.data[c->c2.buf.offset+34]==  00)
	&& (c->c2.buf.data[c->c2.buf.offset+23]==0x11) // UDP protocol identifier
	&& (c->c2.buf.data[c->c2.buf.offset+14]==0x45) // IP version and header length, ignoring the possibility of options
	&& (c->c2.buf.data[c->c2.buf.offset+13]==0x00) // MAC encapsulation of IP
	&& (c->c2.buf.data[c->c2.buf.offset+12]==0x08)) 
    {
      msg (D_TUN_RW, "discarded DHCP request [%d] : %s",
	       BLEN (&c->c2.buf),
	       PROTO_DUMP (&c->c2.buf, &gc));
      c->c2.buf.len = 0; // discard frame
    }

  if (c->c2.buf.len > 0)
    {
// more code omitted…
}

I installed that on both sides of the bridge and at least for the limited testing I did so far it works nicely. Of course one can argue whether this is the correct approach to address the issue, but as I point out above, several other options are not adequate in my opinion, and when I look at the OpenVPN documentation, OpenVPN is quite aware of DHCP for the routing scenario and supports plenty of options – why not add an option to suppress DHCP requests in the bridging scenario.

I am willing to contribute a modification that adds a configuration option (e.g. filterdhcprequests), but before investing more time, I would like to understand the process and collect feedback on both the approach and the specific implementation. Of course I would also appreciate someone experienced in processing optons and the process to take this up and implement it...

Best regards, Joachim

gladiatr72

You're a programmer, aren't you? Experienced sysadmins can spot you guys miles away (parsecs, even...) due to your tendency to want to fix everything with blocks of programmatic exceptions! 😃 (I love you all, regardless... without programmers there would have been no Quake!)

If I'm reading this correctly, why bother with the bridge at all? The only part of your thought process that I find a tad wonky is when you speak of the "local network". If you're bridging, there is only the local network. Link your networks with a routed configuration and your problem is solved. Whatever side of the link you are physically near, you're "on" that "local" network, but you can still reach the other side through your gateway due to a persistent vpn link.

Or perhaps I'm missing something as to what your goal is. Basically, you're trying to shortcut how IP works. DHCP sends broadcasts. If you're in its broadcast domain and are running a DHCP client, your system will respond. Even if you were to configure one of your DHCP servers to negatively respond to a particular MAC address, it's still responding and your cilent will probably shut down when it receives the negative response from this system. Now, granted, one of them is on the other side of a comparatively slow link, but there would still be the potential for a race condition which renders this idea... unwise.

So, yeah: Consider kicking the tunnel up to layer 3 and solving all of your networking design problems rather than patching OpenVPN 🙂

Anyway, good luck.

Regards,
Stephen

jol

Sorry, we encountered an error while displaying this content. If you're a user, please try again later. If you're an administrator, take a look in your Flarum log files for more information.

krzee

https://community.openvpn.net/openvpn/wiki/Topics-2011-01-13
this is now on the topics list for todays dev meeting
feel free to drop by #openvpn-devel on freenode at 18:00 UTC if you would like to talk about it in the meeting

dazo

Just one question, which for sure will be asked in the meeting.

Why isn't normal firewalling sufficient? Why do we need to do this kind of firewalling inside OpenVPN?

I am very sceptical to such a change, it looks more like bloating OpenVPN code base in my eyes. But that is my personal opinion.

jol

Sorry, I read this a few minutes ago, and no clue about how the discussion went so far. And I really appreciate that the suggestion is discussed already, even if you disagree with the proposal.

dazo wroteJust one question, which for sure will be asked in the meeting.

Why isn't normal firewalling sufficient? Why do we need to do this kind of firewalling inside OpenVPN?

I am very sceptical to such a change, it looks more like bloating OpenVPN code base in my eyes. But that is my personal opinion.

firewalling with iptables works on layer 3 and will not work as I am using bridge mode (layer 2). firewalling with ebtables might work, but a) requires recompiling the kernel of OpenWRT (the platform I am using) which personally looked more complicated to me than patching OpenVPN, b) will cause a permanent performance hit for all traffic in all networks bridged (which in my case includes wlan, ethternet, and tap), not just the traffic passing the bridge, and there just a small fraction.
As with respect to bloating the code base - OpenVPN already contains a lot of support for handling DHCP configuration for routed scenarios - adding code to filter DHCP in a bridge scenario is in my opinion featurewise complimentary - except that it is in a method executed all the time instead of connection establishment only. If you prefer, adding an ebtables like mechanism or documenting how the packet filter can be used to accomplish the same is also fine, but for the very specific usecase looks over engineered to me.
Thanks & Best regards, Joachim

dazo

jol wrote firewalling with iptables works on layer 3 and will not work as I am using bridge mode (layer 2). firewalling with ebtables might work,

Yes, ebtables is the right tool for this.

jol wrote but a) requires recompiling the kernel of OpenWRT (the platform I am using) which personally looked more complicated to me than patching OpenVPN,

I'm sorry to be harsh, but I have no sympathy for this. Reinventing a wheel inside openvpn when you do have tools on the outside which is explicitly made for this job is the wrong path. The next thing is that someone wants to block MSN via the tunnel, and proposes a similar patch to yours, and then the next guy wants to block port 39482 for some reason ... this is the wrong path.

It's a while since I used the stock OpenWRT image (I compile my own nowadays), but I was pretty sure ebtables was available via opkg.

jol wrote b) will cause a permanent performance hit for all traffic in all networks bridged (which in my case includes wlan, ethternet, and tap), not just the traffic passing the bridge, and there just a small fraction.

Well, the OpenVPN source code is there for you, feel free to patch it yourself.

jol wrote As with respect to bloating the code base - OpenVPN already contains a lot of support for handling DHCP configuration for routed scenarios - adding code to filter DHCP in a bridge scenario is in my opinion featurewise complimentary - except that it is in a method executed all the time instead of connection establishment only.

To some degree, OpenVPN implements some DHCP filtering in one very specific setting. It filters only the DHCP ROUTE message. Why? If you use bridging together with --route-gateway, it will otherwise break the client's Internet connection, as the client will change the default gateway to a host which is not reachable outside the tunnel. That is the only reason that filter is there. What you are asking for is to tell OpenVPN to block normally legitimate traffic over the tunnel, which is the task of a firewall. And your "fix" blocks all UDP port 67/68 traffic - no matter what the contents is.

If you insist on doing it in OpenVPN, then at least have a closer look at the existing PF implementation and propose a patch which extends it to support configurable protocol (tcp/udp/icmp/igmp) and port numbers. The current implementation only supports filtering based on IP addresses. Then you can use the energy on something which is way more usable for more users than your corner case.

jol wrote If you prefer, adding an ebtables like mechanism or documenting how the packet filter can be used to accomplish the same is also fine, but for the very specific usecase looks over engineered to me.

LOL ... I really hope you're not serious now. ebtables is designed for doing layer 2 filtering. That's a tool which is available practically right under your nose. Writing a patch which hard-codes DHCP traffic filtering on packet level in OpenVPN, compiling and testing it yourself is not over-engineering? .... I mean, come on ...

However, the packet filter is pretty well documented here: http://backreference.org/2010/06/18/openvpns-built-in-packet-filter/
That's also written by a guy who has contributed to the OpenVPN source code already.

Anyway, the meeting minutes will be posted in a few days to the openvpn-devel list. You can see the dialogue there regarding this issue. This patch is a NAK anyway, so this is a dead-end as it is now.