Can't use VPN when on blue (WiFi) network since switching to OTN

Previously, my IPFire’s RED interface was connected to the provider’s modem/router, which connected to the internet.

My new provider has 1Gbps fibre to the home (Community Fibre). The connection point is an ONT (Optical Network Terminal).

I’ve run an ethernet cable from IPFire RED directly to the ONT box. [I’m using the provider’s router (switched to bridge mode) as the Wi-Fi point on the BLUE network.]

This is all working well.

One issue I’ve discovered is that when I’m on the BLUE Wi-Fi network, VPN clients don’t connect to IPFire. I must get off the BLUE network and use, say, 4G/5G. Then, all is fine.

Previously, the RED IP address was an internal address, and the modem/router had an internal (to RED) and public IP address to the installed provider’s box. Now, the RED interface has the public internet address. Is this confusing things?

chatGPT suggested adding a rule to allow BLUE to permit VPN traffic from BLUE to RED on the OpenVPN port. This didn’t work, assuming I did it correctly.

The VPN log when trying to connect:

20:03:04	openvpnserver[5807]:	192.168.6.96:43773 SIGUSR1[soft,tls-error] received, client-instance restarting
20:03:04	openvpnserver[5807]:	192.168.6.96:43773 TLS Error: TLS handshake failed
20:03:04	openvpnserver[5807]:	192.168.6.96:43773 TLS Error: TLS key negotiation failed to occur within 60 seco nds (check your network connectivity)
20:02:54	openvpnserver[5807]:	192.168.6.96:47670 TLS: Initial packet from [AF_INET]192.168.6.96:47670, sid=410 446be 7f8b8a1f
20:02:54	openvpnserver[5807]:	192.168.6.96:47670 Incoming Control Channel Authentication: Using 512 bit messag e hash 'SHA512' for HMAC authentication
20:02:54	openvpnserver[5807]:	192.168.6.96:47670 Outgoing Control Channel Authentication: Using 512 bit messag e hash 'SHA512' for HMAC authentication
20:02:44	openvpnserver[5807]:	192.168.6.96:38906 TLS: Initial packet from [AF_INET]192.168.6.96:38906, sid=a41 753b6 876c6c16
20:02:44	openvpnserver[5807]:	192.168.6.96:38906 Incoming Control Channel Authentication: Using 512 bit messag e hash 'SHA512' for HMAC authentication
20:02:44	openvpnserver[5807]:	192.168.6.96:38906 Outgoing Control Channel Authentication: Using 512 bit messag e hash 'SHA512' for HMAC authentication
20:02:34	openvpnserver[5807]:	192.168.6.96:45663 TLS: Initial packet from [AF_INET]192.168.6.96:45663, sid=9b0 ee8f3 663c7a1f
20:02:34	openvpnserver[5807]:	192.168.6.96:45663 Incoming Control Channel Authentication: Using 512 bit messag e hash 'SHA512' for HMAC authentication
20:02:34	openvpnserver[5807]:	192.168.6.96:45663 Outgoing Control Channel Authentication: Using 512 bit messag e hash 'SHA512' for HMAC authentication
20:02:24	openvpnserver[5807]:	192.168.6.96:52772 TLS: Initial packet from [AF_INET]192.168.6.96:52772, sid=f95 d3069 a11f9388
20:02:24	openvpnserver[5807]:	192.168.6.96:52772 Incoming Control Channel Authentication: Using 512 bit messag e hash 'SHA512' for HMAC authentication
20:02:24	openvpnserver[5807]:	192.168.6.96:52772 Outgoing Control Channel Authentication: Using 512 bit messag e hash 'SHA512' for HMAC authentication

Any suggestions to get VPN working on BLUE network gratefully received.

Thanks

If you can’t answer the question, perhaps you can suggest how I can diagnose the problem?

If I understand the situation correctly you have now connected IPFire directly to the ONT and have moved the old router to your blue network after putting it in bridged mode to replace whatever you were using on your blue network before.

I would suggest going back to the old system you had on your blue network and confirm that openVPN is still working.

If yes then there is a problem with how you are using the old router as a wifi access point.

If no then something has changed with either the configuration of your OpenVPN server or the clients.

1 Like

Thank you for replying @bonnietwin. Minor correction: I’m using the new ISP’s router (which they provide to connect to the ONT) as the new WiFi router on blue network since ipfire can connect directly to the ONT.

I will fire up the old blue WiFi router to test what you said. This old router didn’t have the option of bridge mode so I disabled features such as DHCP, which were handled by ipfire. Therefore, a second test is to configure the new WiFi router in the same way, ie not in bridge mode and disabling features not required.

In the meantime, I’ve just now added a second OpenVPN entry on my android to use the blue IP address of ipfire (ie, a local address) instead of using the (external) FQDN. This works.

This would suggest to me that the IP address for your FQDN is not getting resolved correctly. Is the IP for that FQDN correctly up to date?

Yes - because if I switch off WiFi and connect via 4/5G, everything works. So I currently have two OpenVPN profiles on my phone, one using the FQDN when I’m away from home and the other when I’m on my home network.

Also, the log in my first message is what ipfire sees when I’m trying to connect locally using the FQDN profile. It fails at the TLS stage?

That will fail if you are connected locally and are using a FQDN which has a public IP.

I have only ever used OpenVPN coming in on the red interface using the public IP as a FQDN.

I believe you are trying to use OpenVPN via the Blue network using the Access Point and therefore you have OpenVPN on Blue set up as well as OpenVPN on green on the WUI page.
I have never tried that so can’t help on that front.

However if it used to work in the past then definitely go back to the old wifi connection system on blue and confirm it is still working. That at least gives you a working point and removes any question mark about the ONT because OpenVPN via the Blue Interface won’t come in via Red anyway.

I reinstated my old blue WiFi router and have the same issue. I should have realised this because I have other access points around the house, which have not changed, and also don’t allow OpenVPN client to work!

You are right that I have OpenVPN on blue and red. I want to access green from blue WiFi network, which is what my laptop/phone/tablet connect to. If I gave blue direct access to green, then guests and other home automation/speakers on the blue network could try to get to green. If one of those devices were hacked or someone got onto the blue WiFi network, they’d have a route to green. For security, I wanted green (and the WUI) accessible only from either the green network (wired) or VPN.

My concern about the new config is that the red interface on ipfire is the public IP address. Previously the public IP address was the ISP’s modem/router, which connected to the red interface via an internal subnet to ipfire’s red interface. My intuition, perhaps incorrect, is that this extra jump meant you were “going out” of ipfire, whereas now I’m not.

That all said, the OpenVPN ipfire log (first post above) shows a successful connection and it is at the TLS handshake stage the failure occurs.