OpenVPN is a virtual private network (VPN) system that allows to create secure encrypted point-to-multipoint connections in routed (TUN) or bridged (TAP) modes. Up to four instances (clients and/or servers) can be used simultaneously in one unit. Each server is capable of establishing connections with several tens of clients.
OpenVPN allows peers to authenticate to each other using pre-shared secret keys and certificates. An OpenVPN server is capable to release an authentication certificate for every client, using signatures and certificate authority (certificates can be generated / uploaded in the SETTINGS > Security > Credentials menu).
A time synchronization of individual units is required for proper OpenVPN function.
All the configuration parameters are explained within the manual. The application notes will describe you several use-cases and step-by-step configurations, including screenshots and basic explanations. Eventually, OpenVPN debugging is explained.
Note: All the M!DGE3 or RipEX2 units run 2.1.1.0 firmware.
The topology depicts one OpenVPN server and two OpenVPN clients. M!DGE3 and RipEX2 share the same GUI and are configured exactly the same way. RipEX2 in the diagram is equipped with the LTE extension so it can be connected both to the cellular and radio networks.
The 1st example shows a configuration in which all the units utilize different LAN subnets, i.e., interconnecting them via one shared and secured OpenVPN network to build one secure end-to-end routed network.
The cellular APN is a private APN with specified IP addresses within 10.203.0.0/17. Each device can “see” (ping) each other, but cannot access public Internet. While testing or configuring your scenario, you need to edit all the 10.203.0.0/17 IP addresses to suit your topology.
Note: Keep in mind the connections via the cellular network require some kind of VPN or at least NAPT so that packets can go LAN2LAN. Adding just static routing rules would end by discarding such traffic being discarded in operator’s network.
MIDGE3_Server will be set as the OpenVPN server. Set the Unit name “MIDGE3_Server” in the SETTINGS > Device > Unit menu.
Make sure to have correct and the same time in all units. OpenVPN works with certificates and their validation times so the correct time sync is required.
Set a correct Time zone (Europe/Prague) and NTP server (10.203.0.1) in the SETTINGS > Device > Unit > Time menu. Even if you do not have a working NTP server in your network, at least manually set a correct time, because each M!DGE3 and RipEX2 are equipped with the RTC and should be able to keep the proper time over the years even without the NTP server. NTP server is a recommended solution though – consider one unit within the network to be equipped with GPS – such unit would provide precise time to the rest of the network.
Go to the SETTINGS > Security > Credentials > Settings menu and configure a Common Name for our MIDGE3_Server – “midge3_server”. CNs are very important for proper OpenVPN certificates.
All the units are in the Factory settings so we need to configure proper Ethernet and Cellular interfaces and also Routing.
Go to the SETTINGS > Interfaces > Ethernet > Network interfaces menu. Set the IP of the ‘bridge’ interface to be 192.168.1.1/24.
Go to the SETTINGS > Interfaces > Cellular menu. Set the interface to suit your APN setup (APN name, credentials, MTU, …). We also suggest setting the “Link testing” option so that M!DGE3 periodically pings a defined IP address via the cellular interface. If the ping is not working correctly, the cellular connection is restarted (which may help in particular situations).
Go to the SETTINGS > Routing > Static menu and add one static route. The Destination should either be the APN subnet, or a complete default gateway (0.0.0.0/0). Set the Mode to “WWAN (MAIN)”.
Save the changes now. OpenVPN configuration follows.
Go back to the SETTINGS > Security > Credentials menu. Click on the “Generate credential” button. Select “Certificate key (PRI)” option to generate a private key. This private key is going to be a private key of our Local CA (Certification Authority). Let’s name it “ca_key”.
Once completed, create the CA’s public certificate by clicking on the Generate credential button again. Set the ID to be “ca_cert” and the Type “CA chain (PUB)”.
Go to the “Settings” tab within the same menu and enable this MIDGE3_Server to be a local CA and specify created key & certificate.
Save the changes.
From now on, we can use MIDGE3_Server as a trusted source for generating and signing keys for OpenVPN server and clients. Go back to the “Credentials” tab and generate another private key, now for the MIDGE3_Master again, but for the OpenVPN server itself (not the CA).
Generate a new OpenVPN server certificate. Set
ID to “ovpn_server_cert”
Type to “Certificate (PUB)”
Certificate key to our generated key “ovpn_server_key”
and Certificate modifier to “OpenVPN server” – this is not mandatory, but it improves the VPN tunnel security – primarily it protects any client to mimic it is a server (strict roles for each certificate usage – server, or client).
These two files with the “ca_cert” are enough for the OpenVPN server. We can still improve a security by additional TLS Protection – either “TLS auth” or “TLS Crypt”. TLS Auth helps against port scanning, UDP floods or DoS. TLS Crypt does the same, and adds some additional protection against sniffing certificate attributes or OpenVPN presence.
We will configure the TLS-Auth option. Generate a new shared key with ID equal to “ta_key”. Select a type to be “OpenVPN TLS Protection key (PRI)”.
All the files for the OpenVPN server are ready. Go to the SETTINGS > VPN > OpenVPN menu. Enable OpenVPN service and click on the “Add tunnel” button. Select a mode to be a “server”.
Open the “Edit tunnel” menu. Select the required tunnel parameters. We leave all in defaults, except:
Assign dynamic client addresses “On”
Private key ID “ovpn_server_key”
Certificate ID “ovpn_server_cert”
CA certificate ID “ca_cert”
Cipher “AES-256-CBC”
HMAC authentication “SHA256”
DH parameters ID “_RO_Web_DH_Param”
Enhanced TLS protection “On”
TLS protection shared key ID “ta_key”
Confirm the settings.
Click on the “Edit clients” button. Add two clients, set the 1st client:
Certificate Common Name midge3_client01
Address assignment Dynamic (within 10.8.0.100 – 200 address range)
Client routes 192.168.2.0/24
And 2nd client:
Certificate Common Name ripex2_client02
Address assignment 10.8.0.5
Client routes 192.168.3.0/24
The configured routes are particular clients’ LANs which are then propagated to the Server and to each Client for direct client-to-client communication.
Close the window and click on the “Edit server routes” button. Configure a network 192.168.1.0/24 to be pushed to connected clients. This range is the Server’s LAN segment.
Apply all the changes.
Once completed, the OpenVPN server is ready, but we still need to configure both clients and generate/upload keys&certificates.
First of all, we need correct credentials (keys and certificates) for both the clients. We generate them via two different ways.
For the 1st client (midge3_client01), we will generate all in the server. Then, we will download them to our PC and upload them to the MIDGE3_Client01’s credentials.
For the 2nd client (ripex2_client02), we will generate them in the client itself, and we use our MIDGE3_Server CA to sign the generated CSR (Certificate Signing Request) – so it creates a valid certificate without a ripex_client02’s private key being shared/exposed. This procedure is more secure.
For now, stay in the MIDGE3_Server menu and go to the SETTINGS > Security > Credentials > Settings menu. Change the Organization Common Name (CN) to “midge3_client01”. Apply the changes.
Now, we can generate correct files for MIDGE3_Client01. Go back to the Credentials menu and generate a private key for MIDGE3_Client01’s OpenVPN. The ID is “midge3_client01_key”.
Generate a valid MIDGE3_Client01’s certificate for OpenVPN using the newly generated key. The ID is “midge3_client01_cert”, Type is “Certificate (PUB)”, Certificate key must be our “midge3_client01_key” and because we check the Extended Key Usage of the certificate, select the “OpenVPN client” modifier.
Download required files for the 1st client (MIDGE3_Client01):
ca_cert CA certificate
midge3_client01_cert client’s certificate
midge3_client01_key client’s private key
ta_key TLS Protection key (TLS-Auth)
You can either download them encrypted (using a strong password) or unencrypted. Select proper names if not fully satisfied with automatic file names.
Change the MIDGE3_Server Common name back to “midge3_server” and save the changes.
Login to the MIDGE3_Client01 unit and go to the SETTINGS > Security > Credentials > Settings menu. You can change the Common name to “midge3_client01”, even though it is not necessary.
Set the unit name to MIDGE3_Client01.
Configure the Time zone and NTP server to suit your environment.
Go to the SETTINGS > Interfaces > Ethernet and set the LAN IP to 192.168.2.1/24.
Enable and configure the SETTINGS > Interfaces > Cellular interface to suit your APN. Continue with adding the default GW via WWAN (MAIN).
Save and apply all the changes.
Go to the SETTINGS > Security > Credentials menu and add all four downloaded keys/certificates. You need to import each with a correct “Type”.
CA cert ID: ca_cert, Type: CA chain (PUB)
Client’s certificate ID: midge3_client01_cert, Type: Certificate (PUB)
Client’s key ID: midge3_client01_key, Type: Certificate key (PRI)
TLS-Auth key ID: ta_key, Type: OpenVPN TLS Protection key (PRI)
Go to the SETTINGS > VPN > OpenVPN menu. Enable the service and add the tunnel (Mode: Client).
Edit the tunnel to match the Server’s settings. Keep all parameters in defaults, except:
Private key ID midge3_client01_key
Certificate ID midge3_client01_cert
CA certificate ID ca_cert
Cipher AES_256_CBC
HMAC authentication SHA256
Confirm the changes.
Click on the “Edit servers” button and add one server. Fill in
Server address 10.203.0.28
Enhanced TLS Protection TLS Auth
TLS Protection shared key ID ta_key
Note: Your server address can be different, suit the setting to your APN.
Apply the changes.
You can check if this OpenVPN client has connected successfully, or not. If not, download a Diagnostic package and go through the OpenVPN logs to find possible reasons. You should also check all the OpenVPN parameters so that they match.
Login to the RipEX2_Client02 unit and go to the SETTINGS > Security > Credentials > Settings menu and set the Common name to be “ripex2_client02”. It is mandatory this time, because we will generate the client’s key and CSR on this unit, not in the server.
Note: Due to multiple same steps, some of the configuration screens are not provided.
Repeat most of the steps from the M!DGE3 unit as well.
Unit name to be RipEX2_Client02
Correct Time zone and NTP server
Ethernet bridge IP 192.168.3.1/24
Cellular settings to suit your APN with Link testing
Default (static) route, Mode: WWAN (EXT)
EXT is a must now, because setting RipEX2, not M!DGE3 device
Apply the changes.
Go back to the SETTINGS > Security > Credentials menu. Generate a private key. ID is “ripex2_client02_key”. Type is “Certificate key (PRI)”.
Generate CSR for this particular key. Click on the “Generate CSR” button located at this particular Credential window.
It downloads the CSR file into your PC. Login (locally or remotely) to MIDGE3_Server and go to the SETTINGS > Security > Credentials menu. Find the button “Sign CSR” next to the buttons with generating/uploading credentials.
Click on it and select the CSR file located in your PC. Select the Certificate modifier to be the OpenVPN client. Click on the Sign CSR button.
This downloads a valid certificate into your PC. Name it accordingly, e.g., “ripex2_client02_cert.crt”.
Go back to RipEX2_Client02’s web interface and add/upload this certificate. Set the ID to “ripex2_client02_cert” and Type to “Certificate (PUB)”.
Upload the CA certificate and the TLS Protection key the same way as in MIDGE3_Client01.
Go to the SETTINGS > VPN > OpenVPN menu, enable it and add one tunnel.
Edit the tunnel’s parameters:
Private key ID ripex2_client02_key
Certificate ID ripex2_client02_cert
CA certificate ID ca_cert
Cipher AES_256_CBC
HMAC authentication SHA256
Confirm the changes.
Edit the server settings. Add one server and set its address to 10.203.0.28 (it may differ for your APN). Enable Enhanced TLS protection with the ta_key.
Close the window and apply all the changes. Check if the client got connected and the assigned IP address for the tunnel is 10.8.0.5.
Within the SETTINGS > VPN > OpenVPN menu, open either the Server or Client status to see the details about currently connected units.
The MIDGE3_Server Status while both the clients are connected:
Important fields
Tunnel name Linux interface name (useful for firewalls, NAPT, …)
Common name CN of the client. Especially in case only know CNs are allowed to be connected.
Connected since Since what date&time the client is connected
Tunnel address Assigned OpenVPN tunnel IP address
Server address WAN IP address of the client
In case of the Client instance, there is “State” column – it can either be connected or disconnected.
Example of a client which cannot connect
A particular client is displayed in the Status, but has no Tunnel address assigned. And it also happens that such client is deleted from the Status within several seconds and may appear again within a while, …
The particular client’s Common name is not allowed to connect to the server – add it or fix a possible typo in the list of clients.
You should also try the DIAGNOSTICS > Tools > ICMP ping to check the accessibility of all LAN subnets. Either from the server to the client and back, or from client to client (it’s allowed by default).
Another place to check a current state is the DIAGNOSTICS > Information > Routing menu. Within the System routing tab, you should also see the particular VPN routes – via some “ovpn_” interface.
If some routing is missing, or is wrong, double check your server configuration – especially the Client and Server routes.
List of all interfaces can be displayed within the DIAGNOSTICS > Information > Interfaces menu. Try to find interfaces with “ovpn_” prefixes.
If you encounter any advanced connectivity/configuration issues, you can download the Diagnostic package within the DIAGNOSTICS > Information > Diagnostic package menu.
Once downloaded, you need to extract the file and open the directory with logs. Go through the OpenVPN logs and try to find any reason for issues.
More details about possible issues in the Troubleshooting chapter.
One typical network type is that all the end devices are within the same subnet (e.g. 192.168.1.0/24), but require a communication to each other via the RipEX2 Radio network or M!DGE3 cellular network. This is now possible using a secured channel via OpenVPN and its option to bridge particular interfaces together so that it creates a flat L2 topology over the routed scenario.
Note: It is possible to do it for the RipEX2 radio network operating in the Router mode as well.
The following example is just a continuation of the 1.1. chapter. We only do the required changes to match the desired IP topology and connectivity.
We will need to
Change the Network interfaces’ addresses in both the clients
Change the OpenVPN configurations in all the units to match the bridged (TAP) topology
Start with the RipEX2_Client02 unit. Go to the SETTINGS > Interfaces > Ethernet. Change the IP address to 192.168.1.3/24.
Go to the SETTINGS > VPN > OpenVPN menu and change the Type of the tunnel from Router (TUN) to Bridge (TAP). We only have one Network Interface (bridge) so the “Parent network interface ID” is automatically set to “bridge” and there is no other option. In case of multiple interfaces, select a correct one from the given list.
Apply all the changes.
Note: Based on type of connection to the client unit, you may be disconnected now.
Go to the MIDGE3_Client01 unit and do the similar changes
Change the Ethernet “bridge” Network interface IP to 192.168.1.2/24
Change the OpenVPN Tunnel type to Bridge (TAP)
Commit the changes as well.
Eventually, go back to the MIDGE3_Server and go to the SETTINGS > VPN > OpenVPN menu. Change the Tunnel type to Bridge (TAP) as well. Close window.
Click on the “Edit clients” button and delete both Client routes. Close the window.
Click on the “Edit server routes” button and delete the single line with 192.168.1.0/24.
Commit all the changes.
We have already explained multiple debugging/troubleshooting options. See below several hints while going through OpenVPN logs and solving connectivity issues.
OpenVPN logs are called openvpn_X and openvpn_diag_X where X is the OpenVPN tunnel ID. The 2nd log does not provide much information, it’s mostly our own diagnostics with basic connected/disconnected information.
openvpn_x logs
Server: client got connected
Ciphers negotiated
Connection information.
Assigning a client tunnel interface address
Reporting from the connection event script
2023-10-09T05:18:17+00:00 2023-10-09 05:18:17 10.10.1.55:54280 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 3072 bit RSA, signature: RSA-SHA256
2023-10-09T05:18:17+00:00 2023-10-09 05:18:17 10.10.1.55:54280 [Epsilon] Peer Connection Initiated with [AF_INET]10.10.1.55:54280 (via [AF_INET]10.10.1. 11%radio)
2023-10-09T05:18:17+00:00 2023-10-09 05:18:17 Epsilon/10.10.1.55:54280 MULTI_sva: pool returned IPv4=10.201.0.100, IPv6=(Not enabled)
2023-10-09T05:18:17+00:00 ===== Client Epsilon (10.10.1.55:54280) connected. =====
Server: client got disconnected
2023-10-09T11:22:16+00:00 ===== Client Epsilon (10.10.1.55:54280) disconnected. =====
Client: connection to the server finished
Going to the “Connected state”
Ciphers negotiated
2023-10-09T05:18:04+00:00 2023-10-09 05:18:04 Initialization Sequence Completed 2023-10-09T05:18:04+00:00 2023-10-09 05:18:04 MANAGEMENT: >STATE:1696828684,CONNECTED,SUCCESS,10.201.0.100,10.10.1.11,1194,,
2023-10-09T05:18:04+00:00 2023-10-09 05:18:04 Data Channel: cipher ‘AES-256-GCM’, peer-id: 0
Client: The server does not respond to client’s connection trials
2023-10-09T05:12:10+00:00 2023-10-09 05:12:10 read UDPv4 [EHOSTUNREACH]: No route to host (fd=4,code=148)
2023-10-09T05:12:32+00:00 2023-10-09 05:12:32 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2023-10-09T05:12:32+00:00 2023-10-09 05:12:32 TLS Error: TLS handshake failed
Client authentication failure in the server:
Server:
2023-10-09T11:25:49+00:00 2023-10-09 11:25:49 10.10.1.55:40917 VERIFY ERROR: depth=1, error=self-signed certificate in certificate chain: O=RACOM, OU=Development, L=Bystrice n. P., ST=CR, C=CZ, CN=Alfa, emailAddress=sectech@racom.eu, serial=22739517585033819111443524660849504900645973455
2023-10-09T11:25:49+00:00 2023-10-09 11:25:49 10.10.1.55:40917 OpenSSL: error:0A000086:SSL routines::certificate verify failed
2023-10-09T11:25:49+00:00 2023-10-09 11:25:49 10.10.1.55:40917 TLS_ERROR: BIO read tls_read_plaintext error
2023-10-09T11:25:49+00:00 2023-10-09 11:25:49 10.10.1.55:40917 TLS Error: TLS object -> incoming plaintext read error
2023-10-09T11:25:49+00:00 2023-10-09 11:25:49 10.10.1.55:40917 TLS Error: TLS handshake failed
Client:
2023-10-09T11:26:43+00:00 2023-10-09 11:26:43 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2023-10-09T11:26:43+00:00 2023-10-09 11:26:43 TLS Error: TLS handshake failed
Server authentication failure in the client:
Server:
2023-10-09T11:33:26+00:00 2023-10-09 11:33:26 read UDPv4 [CMSG=8|ECONNREFUSED]: Connection refused (fd=6,code=146)
Client:
2023-10-09T11:33:44+00:00 2023-10-09 11:33:44 VERIFY ERROR: depth=1, error=self-signed certificate in certificate chain: O=RACOM, OU=Development, L=Bystrice n. P., ST=CR, C=CZ, CN=Alfa, emailAddress=sectech@racom.eu, serial=22739517585033819111443524660849504900645973455
2023-10-09T11:33:44+00:00 2023-10-09 11:33:44 OpenSSL: error:0A000086:SSL routines::certificate verify failed
2023-10-09T11:33:44+00:00 2023-10-09 11:33:44 TLS_ERROR: BIO read tls_read_plaintext error
2023-10-09T11:33:44+00:00 2023-10-09 11:33:44 TLS Error: TLS object -> incoming plaintext read error
2023-10-09T11:33:44+00:00 2023-10-09 11:33:44 TLS Error: TLS handshake failed
Server: Maximum number of connected clients exceeded:
2023-10-02T09:36:38+00:00 2023-10-02 09:36:38 10.10.1.55:32786 MULTI: new incoming connection would exceed maximum number of clients (1)
Server: The client’s connection is refused, because it’s not listed within the OpenVPN clients:
2023-10-09T11:39:21+00:00 2023-10-09 11:39:21 10.10.1.55:54272 TLS Auth Error: –client-config-dir authentication failed for common name ‘Epsilon’ file=’/var/run/openvpn/1/ccd/Epsilon’
2023-10-09T11:39:21+00:00 2023-10-09 11:39:21 10.10.1.55:54272 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
2023-10-09T11:39:21+00:00 2023-10-09 11:39:21 10.10.1.55:54272 TLS: tls_multi_process: initial untrusted session promoted to semi-trusted
2023-10-09T11:39:21+00:00 2023-10-09 11:39:21 10.10.1.55:54272 Delayed exit in 5 seconds
2023-10-09T11:39:21+00:00 2023-10-09 11:39:21 10.10.1.55:54272 SENT CONTROL [UNDEF]: ‘AUTH_FAILED’ (status=1)
2023-10-09T11:39:21+00:00 2023-10-09 11:39:21 10.10.1.55:54272 SENT CONTROL [Epsilon]: ‘AUTH_FAILED’ (status=1)
Client: The server is refused due to the Extended Key Usage (EKU) check:
2023-10-09T11:37:14+00:00 2023-10-09 11:37:14 VERIFY KU ERROR
2023-10-09T11:37:14+00:00 2023-10-09 11:37:14 OpenSSL: error:0A000086:SSL routines::certificate verify failed
2023-10-09T11:37:14+00:00 2023-10-09 11:37:14 TLS_ERROR: BIO read tls_read_plaintext error
2023-10-09T11:37:14+00:00 2023-10-09 11:37:14 TLS Error: TLS object -> incoming plaintext read error
2023-10-09T11:37:14+00:00 2023-10-09 11:37:14 TLS Error: TLS handshake failed
Link fragmentation is turned on, but the Peer has it turned off:
2023-10-02T08:05:54+00:00 2023-10-02 08:05:54 Beta/10.10.1.22:37547 IP packet with unknown IP version=0 seen
2023-10-02T08:06:05+00:00 2023-10-02 08:06:05 Beta/10.10.1.22:37547 FRAG_IN error flags=0x2a187bf3: FRAG_TEST not implemented
Server: Server has the compression enabled, but the client has it disabled:
2023-10-09T11:47:19+00:00 2023-10-09 11:47:19 Epsilon/10.10.1.55:57609 IP packet with unknown IP version=15 seen
Client: It has the compression disabled, but the server has it enabled and wants to enforce it:
2023-10-09T11:43:27+00:00 2023-10-09 11:43:27 Compression is not allowed since allow-compression is set to ‘stub-only’
2023-10-09T11:43:27+00:00 2023-10-09 11:43:27 OPTIONS ERROR: server pushed compression settings that are not allowed and will result in a non-working connection. See also allow-compression in the manual.
2023-10-09T11:43:27+00:00 2023-10-09 11:43:27 ERROR: Failed to apply push options
2023-10-09T11:43:27+00:00 2023-10-09 11:43:27 Failed to open tun/tap interface
TLS Auth: The peer side uses a different key:
2023-08-08 09:33:47 Authenticate/Decrypt packet error: packet HMAC authentication failed
2023-08-08 09:33:47 TLS Error: incoming packet authentication failed from [AF_INET]10.10.1.44:47771
TLS Auth: The peer side does not have TLS-Auth enabled:
2023-08-08 09:37:38 TLS Error: cannot locate HMAC in incoming packet from [AF_INET]10.10.1.44:47878
TLS Crypt: The peer side uses a different key:
2023-08-08 11:17:33 tls-crypt unwrap error: packet authentication failed
2023-08-08 11:17:33 TLS Error: tls-crypt unwrapping failed from [AF_INET]10.10.1.44:56203
TLS Crypt: The peer side does not have TLS-Crypt enabled:
2023-08-08 11:18:34 tls-crypt unwrap error: packet too short
2023-08-08 11:18:34 TLS Error: tls-crypt unwrapping failed from [AF_INET]10.10.1.44:59311
M!DGE3/RipEX2 devices support so called Events.
You can be notified about the clients being (dis)connected and about the tunnels being down via SNMP notifications, Alarm and Digital outputs or SMS.
You can also change the severities for particular events so it can e.g., display this important Event within the STATUS menu, or change the physical SYS LED diode color to red.
All Events can also be displayed and filtered within the DIAGNOSTICS > Events menu. Read more information about the Events in the manual.
OpenVPN is a well-known protocol and is compatible with any other OpenVPN enabled device, including older M!DGE2 cellular router.
You can do both, adding M!DGE2 into the existing M!DGE3/RipEX2 network or adding M!DGE3/RipEX2 to the existing M!DGE2 network.
Just configure the correct OpenVPN parameters and upload the keys and certificates.
Keep in mind that older M!DGE2 “Expert files” are no longer supported in M!DGE3/RipEX2 units. Configure the parameters manually (based on 2.1.1.0 firmware features).
Note: Keep the M!DGE2 software up-to-date. Check the Download section on our website: https://www.racom.eu/eng/products/cellular-router-midge.html#dnl_fwr.
Note: There can be multiple ways of doing the same. Consider the following text to be just one of the options. You can choose a different approach.
We start in the server by going to the SETTINGS > VPN > OpenVPN menu. Open the “Edit clients” menu and add a new client with a Certificate Common name equal to “midge2_client03”. Add its route to be 192.168.4.0/24.
Go to the SETTINGS > Security > Credentials > Settings menu. Change the Common name (CN) parameter to “midge2_client03” so that newly created certificate has a correct CN.
Commit the changes to the OpenVPN.
Go to the SETTINGS > Security > Credentials menu. Generate a private key and a certificate for this M!DGE2 unit.
midge2_client03_key Certificate key (PRI)
midge2_client03_cert Certificate (PUB)
Download them into your PC together with the OpenVPN TLS Protection key (PRI) “ta_key” and CA chain (PUB) “ca_cert”.
Change the MIDGE3_Server’s Common name back to “midge3_server” and commit changes.
The application note is not intended for M!DGE2 complete tutorial, but if you configure it from the factory settings, do not forget to:
set the Ethernet IP to 192.168.4.1/24 and change its DHCP address range
configure the Mobile interface correctly to suit your APN
our WWAN IP address will be 10.203.3.33/17
set the hostname to “MIDGE2_Client03”
set the correct NTP server and Time zone
set the correct Common Name (CN) within the Keys&Certificates to be “midge2_client03”
Go to the VPN > OpenVPN > Tunnel Configuration menu.
Set the Operation mode to “client”.
Set the Server IP to 10.203.0.28
Uncheck the “use compression” and “allow weak ciphers” options
Check the “use keepalive” option
Other parameters should stay in default and shall follow the server’s setup.
Apply the changes. Click on the Error message within the Authentication part of the menu.
But what about the OpenVPN TLS Protection key (PRI)? (TLS-Auth, ta.key)
This is not supported within the M!DGE2 web interface, but can be done different way.
Go to the VPN > OpenVPN > Tunnel configuration and click on the Download button. Save the ZIP file to your PC and unzip it. Open the openvpn-expert.conf file using a text editor and add one new line:
tls-auth ta.key 1
A complete file should be the same, or similar to:
client
remote 10.203.0.28 1194
proto udp
verb 3
auth-retry nointeract
nobind
auth-nocache
sndbuf 0
rcvbuf 0
ipchange “/etc/openvpn/tunnel0-ipchange”
passtos
up-restart
auth-retry nointeract
remap-usr1 SIGHUP
resolv-retry infinite
persist-key
persist-tun
auth SHA256
cipher AES-256-CBC
keepalive 10 60
ca ca.crt
cert openvpn-expert.crt
key openvpn-expert.key
dev tun
tls-auth ta.key 1
Now, copy & paste the OpenVPN TLS Protection key (PRI) file to the same folder/directory with the rest of the files within the Expert file. Name it “ta.key”. Zip all the files to the openvpn-expert.zip file again.
So, the differences are:
the configuration file includes the tls-auth ta.key 1 directive
the ZIP includes the ta.key file
Go back to the MIDGE2_Client03’s web interface and VPN > OpenVPN > Tunnel Configuration menu. Erase the current OpenVPN settings.
Set the Operation mode to “client” again, but set the “expert mode” now.
Keep the “Routed” option set and uncheck the “allow weak ciphers” option. Select the updated ZIP file and apply the changes.
Go to the OpenVPN’s Administration menu and enable the tunnel.
Go to the HOME menu and check if the client gets connected, or not.
If you go to the OpenVPN details, you should e.g. see the assigned OpenVPN IP address.
You can go to the SYSTEM > Network debugging > ping menu and try to ping 192.168.1.1 IP address of the server or 192.168.2.1 MIDGE3_Client02 IP address.
You can check the routes within the ROUTING > Static routes menu. You should see all the remote networks accessible via TUN interface.
Last, but not least, you can also download a Techsupport package and check the logs for any issues. Do it from the SYSTEM > Tech Support menu.
Logs can also be viewed online if you connect to the M!DGE2 SSH. You can also do advanced debugging directly from the Linux command line in M!DGE2.
Requirement can also be the other way. You have a working M!DGE2 network utilizing the OpenVPN connections. Now you bought M!DGE3 as well and just need to add a new client.
The application note will not show the step-by-step configuration with all the screenshots, but will help you with required steps. Most of the following steps are covered within the application note so just go through previous examples if you encounter any obstacle.
Configure your M!DGE3/RipEX2 to connect to your APN and configure all other required parameters such as NTP, Network Interfaces, Common name, …
Add a new client in your M!DGE2 server and set its network(s)
Generate valid credentials (Keys & certificates) in your M!DGE2 server (or e.g. in some external CA)
Upload/Add the client’s key, client’s certificate, CA chain and if required, the TLS-Auth/TLS-Crypt key to your M!DGE3/RipEX2
Configure your M!DGE3/RipEX2’s OpenVPN with valid credentials and correct parameters to suit your server settings
Several screenshots to help you.
Note: You may also change the Common name of the M!DGE2 server before generating the client’s certificate even though there is no “Certificate modifier” option in M!DGE2 so the “Verify peer certificate usage“ parameter in M!DGE3/RipEX2 should probably be disabled.
M!DGE2 OpenVPN server only supports a “Network topology” option “Net /30”. This is not configurable in clients, but is driven by the server. Just keep this in mind while interconnecting various devices within one OpenVPN network. The network is either “Net /30” or more up-to-date option “Subnet”. It cannot be combined. M!DGE2 and M!DGE3/RipEX2 support both options, but M!DGE2 cannot set it for the Server, it can only adapt to it as a client.
If you have any issues, contact our technical support at support@racom.eu.
In the most basic scenario, each client connects to one server defined by its parameters and its IP address. In more robust solution, we may have multiple servers due to high availability requirement, because in case of one server failure, the other one can work instead.
Another example could be that a particular M!DGE3/RipEX2 utilizes multiple WAN links and based on the active WAN (link priorities, dynamic routes, …) it can only reach one of more OpenVPN servers.
In such clients, we can configure multiple OpenVPN servers with different IPs and, if required, other parameters (Enhanced TLS protection, UDP/TCP protocol, port number, …). Priorities of the servers can be set. In normal operation and built-in OpenVPN “failover” option, once it connects to the lower priority server, it stays connected to it until there is some issue with this connectivity. In M!DGE3/RipEX2, we can define a fixed time after the currently active connection is closed and the higher priority servers can be used again.
If not already done, set up two M!DGE3 units by following the Chapter 1.1. The server can have RipEX2_Client02 configured as well, but we won’t focus on this client at all, only the MIDGE3_Client01 client.
Configure a new Network Interface within SETTINGS > Interfaces > Ethernet menu called “wan”, using ETH4 port. Set its IP address to 192.168.132.200/24.
Go to the SETTINGS > Routing > Static menu. Based on your APN settings, this may differ a lot, but we set a static route to cellular APN subnet 10.203.0.0/17 via WWAN (MAIN) persistently. We do not need to set any routes via the WAN for this scenario.
Note: More complex solutions can require multiple static routes, and/or Link management and dynamic routing.
Commit the changes.
Configure a new Network Interface within SETTINGS > Interfaces > Ethernet menu called “wan”, using ETH4 port. Set its IP address to 192.168.132.201/24.
Go to the SETTINGS > Routing > Static menu. Based on your APN settings, this may differ a lot, but we set a static route to cellular APN subnet 10.203.0.0/17 via WWAN (MAIN) persistently. We do not need to set any routes via the WAN for this scenario.
Go to the SETTINGS > VPN > OpenVPN menu and click on the “Edit servers” button. Add one new server with server address 192.168.132.200. Set the TLS Protection shared key ID the same way as for the 10.203.0.28 server (TLS-Auth, direction ‘1’).
Switch the priorities so the 192.168.132.200 server is on the 1st line and 10.203.0.28 is on the 2nd line.
Commit the changes.
Connect M!DGE3_Server and M!DGE3_Client01 via the Ethernet cable using the ETH4 ports!
Currently, the OpenVPN tunnel should be established via the primary option. Go to the client’s OpenVPN settings and check the Status.
Focus on “Server address” – it should be 192.168.132.200. If not, you can reboot the unit and wait until the tunnel gets connected again.
Go to the DIAGNOSTICS > Tools > ICMP ping and try to ping 192.168.1.1 from the client. It should work with a very low RTT – it’s approximately 1.5 ms in our example – because it’s just via the Ethernet cable.
Disconnect the ETH cable between the units. The ping should start failing until the OpenVPN mechanism reconnects via the cellular network. The RTTs should be much higher compared to ETH speed.
The switchover time can differ based on Keepalives set in the OpenVPN settings.
You should also check the OpenVPN status – there should be 10.203.0.28 the Server address.
Connect the Ethernet cable again.
The OpenVPN connection does not get re-established via the primary link now, because it only goes to the primary server if the current failover/backup fails. You can either disconnect the cellular antenna, or reboot the client. Wait until it gets connected via the primary ETH link again.
If you need to check the primary (higher priorities) link, set the “Limit session length” parameter in the client’s tunnel configuration. Set the “Maximal session length” to suit your requirements. The minimum time is 5 minutes and the maximum time is 1 day.
We will set it for 5 minutes only due to testing purposes.
Commit changes.
You can do the test with the Ethernet cable again. Once the OpenVPN gets connected via the cellular network, attach the cable again. Within 5 minutes’ time, you should be re-connected via the primary Ethernet link again.
Keep in mind such settings reconnect the tunnel no matter which server is being used – so in our example, while operating via the primary Ethernet link – the VPN tunnel is still re-established every 5 minutes.
You may check the DIAGNOSTICS > Events menu.
The OpenVPN implementation uses generally know protocol and thus, it is compatible with any 3rd party device, including Linux and Windows servers/clients. So e.g., you can successfully connect from your laptop to the M!DGE3/RipEX2 via OpenVPN and get a secure connection to the complete network.
Within the 2.1.1.0 firmware, there is no option to export the .conf, .ovpn, .p12 and similar OpenVPN configuration files with or without the certificates. The same is valid for importing such configuration files. All must be done manually.
If you configure the Windows/Linux client, just configure the tunnel parameters to match the server settings (cipher, HMAC authentication, protocol, …) and upload valid credentials which can be downloaded from M!DGE3/RipEX2 Credentials menu.