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

[praful]

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

[praful]

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

[bonnietwin (Adolf Belka)]

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.

[praful]

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.

[bonnietwin (Adolf Belka)]

@praful

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?

[praful]

@bonnietwin

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?

[bonnietwin (Adolf Belka)]

@praful

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.

[praful]

@bonnietwin

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 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.

[mumpitz]

You have to decide whether you want to connect to red from the internet and open the tunnel or whether you want to connect from within blue and open the tunnel. Neither will be possible for a server due to the key exchange between server and client that you create when setting up the Roadworrier configuration.
This only works either with FQDN or internal IP.
The only option is to start a second OpenVPN server on tun1 and one server listens on blue and the other on red. But this cannot be done via the web GUI. I cannot say whether this is recommended or not.

[dr_techno (Dave Mikeska)]

@praful

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.

It had a place to turn around the traffic, but using a vpn this way is not the way its designed.

Your phone or tablet or whatever you have on blue that needs to talk to green and ipfire, all you have to do is add it to fix leases and assign it a new ip address outside the pool. Then add that ip to allow on green in the firewall rules.

But as far as your ISP is concerned. You have now a standard connection instead of the bottleneck setup you had. Plus, if you want any additional outside public ip addresses, its now very easy to implement.

[praful]

Thanks @mumpitz

@mumpitz

This only works either with FQDN or internal IP.

Originally, when I had the ISP’s modem/router between IPFire and the internet, all was fine. I always used the FQDN whether I was on the blue WiFi network or on a public network somewhere… Is there something about the new setup that creates this problem?

As a reminder, the new setup has IPFire red interface connecting to the ISP’s ONT and therefore the red interface is the public internet IP address.

[praful]

Thanks @dr_techno for replying.

@dr_techno

It had a place to turn around the traffic, but using a vpn this way is not the way its designed.

Your phone or tablet or whatever you have on blue that needs to talk to green and ipfire, all you have to do is add it to fix leases and assign it a new ip address outside the pool. Then add that ip to allow on green in the firewall rules.

I currently issue fixed leases on blue via DHCP, which are based on MAC addresses (I believe). So I could allow the relevant IP addresses to access green from blue. However, I was under the impression that this is not a secure way of limiting access because MAC addresses can be spoofed. Is that not correct? Just being paranoid!

@dr_techno

Plus, if you want any additional outside public ip addresses, its now very easy to implement.

I don’t understand this. Although I don’t need to do it now, please could you say a bit more about how to do this.

[dr_techno (Dave Mikeska)]

@praful

I currently issue fixed leases on blue via DHCP, which are based on MAC addresses (I believe). So I could allow the relevant IP addresses to access green from blue. However, I was under the impression that this is not a secure way of limiting access because MAC addresses can be spoofed. Is that not correct? Just being paranoid!

The flaw in WIFI only really applies to using mac address authentication instead of wap/wep methods with a password, because MAC address authentication does not encrypt the mac address when the client transmits it to make a connection. So I would suggest using access points or wifi routers set to AP mode and the blue interface be a Ethernet connection instead of a wifi card and use the access point as the login entry point.

[dr_techno (Dave Mikeska)]

@praful

I don’t understand this. Although I don’t need to do it now, please could you say a bit more about how to do this.

When you are connected as the outside ip address, your broadband connection is connecting to what I called the local ISP network back pane. This usually have a bunch of different DNS and commercial web servers connected together along with the serving and physical network nodes for the system. There are at least two dns servers (one for dhcp and another for static ip addresses) for private and commercial connections. A static and a dynamic. Usually customers not using a static ip will be using DHCP on their connection to the isp to get their outside address while static ip customers would manually entered the DNS and the ip address.

When the demands for a commercial customer goes beyond one ip address needed (like for operations such as fire/burglar alarm monitoring) services that would need 2 or more ip address to be connected to other servers while servicing the office on a different ip. The customer leases ip addresses the ISP have long term leased from the system. Usually you can get 1 but some isp only will lease to their customers in groups of 2 or 4. To make these extra connections, you add an unmanaged switch right after the ONT, then add a router for each ip address to this switch, then of course program each router with its ip address you want it to be assigned as well as the static DNS server that is used to provision these connections.

[praful]

@dr_techno

When the demands for a commercial customer goes beyond one ip address needed (like for operations such as fire/burglar alarm monitoring) …

Thank you for explanation. I understand now!

[praful]

@dr_techno

So I would suggest using access points or wifi routers set to AP mode and the blue interface be a Ethernet connection instead of a wifi card and use the access point as the login entry point.

Thanks. This is what I have: two APs and one WiFi router set to bridge mode, which all connect (via ethernet) to a switch, which connects via ethernet to the blue interface. This sounds like what you described?

By default, clients to the APs get their IP addresses via DHCP server on IPFire. Could clients hard-code an IP address that’s allowed access to green? Or does the fact that these are static DHCP leases tell IPFire not to give access to a client, eg because the IP address does not map to the MAC address in the static list?

[mumpitz]

@praful

Originally, when I had the ISP’s modem/router between IPFire and the internet, all was fine. I always used the FQDN whether I was on the blue WiFi network or on a public network somewhere… Is there something about the new setup that creates this problem?

As a reminder, the new setup has IPFire red interface connecting to the ISP’s ONT and therefore the red interface is the public internet IP address.

If a hybrid was previously running between the ISP and Ipfire, red probably had an internal IP from the hybrid (router/modem) device assigned to it. When the certificate was created, the OpenVPN server linked the FQDN, which must be linked to the ISP’s public IP on the hybrid (e.g. DDNS), simultaneously with the internal IP of red in the ipfire routing. How is the client from the internet supposed to know where to go when the OpenVPN server is listening at the internal IP of the hybrid after the hybrid at the ISP IP?
If a connection is made out of the blue, IPFire would already know where the client wants to go, as the FQDN and the internal IP are known to IPFire at red.
Currently with the ONT, the IP at red is the public IP of the ISP, which is linked to the FQDN (e.g. DDNS) and thus no longer has an internal IP at red, but this is still included in the routing in the old configuration, including the certificates. For this reason, the old one no longer works.
Connections from blue out are then sent to the FQDN back to itself, there is no direct route to green, not even if you set rules.

But I had understood the request as wanting to prescribe a requirement for using a device on blue via VPN? That would then be possible with the appropriate firewall rules and a second OpenVPN server that only listens on the internal blue IP. As I can see, another instance is now possible via the webGUI after all, which I had done before . At the time, I created two different config files for two network devices tun0/tun1.

[praful]

@mumpitz

Connections from blue out are then sent to the FQDN back to itself, there is no direct route to green, not even if you set rules.

Thanks for the explanation about how green is inaccessible in the new setup.

@mumpitz

But I had understood the request as wanting to prescribe a requirement for using a device on blue via VPN? That would then be possible with the appropriate firewall rules and a second OpenVPN server that only listens on the internal blue IP. As I can see, another instance is now possible via the webGUI after all, which I had done before . At the time, I created two different config files for two network devices tun0/tun1.

Yes, I want to use a device on blue via VPN. I had already (for my original setup) ticked both boxes in the VPN setup (OpenVPN on RED and OpenVPN on BLUE), which I assume is what you did manually not via the webGUI. However, previously I used one client config, which worked for the reason you said. Instead of creating two client VPN profiles on IPFire, I’ve cloned the IPFire-generated .ovpn file so that one files uses the FQDN (“remote” profile) and the other uses blue’s IP address (“local” profile) on each VPN client. This works.

Thanks again for explaining how the routing works.

[mumpitz]

@praful

Thanks again for explaining how the routing works.

I have no idea how routing works, I’m just reporting the problems I faced and how i solved them.

[dr_techno (Dave Mikeska)]

@praful

Could clients hard-code an IP address that’s allowed access to green? Or does the fact that these are static DHCP leases tell IPFire not to give access to a client, eg because the IP address does not map to the MAC address in the static list?

you grant the machine access by reserving an ip address for it and then allow that ip to green. Yes, it uses the MAC address. But you secured the access point with a password handled by itself (by access point, or router in access point mode)

btw, a Openvpn is more easy to hack because the security is all in one and just relies on self signed encryption that is easily to man in the middle. And much easier to do it with wifi+VPN than wired + VPN.