Windows 11 OpenVPN

Networking
23

Hi all,
@suschi can you post the output of
openssl ca -config /usr/share/openvpn/ovpn.cnf -gencrl -out /var/ipfire/ovpn/crls/cacrl.pem

and after that from
openssl crl -in "/var/ipfire/ovpn/crls/cacrl.pem" -text | grep -oP 'Next Update: *\K.*'

?

Best,

Erik

1 Like
24

Thanks for helping

the first command:
Using configuration from /usr/share/openvpn/ovpn.cnf

the second command:
Aug 7 07:54:23 2024 GMT

25

Hi @suschi ,
{i posted the last paragraph in the wrong topic, don´t get confused :wink: have already deleted it}
so your CRL is updated and can be used until Aug 7 , can you try to connect with your VPN client another time and if possible, run a

tail -f /var/log/messages | grep openvpn

before to get a real time log of the connection attempt so you can post the results if it is not working ?

Best,

Erik

26

Hello Erik,
I executed the command in the console and tried to establish a connection with the VPN client (Windows 10) but nothing happened.
Neither the connection works nor does anything happen on the console :frowning:

27

What is in your client log ?

28

OpenVPN 2.5.9 Version,

the Client Log :
2024-07-08 11:10:25 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2024-07-08 11:10:25 TLS Error: TLS handshake failed
2024-07-08 11:10:25 SIGUSR1[soft,tls-error] received, process restarting
2024-07-08 11:10:25 MANAGEMENT: >STATE:1720429825,RECONNECTING,tls-error,
2024-07-08 11:10:25 Restart pause, 160 second(s)
2024-07-08 11:13:05 MANAGEMENT: CMD ‘password […]’
2024-07-08 11:13:05 TCP/UDP: Preserving recently used remote address: [AF_INET]192.168.0.200:1194
2024-07-08 11:13:05 Socket Buffers: R=[65536->65536] S=[65536->65536]
2024-07-08 11:13:05 UDP link local: (not bound)
2024-07-08 11:13:05 UDP link remote: [AF_INET]192.168.0.200:1194
2024-07-08 11:13:05 MANAGEMENT: >STATE:1720429985,WAIT,
2024-07-08 11:14:06 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2024-07-08 11:14:06 TLS Error: TLS handshake failed
2024-07-08 11:14:06 SIGUSR1[soft,tls-error] received, process restarting
2024-07-08 11:14:06 MANAGEMENT: >STATE:1720430046,RECONNECTING,tls-error,
2024-07-08 11:14:06 Restart pause, 300 second(s)
2024-07-08 11:14:09 SIGTERM[hard,init_instance] received, process exiting
2024-07-08 11:14:09 MANAGEMENT: >STATE:1720430049,EXITING,init_instance,

29

You are trying to connect from a local IP 192.168.0.200 which won´t work if you are going from green0 to green0 since IPFire does not operate in bridged mode but in routing mode. If you are trying it from blue0 to green0 this might work, may the FW needs then to be adapted since

2024-07-08 11:13:05 UDP link local: (not bound)
2024-07-08 11:13:05 UDP link remote: [AF_INET]192.168.0.200:1194

is normaly a firewall problem → www.ipfire.org - Troubleshooting OpenVPN .

30

OK,
What I don’t understand is that it used to work (2-3 weeks ago) and now it doesn’t anymore. There are no computers in the green network, all of them are in blue.
I seem to remember that I activated the TLS channel security for this current problem and then nothing worked anymore.
The two Ipfire machines connect at certain times with IPSec and that works well. I can then go from 192.168.2.x to 192.168.3.x without any problems and the server can then make a backup.
In addition, I connected the 192.168.3.x network to 192.168.2.x via the Windows VPN Client (OpenVPN) and that worked great. But not until recently.

Crap

31

If something is wrong with the TLS-Channel security something like
TLS Error: cannot locate HMAC in incoming packet from
will apear. If you do not get any logs from server side from the connection attempt, it looks like

  1. you have the wrong ‘Local VPN Hostname/IP’ or
  2. the firewall blocks the connection attempts.
    If everything is in blue, you will have the same problem if everything is in green. The LAN subnets which you want to reach via OpenVPN needs to be different. Your first questions in this thread does include the same error like the last one
    TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
    so i don´t know where you get the CRL error from but in any case you would need an existing connection attempt to get those kind of errors which is now not the case.
    So it might be an idea if you check the above mentioned points for your infrastructure.

As another idea.

Best,

Erik

32

If nothing happens in the console when tailing the openvpn logs and making a client connection, is the openvpn server actually running?

33

The way I see it, yes

Unbenannt1
Unbenannt1977×543 53.3 KB

If the firewall is blocking the traffic, it may be that I have to create a rule?

Although I haven’t changed anything

Does it make sense to completely reinstall everything related to OpenVPN?

34

No it does not. From where to where you want to communicate ?
If the FW drops the connection attempt you can see it in the FW logs too. But please check the above written and check your subnets. If you have “OpenVPN auf Rot” active and for “Lokaler VPN Hostname/IP” is configured for a LAN IP, no FW rules will manage blue0 ↔ green0 since red0 is not blue0.

35

Well Erik,
then I don’t understand why it worked.

My Config is here (Example1)

A few weeks ago I used a Windows VPN tool (OpenVPN) to access the IpFire machine 192.168.2.1 from my 192.168.3.x without any problems

36

If there are no openvpn logs, then nothing is getting into Red. (assuming it is 192.168.0.200). Have you done something to prevent RFC1918 addressed being accepted by Red? Perhaps a new or updated blocklist?

37

Soon I won’t know anything anymore :slight_smile:
Here are my firewall rules

Unbenannt-2
Unbenannt-2712×341 27.4 KB

Unbenannt-4
Unbenannt-4917×289 22.9 KB

38

So now I always connect the two Ipfire machines manually via the root console using IPSec.
The OpenVPN doesn’t work and I can’t get it to work.
Then I have to do it this way. Thank you for your help anyway