Trying to setup OpenVPNs to Orange device

Hi
My use case is that a remote road warrior client needs to access my Orange local host network. For that they need my current exposed internet ip. They can get that from a DDNS service, I can tell them what it is currently is, or I could have a fixed ip address.

Is the Local VPN Hostname/IP for the use case where I need to initiate a VPN as a client, to connect to a remote host? If that is the case, then entering the DDNS named address in the Local VPN Hostname/IP box makes sense. If that is the case, then it is not clear to me from reading the guide. Maybe a diagram would make it easier to understand.

Yes, the info in that box is put into the .ovpn config file to be provided to your client.
The config ends up with a line:-
remote "Local VPN Hostname/IP" "Destination port"
so that the client knows where to connect to for the OpenVPN connection.

You can use multiple .ovpn configuration files.
Below is a simple example of the possibilities.

Add dyndns hosts.

Add OpenVPN connection and click Download Client Package(zip)

Save as
obraz
and unzip.

Rename the .ovpn file to a name you recognize
obraz

In the downloaded .ovpn file you have dyndns host entered in Local VPN Hostname/IP: box
obraz

Next
click again Download Client Package(zip)
and save it with a different name.

obraz
and unzip.

obraz

Then in the .ovpn file we replace the “default” dyndns host with another
(In this example, “testfordazznoip.myddns[.]me” changed to “testfordazzduckdns.duckdns[.]org”)
obraz

Note: Generally, the above connections use the same Authentication settings.

In the example windows OpenVPN client, we can select the connection we need.
obraz

Below is a working connection to the dyndns host “testfordazzduckdns.duckdns[.]org”

Or
you can create separate connections for each dyndns host and proceed as above


I hope the above example is understandable.

2 Likes

Yes do that.

Would recommend everyone using this VPN
To have separate VPN.

1 Like

Hi
Yes, I already do that. Each person has their own VPN.

Hi
Here is the log from a client attempt to make a VPN connection. He is in the Philippines and I am in New Zealand.

Blockquote
Wed Jun 08 16:48:15 2022 OpenVPN 2.4.8 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Oct 31 2019
Wed Jun 08 16:48:15 2022 Windows version 6.2 (Windows 8 or greater) 64bit
Wed Jun 08 16:48:15 2022 library versions: OpenSSL 1.1.0l 10 Sep 2019, LZO 2.10
Enter Management Password:
Wed Jun 08 16:48:15 2022 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Wed Jun 08 16:48:15 2022 Need hold release from management interface, waiting…
Wed Jun 08 16:48:16 2022 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Wed Jun 08 16:48:16 2022 MANAGEMENT: CMD ‘state on’
Wed Jun 08 16:48:16 2022 MANAGEMENT: CMD ‘log all on’
Wed Jun 08 16:48:16 2022 MANAGEMENT: CMD ‘echo all on’
Wed Jun 08 16:48:16 2022 MANAGEMENT: CMD ‘bytecount 5’
Wed Jun 08 16:48:16 2022 MANAGEMENT: CMD ‘hold off’
Wed Jun 08 16:48:16 2022 MANAGEMENT: CMD ‘hold release’
Wed Jun 08 16:48:16 2022 WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead.
Wed Jun 08 16:48:16 2022 OpenSSL: error:0D0680A8:asn1 encoding routines:asn1_check_tlen:wrong tag
Wed Jun 08 16:48:16 2022 OpenSSL: error:0D07803A:asn1 encoding routines:asn1_item_embed_d2i:nested asn1 error
Wed Jun 08 16:48:16 2022 OpenSSL: error:0D08303A:asn1 encoding routines:asn1_template_noexp_d2i:nested asn1 error
Wed Jun 08 16:48:16 2022 MANAGEMENT: Client disconnected
Wed Jun 08 16:48:16 2022 Error reading PKCS#12 file test20220607.p12
Wed Jun 08 16:48:16 2022 Exiting due to fatal error

To eliminate DDNS issues, he also tried connecting using my current internet IP address. He can ping my ip. He got the same OpenVPN error messages.

I created a test setup with no password because he seems to have hit this bug: Not connecting - Enter Management Password This is an old bug and should be fixed.

Any advice would be much appreciated.

Hi

Downloading and using the zip file, rather than the PKCS12 file resulted in a successful VPN connection.
With ipCop, I only ever used the PKCS12 files so I had no reason to think that they would not work with ipFire.

Here is the log for a successful VPN connection (client side)

Blockquote
Wed Jun 08 18:01:41 2022 OpenVPN 2.4.8 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Oct 31 2019
Wed Jun 08 18:01:41 2022 Windows version 6.2 (Windows 8 or greater) 64bit
Wed Jun 08 18:01:41 2022 library versions: OpenSSL 1.1.0l 10 Sep 2019, LZO 2.10
Enter Management Password:
Wed Jun 08 18:01:41 2022 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Wed Jun 08 18:01:41 2022 Need hold release from management interface, waiting…
Wed Jun 08 18:01:41 2022 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Wed Jun 08 18:01:41 2022 MANAGEMENT: CMD ‘state on’
Wed Jun 08 18:01:41 2022 MANAGEMENT: CMD ‘log all on’
Wed Jun 08 18:01:41 2022 MANAGEMENT: CMD ‘echo all on’
Wed Jun 08 18:01:41 2022 MANAGEMENT: CMD ‘bytecount 5’
Wed Jun 08 18:01:41 2022 MANAGEMENT: CMD ‘hold off’
Wed Jun 08 18:01:41 2022 MANAGEMENT: CMD ‘hold release’
Wed Jun 08 18:01:41 2022 MANAGEMENT: >STATE:1654682501,RESOLVE,
Wed Jun 08 18:01:41 2022 TCP/UDP: Preserving recently used remote address: [AF_INET]xxx.yyy.81.67:1194
Wed Jun 08 18:01:41 2022 Socket Buffers: R=[65536->65536] S=[65536->65536]
Wed Jun 08 18:01:41 2022 UDP link local: (not bound)
Wed Jun 08 18:01:41 2022 UDP link remote: [AF_INET]xxx.yyy.81.67:1194
Wed Jun 08 18:01:41 2022 MANAGEMENT: >STATE:1654682501,WAIT,
Wed Jun 08 18:01:41 2022 MANAGEMENT: >STATE:1654682501,AUTH,
Wed Jun 08 18:01:41 2022 TLS: Initial packet from [AF_INET]xxx.yyy.81.67:1194, sid=58acae9e d6b6d67b
Wed Jun 08 18:01:42 2022 VERIFY OK: depth=1, C=NZ, ST=City, L=, O=test, OU=Director, CN=test CA, emailAddress=sales@test.co.nz
Wed Jun 08 18:01:42 2022 VERIFY KU OK
Wed Jun 08 18:01:42 2022 Validating certificate extended key usage
Wed Jun 08 18:01:42 2022 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Wed Jun 08 18:01:42 2022 VERIFY EKU OK
Wed Jun 08 18:01:42 2022 VERIFY X509NAME OK: C=NZ, ST=Wellington, O=test, OU=Director, CN=xxx-yyy-81-67-adsl.sparkbb.co.nz
Wed Jun 08 18:01:42 2022 VERIFY OK: depth=0, C=NZ, ST=Wellington, O=test, OU=Director, CN=xxx-yyy-81-67-adsl.sparkbb.co.nz
Wed Jun 08 18:01:42 2022 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Wed Jun 08 18:01:42 2022 [222-154-81-67-adsl.sparkbb.co.nz] Peer Connection Initiated with [AF_INET]xxx.yyy.81.67:1194
Wed Jun 08 18:01:43 2022 MANAGEMENT: >STATE:1654682503,GET_CONFIG,
Wed Jun 08 18:01:43 2022 SENT CONTROL [xxx-yyy-81-67-adsl.sparkbb.co.nz]: ‘PUSH_REQUEST’ (status=1)
Wed Jun 08 18:01:43 2022 PUSH: Received control message: ‘PUSH_REPLY,route 10.158.55.1,topology net30,route 172.30.23.0 255.255.255.0,ifconfig 10.158.55.6 10.158.55.5,peer-id 0,cipher AES-256-CBC’
Wed Jun 08 18:01:43 2022 OPTIONS IMPORT: --ifconfig/up options modified
Wed Jun 08 18:01:43 2022 OPTIONS IMPORT: route options modified
Wed Jun 08 18:01:43 2022 OPTIONS IMPORT: peer-id set
Wed Jun 08 18:01:43 2022 OPTIONS IMPORT: adjusting link_mtu to 1524
Wed Jun 08 18:01:43 2022 OPTIONS IMPORT: data channel crypto options modified
Wed Jun 08 18:01:43 2022 Outgoing Data Channel: Cipher ‘AES-256-CBC’ initialized with 256 bit key
Wed Jun 08 18:01:43 2022 Outgoing Data Channel: Using 256 bit message hash ‘SHA256’ for HMAC authentication
Wed Jun 08 18:01:43 2022 Incoming Data Channel: Cipher ‘AES-256-CBC’ initialized with 256 bit key
Wed Jun 08 18:01:43 2022 Incoming Data Channel: Using 256 bit message hash ‘SHA256’ for HMAC authentication
Wed Jun 08 18:01:43 2022 interactive service msg_channel=412
Wed Jun 08 18:01:43 2022 ROUTE_GATEWAY 192.168.1.1/255.255.255.0 I=6 HWADDR=50:3e:aa:96:03:9a
Wed Jun 08 18:01:43 2022 open_tun
Wed Jun 08 18:01:43 2022 TAP-WIN32 device [Local Area Connection] opened: \.\Global{B1AA5CC6-A435-4BCF-A3AC-B2BAB535B8E5}.tap
Wed Jun 08 18:01:43 2022 TAP-Windows Driver Version 9.24
Wed Jun 08 18:01:43 2022 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.158.55.6/255.255.255.252 on interface {B1AA5CC6-A435-4BCF-A3AC-B2BAB535B8E5} [DHCP-serv: 10.158.55.5, lease-time: 31536000]
Wed Jun 08 18:01:43 2022 Successful ARP Flush on interface [70] {B1AA5CC6-A435-4BCF-A3AC-B2BAB535B8E5}
Wed Jun 08 18:01:43 2022 MANAGEMENT: >STATE:1654682503,ASSIGN_IP,10.158.55.6,
Wed Jun 08 18:01:48 2022 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Wed Jun 08 18:01:48 2022 MANAGEMENT: >STATE:1654682508,ADD_ROUTES,
Wed Jun 08 18:01:48 2022 C:\WINDOWS\system32\route.exe ADD 10.158.55.1 MASK 255.255.255.255 10.158.55.5
Wed Jun 08 18:01:48 2022 Route addition via service succeeded
Wed Jun 08 18:01:48 2022 C:\WINDOWS\system32\route.exe ADD 172.30.23.0 MASK 255.255.255.0 10.158.55.5
Wed Jun 08 18:01:48 2022 Route addition via service succeeded
Wed Jun 08 18:01:48 2022 WARNING: this configuration may cache passwords in memory – use the auth-nocache option to prevent this
Wed Jun 08 18:01:48 2022 Initialization Sequence Completed
Wed Jun 08 18:01:48 2022 MANAGEMENT: >STATE:1654682508,CONNECTED,SUCCESS,10.158.55.6,xxx.yyy.81.67,1194,

but it is not that simple because this worked with the Open VPN client version openvpn-install-2.4.8-l602.Win10.exe It did not work with the very latest client version ‘openvpn-connect-3.3.6.2752_signed.msi’ No changes were made on my (server) end.

So it seems likely there is some issue with openVPN.

Not sure if this helps.

In my example above, I used version OpenVPN-2.5.7-I602-amd64.msi
downloaded from the following address

edit:
IPFire version CU167

1 Like

Today I downloaded and installed the openvpn-connect-v3-windows.msi version
from: https://openvpn.net/download-open-vpn/

To run the v3 version, I performed the following steps:

  1. WUI–>OpenVPN → Global Settings
    check the TLS Channel Protection option

  1. Add the RoadWarrior connection

with PKCS12 File Password
obraz

  1. Download Client Package(zip)

and unzip to separate folder
obraz

obraz

  1. Following the below of wiki instructions, copy the downloaded file
    testv3-TO-IPFire.ovpn to IPFire OpenVPN serwer
    then create a unified .ovpn file

obraz

  1. Download the created .ovpn file to the previously created folder

obraz

  1. After run OpenVPN Connect go to Certificates & Tokens

then click ADD CERTIFICATE

enter password

after enter password and cklick on OK

  1. Go back to Import Profile then click FILE → BROWSE

select the created .ovpn file

obraz

Enter password after cklick CONNECT

And it looks like it’s working :blush:

Edit2:
Tested between:
A) server openvpn on IPFire version CU167 - RED public dynamic IP address
B) client on Windows 10 Pro 21H2 + LTE modem

The client was connected using the host address dyndns no-ip.com.

3 Likes

Hi
OK thanks for taking the time and effort to investigate and test this.

It would appear that openVPN may be incompatible with different versions of itself. The other possibility is that ipFire is incorrectly constructing the openVPN profile files. I don’t know if this is a problem that can be fixed in ipFire or openVPN. Either way, I think that ipFire should guide the user toward a default solution that works. If the PKCS12 or unsecure profile files don’t work, then I think they should be fixed or removed from ipFire.

I found the openVPN guide on the Local VPN Hostname/IP This might work well for a client in a fixed location where the specified DDNS service is always available. It doesn’t work for an international traveler moving through countries that may not support the specified DDNS service. This really requires the option of specifying multiple DDNS services, so if one is not available, the next on the list is tried. I understand this is a openVPN issue and not ipFire. The work-around would be to setup a profile for each DDNS service, but that is not elegant or efficient.

It has taken me, and those who have contributed to this thread, far too much time and effort to get to this point. I like ipFire and I hope the developers will review this thread to determine if any improvements can be made to ipFire to help users get VPN setup and running.

It looks like this section has changed a lot over the years. Here is the old:



and here is the new:



and none of the icon hoover is “Windows” specific.

Hi
Based on advice here, it appears that TLS protection should be ticked (on) on by default.

Przeprowadziłem sobie “małe śledztwo” :wink:
The phrase “OpenVPN Community Software Windows Client Download” can be seen on several pages dated October 2010.

Below is a view of the openvpn.net site at the time.

Can you see some correlation with the Wiki page above? :wink:
There is this “Windows icon hover”. :wink: :grinning:

There are two versions of the OpenVPN client.
1-the official OpenVPN Connect client software for Windows workstation platforms developed and maintained by OpenVPN Inc.
2-developed and maintained by the OpenVPN community project team.

The Author of the Wiki entry, recommends using the Community version.

Regards.

1 Like

Hi
Until a couple of days ago, I was unaware that there is a commercial and community version of OpenVPN. I don’t know if this makes any difference to ipFire OpenVPN configuration/compatibility.

I have been using OpenVPN in ipCop for years. It was easy to setup and never caused me problems. My thoughts are that the ipFire WUI should select good settings by default. This might include a link to the OpenVPN webpage with a known-to-work client version. Advanced settings should be hidden in sub-pages. It should be a lot easier to setup than it is.

Found and updated one occurrence on wiki.ipfire.org - Client configuration. Let me know if there are others.

2 Likes

Hi
I don’t think the problem is with the documentation. I think the WUI should be more helpful in providing a working solution with minimal user input.

Implementing a load-balancing/failover configuration

Client

The OpenVPN client configuration can refer to multiple servers for load balancing and failover. For example:

remote server1.mydomain
remote server2.mydomain
remote server3.mydomain

will direct the OpenVPN client to attempt a connection with server1, server2, and server3 in that order. If an existing connection is broken, the OpenVPN client will retry the most recently connected server, and if that fails, will move on to the next server in the list. You can also direct the OpenVPN client to randomize its server list on startup, so that the client load will be probabilistically spread across the server pool.

remote-random

If you would also like DNS resolution failures to cause the OpenVPN client to move to the next server in the list, add the following:

resolv-retry 60

The 60 parameter tells the OpenVPN client to try resolving each remote DNS name for 60 seconds before moving on to the next server in the list.

The server list can also refer to multiple OpenVPN server daemons running on the same machine, each listening for connections on a different port, for example:

remote smp-server1.mydomain 8000
remote smp-server1.mydomain 8001
remote smp-server2.mydomain 8000
remote smp-server2.mydomain 8001

If your servers are multi-processor machines, running multiple OpenVPN daemons on each server can be advantageous from a performance standpoint.

OpenVPN also supports the remote directive referring to a DNS name which has multiple A records in the zone configuration for the domain. In this case, the OpenVPN client will randomly choose one of the A records every time the domain is resolved.

The quote is from:
https://community.openvpn.net/openvpn/wiki/HOWTO#Client

2 Likes

Hi
That is really useful to know. Thanks.