Yes, I have also found that now with searching but then you have to use TCP on the server and the client has to match the server also with TCP.
You can check on your IPFire Server page if UDP or TCP is selected and you should be able to find the same thing on your clients to confirm they are also set to TCP.
Both Open VPNs run via TCP, UDP was just a quick test to see if it works. I still don’t believe there is a configuration problem with OpenVPN, because port 443 is not accessible.
I have just compared the settings in the web proxy of both systems: absolutely identical, apart from the different networks. Both systems also have port 443 under “Permitted TLS ports (one per line):”, but it only works on one system.
Translated with DeepL.com (free version)
Just to confirm, to me I read this as two IPFire systems trying to be accessed with the same client.
Correct me if I am wrong.
Do both IPFire servers have the same Encryption setting and do both systems have the TLS Channel Protection enabled or disabled (but the same).
Yes, that is correct. One client (cell phone) addresses two different networks with one ipfire each. All settings are identical, I have just checked again.
it worked with the other port in the past
Then you will need to look at the logs to see what the difference is now. Something must be stopping it and you should be able to see that in the logs by comparing the two client logs or by comparing your IPFire server logs to see what it is saying about the connection.
Does the second IPFire server even receive any connection attempt by the client.
If not then your only option is the client log for that connection attempt.
What do you think about the port not being recognized as open? Is this not the reason? How is OpenVPN supposed to establish the connection if it cannot establish the connection via the port? Then the problem would not be found in the OpenVPN log either.
Yes, but why won’t it open. Do you have an ISP supporting that IPFire that blocks all https traffic compared to the other IPFire.
There must be some difference between the two IPFires or between the two ISPs and one way to identify that is from the logs. They will show the steps that work and will then flag up when something fails and will tell you a message about what failed.
Then you can try and figure out what could cause that error message to be created, ie where in the traffic flow did the tcp 443 port not get opened.
If port 443 outgoing on that IPFire is blocked then you would also not be able to do any https browsing from that IPFire green network.
You have to decide if this is far enough for you to investigate and you are happy to stop at this point. That is not for us to decide.
I am very grateful for the support, but I like to understand what I am doing and avoid looking in places where the solution is probably not there. “Why should I bother with the room lock if the front door won’t open?” Hence my question about the port.
I am with the same ISP with both ipfires. So that can’t be the reason either.
I’ll have a look at the logs in my next free time, as this seems to be something more lengthy.
Thank you very much!
When I configured openvpn, I had to enable the port on my ISP modem/router (to allow incoming traffic on the port to my ipfire server) as well as the ipfire config stuff. Do you need to do that for the second ipfire server?
Looking at the logs is not as lengthy as you might think and will quickly give you info, and possibly confirm your observation about the port (or not).
If you have a modem/router, check the logs to see if the traffic is getting past it or being blocked.
On Android, tap the top right icon to see the logs
On ipfire, you can do it via the command line or in the web gui, goto to system logs and filter on Openvpn. I have found them useful first steps.
[I can’t check this because I’m in a frustrating position myself: openvpn on ipfire has frozen on me and I’m away! I have monit running to restart stopped processes so the process must be still running and something within or outside the openvpn process is not working. I was trying to set up a second phone for VPN and repeated failures ended up with neither my first phone nor laptop being able to connect any more! It’s rare for this to happen (three times in about 10 years) but I think I’ll setup a job to restart VPN everyday.]
Thank you very much! I’m sorry you’re having problems too, I’m afraid I don’t have a solution for you.
In ipfire, the log file under Openvpn is empty. This fits with my assumption that port 443 is not open and therefore no communication is taking place on an open-vpn basis.
On Android I get:
2024-06-07 12:29:24 VpnClientPro-google-api27-release-1.01.79 (30010179)
2024-06-07 12:29:24 Connecting request by user
2024-06-07 12:29:24 OpenVPN 2.5.8 android-arm64-v8a [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on May 20 2024
2024-06-07 12:29:24 library versions: OpenSSL 3.0.13 30 Jan 2024, LZO 2.10
2024-06-07 12:29:36 TCP/UDP: Preserving recently used remote address: [AF_INET]80.133.22.12:443
2024-06-07 12:29:36 Socket Buffers: R=[1048576->1048576] S=[1048576->1048576]
2024-06-07 12:29:36 Attempting to establish TCP connection with [AF_INET]80.133.22.12:443 [nonblock]
2024-06-07 12:29:36 TCP: connect to [AF_INET]80.134.20.13:443 failed: No route to host
2024-06-07 12:29:36 SIGUSR1[connection failed(soft),init_instance] received, process restarting
2024-06-07 12:29:36 Restart pause, 5 second(s)
Have you tried disabling the ip block list and drop hostile networks?
You never know how you may end up being blocked by this sort of thing.
These lines seem key:
2024-06-07 12:29:36 Attempting to establish TCP connection with [AF_INET]80.133.22.12:443 [nonblock]
2024-06-07 12:29:36 TCP: connect to [AF_INET]80.134.20.13:443 failed: No route to host
When I run the following command for my public IP address:
sudo nmap -Pn -sU -p <port> <ip>
I get
PORT STATE SERVICE
<port>/udp open|filtered openvpn
If I run this on yours:
sudo nmap -Pn -sT -p 443 80.133.22.12
I get
PORT STATE SERVICE
443/tcp filtered https
For UDP:
❯ sudo nmap -Pn -sU -p 443 80.133.22.12
Starting Nmap 7.80 ( https://nmap.org ) at 2024-06-07 13:47 BST
Nmap scan report for p5085160c.dip0.t-ipconnect.de (80.133.22.12)
Host is up.
PORT STATE SERVICE
443/udp open|filtered https
I don’t know if the service were running both openvpn and https whether nmap would show both. However, port 443 is open for UDP.
Is your ipfire server connected directly to the internet or is it first connected to the ISP modem/router? If so:
Thanks for the effort, I’m afraid I misled you because I changed the IP address. It’s not mine, sorry. Mine is 80.134.20.13
np - both seem closed 
Did you see the bit about modem/router?
❯ sudo nmap -Pn -sU -p 443 80.134.20.13
Starting Nmap 7.80 ( https://nmap.org ) at 2024-06-07 14:11 BST
Nmap scan report for p5086140d.dip0.t-ipconnect.de (80.134.20.13)
Host is up (0.16s latency).
PORT STATE SERVICE
443/udp filtered https
Nmap done: 1 IP address (1 host up) scanned in 0.46 seconds
❯ sudo nmap -Pn -sT -p 443 80.134.20.13
Starting Nmap 7.80 ( https://nmap.org ) at 2024-06-07 14:11 BST
Nmap scan report for p5086140d.dip0.t-ipconnect.de (80.134.20.13)
Host is up (0.037s latency).
PORT STATE SERVICE
443/tcp filtered https
Nmap done: 1 IP address (1 host up) scanned in 0.11 seconds
Do you have any idea why and how https is filtered?
Why not check with tcpdump running on Red to see if packets are arriving when you connect from your Android? tcpdump -nni red0 dst port 443 and dst 80.134.20.13. It should pick up both UDP and TCP.
Tcpdump sits outside the firewall. If it sees nothing then the packets aren’t reaching IPFire.
0 packets captured
0 packets received by filter
0 packets dropped by kernel
So, as your Android logs say, unable to connect to your target, so something between your Android device and your server is dropping packets. If IPF is directly connected to your public IP, this suggest your server ISP or your Android telco, or a misconfiguration of the Android device.
As you have two IPFire OpenVPN servers then you need to make sure that you are using the correct IP address for each client profile on your Android device.
In your Android Log you have the following.
I have highlighted in bold the server IP address references.
The first ref is to the IP that was recently already tried.
It then attempts to make the OpenVPN TCP connection to that IP which is the second ref.
The third ref is when it reports a failure to connect but the specified IP is a different IP now. Make sure the Android App for the connection profile to the second IPFire server has the correct Server IP address.