Tweet
For years, OpenVPN has been using four IP addresses for each single client connection, just to keep Windows XP happy. This era is finally over - and with it, the needless waste of innocent IP addresses that could be helping someone work from home. Join us in the second part of our series about our latest OpenVPN update.
Exhausting (Private) IP Address Space
OpenVPN supports pretty much any operating system out there. One of those compromises was made long ago to work around Windows XP’s broken network stack. Since then, OpenVPN used to allocate not only one, but four IP addresses to each client. This used to be called net30 internally and got the 30 in the name because of carving out a /30 subnet from the larger OpenVPN address pool like this:
Assuming you have allocated 10.0.0.0/24 as subnet for the OpenVPN clients, one possible subnet with exactly four addresses could be 10.0.0.128/30. Of course we cannot use the network address, so the first usable address is 10.0.0.129 which is being assigned to the OpenVPN server. The next address is 10.0.0.130 which will be assigned to the client. And the fourth address, you are asking? Well that is technically the "broadcast" address 10.0.0.131, but since we are building a layer 3 VPN there is no such thing as broadcast packets. So we lose both, the first and the last address of this subnet of four and can only use two.
Pretty wasteful, isn't it?
And this all for some legacy operating system.
From now on, each client simply gets one IP—just like IPsec or WireGuard—while all share a common gateway. Any formerly reserved IP address space will now be able to be assigned to a client.
It’s a small but important step toward a leaner, more future-proof OpenVPN on IPFire.
Let's Decompress A Bit
Another important step is to remove compression from OpenVPN as it has been a huge attack vector since VORACLE. But since OpenVPN used to rely on static configuration, this is not as easy as it seems. Clients might still have compression enabled and will send compressed packets to the server. The result is simply no data flowing.
With this update, the OpenVPN server will not send compressed packets any more. Almost always. It will tell each connecting client to do the same, but some might not listen and still send compressed frames which will then be accepted and decompressed by the server if there is no other way. That will ensure that we will keep everything working as it was and we will still eradicate all risks from this attack wherever possible.
In future versions, this compatibility mode will be removed from OpenVPN and therefore we urge you to update all clients to the latest supported OpenVPN version as soon as possible.
More...
