Providing ipv6 through openvpn part 2: Routing additional subnets

Consider the following situation:

+-------------------------------------+
| Local office network, private ipv4  |
|                                     |
| gateway with only ipv4 access       |
+---+---------------------------------+
    |
 Internet (ipv4)
    |
+---+---------------------------------+
|Hosted server with openvpn and ipv6  |
+-------------------------------------+

Using the openvpn setup from the previous post, it is possible to assign ipv6 addresses to the gateway of a local office network where ipv6 is not readily available.  If additional ipv6 subnets are available, these can be assigned to the office network behind this gateway and routed to the internet through OpenVPN. This post describes the extra settings needed to do that.

“Providing ipv6 through openvpn part 2: Routing additional subnets” verder lezen

Providing ipv6 access through openvpn part 1: assigning ipv6 addresses to openvpn clients

While ipv6 is becoming more common, not many ISP’s do provide ipv6 addresses to their customers. But what if you have some ipv6 /64 subnets, e.g. on a hosted server, and you want to provide ipv6 access to locations that only have ipv4? Simply become your own ipv6 provider, using OpenVPN!

In this post, we explain how openvpn can be used to add ipv6 access to clients that only have an ipv4 connection to internet. The next post extends this example to routing ipv6 subnets through openvpn, allowing every machine in the office network behind the openvpn client to have ipv6 access.

To provide openvpn clients with ipv6, you need a server that has both an ipv4 address and some unused ipv6 /64 subnets. The OpenVPN server will be accessible through ipv4, and an ipv6 /64 subnet can be routed through the OpenVPN Tunnel.

“Providing ipv6 access through openvpn part 1: assigning ipv6 addresses to openvpn clients” verder lezen

Verlopen OpenVPN CA certificaat, wat nu?

Bij het opzetten van een OpenVPN maak je vaak gebruik van een eigen certificaatautoriteit (CA). Bij OpenVPN gebeurt dat vaak met de EasyRSA scripts. Volg je daar de instructies, dan bouw je een CA waarvan het root-certificaat 3650 dagen geldig is, bijna 10 jaar.

Hoewel het in ICT-land niet vaak voorkomt, blijkt een OpenVPN-oplossing vaak ongemerkt jaren lang mee te gaan en zo kan het gebeuren dat op een zeker moment het niet alleen (of juist niet) het certificaat van een openvpn client is verlopen, maar dat van de CA zelf!

In deze posting bekijken we wat er dan gebeurt, en hoe dat op te lossen is. Op zich is het natuurlijk verstandig om een nieuwe CA te maken en voor alle clients nieuwe certificaten te genereren. Dat kan echter logistiek lastig zijn. In plaats daarvan is het ook mogelijk een nieuw CA certificaat te maken, dat het oude vervangt, maar dat ondertekend is met dezelfde private key.
Lees verder