OpenVPN TAP Bridge Firewall
-
I have an openvpn TAP setup and bridged to lan for several remote users to connect into my network. The client side of the openvpn is handled by some small routers I have with openvpn client capability. The problem here is that while this works pretty well, one user installed their router with a loop (lan to lan) to their home router causing their home router to issue dhcp to several other clients on the network. I am trying to block this with a firewall on the bridge to block anything on port 67 other then my dhcp server or by blocking all port 67 incoming on the openvpn interface however this is not applying correctly for some reason. I have enabled net.link.bridge.pfil_bridge and have tried the firewall rule on all relevant interfaces (LAN, OPENVPN, TAP INT, and Bridge INT) but cant seem to get it to work. Does anyone know what I am doing wrong?
-
Are you logging the traffic thats coming through the openvpn connection to see whats happening?
-
Remember you have to set net.link.bridge.pfil_member to 0 and net.link.bridge.pfil_bridge to 1 in order to have a bridge behavior. Meaning that the bridge itself will be the interface having an IP and all its member interfaces will have none. So you have to apply all filtering on the bridge. Contrary to the default options on net.link.bridge, where you apply the filtering on each member interface.
The problem you have is known as "DHCP rogue". Usually ppl try to deal with it using layer 1. Isolating it. (or obliterating it ;D )
Probably you are trying to filter the DHCP negotiation on layer 3 (IP). But it happens on layer 2 also (MAC address). Beginning with a broadcast (destination 255.255.255.255) (source 0.0.0.0).
I would consider totally blocking the rogue router till it changes it's configuration. Or reviewing your openvpn isolation on clients. -
I have net.link.bridge.pfil_member = 0, no problems there. Client Isolation is not an option unfortunately as client intercommunication is required for the purpose of this VPN. It was my understanding that the dhcp client broadcasts its request from port 68 (out) to port 67 and then the server responds using its direct address and thus you could block anything not my server sending messages on port 67 (if this is incorrect or needs to be clerified then please let me know). I have blocked the rogue router for now, this is more of a preventative measure to stop this from reoccurring as we issue more clients.
-
You've tried to create a rule (first positions) to allow traffic from your dhcp to broadcast (255.255.255.255) with source port 67 and destination port 68, followed by a rule that denies all traffic from any ip to broadcast using same ports as before, right?
The situation here is there's no guarantee the traffic will be filtered. As the 'offer' procedure from the dhcp server will be broadcasted using 255.255.255.255, but (now, instead of using ff:ff:ff:ff:ff:ff as in the 'request') directed to the machine's MAC address that made the 'request' (considering that the client doesn't have an IP address yet).
So, by default, the traffic will be broadcasted through the entire network domain, but rejected on layer 2 by everyone that doesn't have the destination MAC address. Take into account the switches and bridges involved the broadcast. And remember that the TAP interface is designed to act as a switch on layer 2.
Therefore usually you must know the source of this kind of attack to block it (preferably MAC).
Hope it helps you at least a little bit. :)
Feel free contact me if you feel that could be of any help. -
OP, can you share with us why you went with a bridged solution to begin with?