I’m experiencing strange behavior with one of my PCs.
I’m connecting to IPFire 2 via OpenVPN on a PC connected via Wi-Fi. However, another PC connected to the same Fritz!Box Wi-Fi network is connected via LAN. This PC isn’t establishing a connection.
2025-11-30 19:17:21 Note: --cipher is not set. OpenVPN versions before 2.5 defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add ‘–data-ciphers-fallback BF-CBC’ to your configuration and/or add BF-CBC to --data-ciphers.
2025-11-30 19:17:21 OpenVPN 2.6.14 [git:v2.6.14/f588592ee6c6323b] Windows [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] [DCO] built on Apr 2 2025
2025-11-30 19:17:21 Windows version 10.0 (Windows 10 or greater), amd64 executable
2025-11-30 19:17:21 library versions: OpenSSL 3.4.1 11 Feb 2025, LZO 2.10
2025-11-30 19:17:21 DCO version: 1.2.1
2025-11-30 19:17:23 TCP/UDP: Preserving recently used remote address: [AF_INET]192.168.0.200:1194
2025-11-30 19:17:23 UDPv4 link local: (not bound)
2025-11-30 19:17:23 UDPv4 link remote: [AF_INET]192.168.0.200:1194
2025-11-30 19:18:23 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2025-11-30 19:18:23 TLS Error: TLS handshake failed
2025-11-30 19:18:23 SIGUSR1[soft,tls-error] received, process restarting
2025-11-30 19:18:25 TCP/UDP: Preserving recently used remote address: [AF_INET]192.168.0.200:1194
2025-11-30 19:18:25 UDPv4 link local: (not bound)
2025-11-30 19:18:25 UDPv4 link remote: [AF_INET]192.168.0.200:1194
2025-11-30 19:18:43 SIGTERM[hard,] received, process exiting
–
As I said, the OpenVPN configuration is the same on both PCs. The only difference is that one PC is connected via LAN to a Fritz!Box (which doesn’t work), and the other is connected via Wi-Fi, where it works.
This is saying that you have set the IP for the remote machine as 192.168.0.200 but as you are trying to connect to your IPFire2 you need to have it set to 192.168.0.201, which is the IPFire2 red interface ip address.
Check the line in the ovpn file that starts with “remote” and check that it is the same for both machines if you have specified an IP or that the fqdn specified does actually translate to the correct IP.
You can also check the client logs for the machine that is working and see what remote address has been specified there.
Okay, then if the remote IP is correct then these lines
indicate that there is some network connectivity problem between your PC2 and IPFire2.
As the other machine can connect then this means that the connection from IPFire1 to IPFire2 is not a problem so the most likely thing would be some issue within the Fritzbox/WLAN Router for PC2 or spome problem with the definition in IPFire1 for the blue access for that PC2.
Is the blue access set up for no mac filtering or do you specify the mac addresses in the blue access page for what is allowed. Is PC2 getting a correct IP from the IPFire1 blue dhcp.
So check the ARP data at the bottom of the Network (others) WUI page to see if PC2 is successfully connected to IPFire1.
Try pinging the blue interface of IPFire1 from PC2 and pinging the IP of PC2 from your IPFire1 system.
Do the same thing for PC1 to confirm that there is a difference or not.
Try pinging the red interface IP of IPFire2 from PC2.
Can you confirm that none of your systems are using a fqdn but instead all are being referenced by an IP as your diagram suggests, because that then removes any DNS issue of finding out how to access IPFire2 from IPFire1.
The above is the sort of process I would do to find out where the network connectivity problem is occurring.
Thanks for the reply, and sorry I couldn’t respond until today.
So, I’m actually having the problem that PC2 can’t ping IPFFire 2. PC1, however, can. Both PCs are listed as “allowed” on the blue network, and their MAC addresses are correct.
I thought it might be a problem somewhere between the Wi-Fi and LAN interfaces of the Fritz!Box, but today a new issue arose.
I bought an identical iPad. Both iPads are connected via the same Fritz!Box (as shown in the picture). With one of them, I can ping to both red networks (192.168.0.200 and 192.168.0.201), but with the “new” iPad, I can’t ping to 192.168.0.200, and therefore OpenVPN isn’t working here either…
And strangely enough, OpenVPN doesn’t work externally (DynDNS) on the iPad either.
However, WireGuard does work externally on the iPad. With that, I can access the blue network of the IPFire 2.