https://community.ipfire.org/t/testing-ipfire-2-29-core-update-197/14510/25?u=tphz If the RoadWarrior OpenVPN client has “Static IP address pool” set, it receives the following message after connecting: Warning: route gateway is not reachable on any active network adapters The connection is established (Status CONNECTED), but there is no access to resources on the internal network (e.g., Green). If “Dynamic Client Subnet” is selected, the connection is established and you can access the resources of the internal network.
(In reply to iptom from comment #0) > > If the RoadWarrior OpenVPN client has “Static IP address pool” set, it > receives the following message after connecting: > > Warning: route gateway is not reachable on any active network adapters > > The connection is established (Status CONNECTED), but there is no access to > resources on the internal network (e.g., Green). I think you need to provide more details on your server and client settings. All my testing with static IP address pool just worked. I did a couple of tests with dynamic IP address pool and that also just worked. I have checked through the logs for my testing system and the message you have received is not to be found. If you can provide the client .ovpn file and the server.conf file contents from CU196 and after they have been updated in CU197 Testing with any public IP's or FQDN's suitably sanitised then I can compare that with my setup and try and see if I can replicate what you are experiencing. Can you also indicate what build version you are experiencing this on as there have been ongoing updates to the CU197 status. I am currently on master/c293ac4b although there are two further updates since that one with the current version being master/19802511
I just updated my system to master/19802511 and tested out my connections with Fixed IP address pool. Connection worked fine. I could ping a system on the green lan via my openvpn tunnel and also ssh into the server on that green system and then edit files on it. I will create a new CU196 clone and do the update to the latest version with that combination and confirm that it all works for me. If you can confirm that you are experiencing the problem with a CU196 system updated to CU197 master/19802511 then if you can provide the server.conf and client.ovpn file contents suitably sanitised then I will be able to do an apples for apples comparison. I can then duplicate your settings, in case you have some differences with setting of gateways or routes pushed etc. In my case all of those settings are at the default values.
I created a new CU196 clone. Tested the openvpn rw connection out. ping to a green machine worked. Running an ssh client to the ssh server on the green machine worked. Running the IPFIre WUI via the openvpn tunnel worked. I then updated to CU197 Testing. Ran the above three tests again and all three worked the same as with CU196.
I have seen three differences in the setup which might make some difference and one that I would have expected to mean that your CU196 connection would not work. In your server.conf you have proto udp but in your client .ovpn file you have proto tcp You must have edited that yourself as the CU196 code would always copy the proto in the server to the client. In your server.conf you have defined 4 routes to be pushed while I have only got one defined. In my server.conf I am pushing the dhcp-options of Domain and DNS while your server.conf has neither defined. I don't know how easy it will be for me to specify 3 extra subnets to route defined. I will have to have a think about it. My first step will be to define what differences I see between the CU196 and CU197 Testing versions of the three files and you can then see if you ahve the same differences or additional/different ones.
If you just did the update to CU197 Testing then the client config file changes won't make any difference as what will count is what you have installed on your client which will stay as the old version and will work the same as the new version. So the only impact files should bhe the server.conf and/or the ccd file.
Created attachment 1644 [details] 196 ccd file This is my CU196 ccd file for the client I worked with.
Created attachment 1645 [details] CU197 ccd file This is the CCD file after updating to CU197. Note the change to the if-config push line where it has gone from 2 IP's defined to a single IP with a subnet mask. Please confirm that your ccd file after the CU197 update shows a similar thing for your setup. If you still have two IP's specified then this was a bug found in the earlier CU197 versions but has already been fixed in the last 3 or 4 update versions. The conversion to the single IP with a subnet mask definitely works in build master/19802511
server.conf differences between CU196 and 197 In CU197 there will be the lines # Topology topology subnet I only have the single route in my server.conf but it is the same in the CU196 and CU197 versions. Is there a difference in the CU197 compared to CU196 for your system. ncp-disable and cipher should be replaced by data-ciphers and data-ciphers-fallback. There will be a line compress migrate added to the CU197 version. My push dhcp-option lines are both the same for CU196 and CU197 but you did not have these in your server.conf file from CU196 A new line added at the end explicit-exit-notify All other lines for my CU197 are the same as for CU196.
> If you can confirm that you are experiencing the problem with a CU196 system > updated to CU197 master/19802511 then if you can provide the server.conf and > client.ovpn file contents suitably sanitised then I will be able to do an > apples for apples comparison. Yes, I can confirm that the problem occurs on several devices updated to "Core-Update 197 Development Build: master/19802511".
Okay, then the problem was not the bug with the ccd files which has been fixed. I am looking at setting up a new clone where I will create three additional routes to be pushed beside the default green one and then create a new client connection and get that running in CU196 and then do the update to CU197 Testing and see what I find.
I just tried to define the extra routes that you have in your server.conf file from CU196 and I have been unable to replicate the entries. I end up with the following lines push "route 10.32.102.0 255.255.255.0" push "route 10.32.101.0 255.255.255.0" push "route 10.0.100.0 255.255.255.0" route 10.110.30.0 255.255.255.0 but the same entries in your server.conf would show as all being route only without the push option. route 10.32.102.0 255.255.255.0 route 10.32.101.0 255.255.255.0 route 10.0.100.0 255.255.255.0 route 10.110.30.0 255.255.255.0 I placed my entries in the Advanced Server options WUI page in the section labelled Route push options. Where did you specify them on your CU196 WUI page?
I didn't read the warning message closely enough. It is related to the gateway not being reachable. Doing a google search on that warning I have found a lot of results related to issues with Windows, especially 8, 10 & 11. The comments seem to have been related to tap-win32 not being available when openvpn is trying to set properties on it. However not 100% sure as OpenVPN, certainly on IPFire is using tun and not tap. Maybe OpenVPN-6.x is faster at doing some stuff before the windows system is ready. The fix that has been mentioned is adding additional lines at the end of the windows client profile tap-sleep 3 route-delay 1 3 Whether this would actually help, I have no idea as I don't have any windows systems to test with. Can you confirm if the systems having a problem are windows systems or whether they are Linux or Mac systems? What happens if you create a new client connection under CU197 Testing. Does that work without the warning message?
> Doing a google search on that warning I have found a lot of results related > to issues with Windows, especially 8, 10 & 11. In my case, this applies to Windows 10 and 11. Tomorrow or the day after tomorrow, I'll try it on virtual Linux. > The comments seem to have been related to tap-win32 not being available when > openvpn is trying to set properties on it. However not 100% sure as OpenVPN, > certainly on IPFire is using tun and not tap. > > Maybe OpenVPN-6.x is faster at doing some stuff before the windows system is > ready. As a reminder: Dynamic pool – connection works Static pool – connection does not work > What happens if you create a new client connection under CU197 Testing. Does > that work without the warning message? The problem also occurs after adding a new connection.
@iptom: Please provide the full logs from the OpenVPN client and server.
Fix is available here: > https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=d4eb2e77a9647c6b85a73f3d5695d72c1665f03a
Created attachment 1646 [details] clientlog-dynamicpool-verb4
Created attachment 1647 [details] clientlog-dynamicpool-verb6
Created attachment 1648 [details] clientlog-staticpool-verb4
Created attachment 1649 [details] clientlog-staticpool-verb6
Created attachment 1650 [details] serverlog-dynamicpool-verb4
Created attachment 1651 [details] serverlog-dynamicpool-verb6
Created attachment 1652 [details] serverlog-staticpool-verb4
Created attachment 1653 [details] serverlog-staticpool-verb6
> Can you confirm if the systems having a problem are windows systems or > whether they are Linux or Mac systems? However, no problems occurred during testing on Linux Mint.
(In reply to Michael Tremer from comment #14) > @iptom: Please provide the full logs from the OpenVPN client and server. Sorry, I was only able to attach the necessary logs today. Best Regards
I suppose this is not tested with the proposed fix that I posted yesterday?
(In reply to Michael Tremer from comment #26) > I suppose this is not tested with the proposed fix that I posted yesterday? Yes, these are logs without a fix.
Would you please install the fix then, hit the Save button on the connection and test again?
Created attachment 1654 [details] clientlog-dynamicpool-verb4-ver_d4eb2e77
Created attachment 1655 [details] clientlog-staticpool-verb4-ver_d4eb2e77
Created attachment 1656 [details] serverlog-dynamicpool-verb4-ver_d4eb2e77
Created attachment 1657 [details] serverlog-staticpool-verb4-ver_d4eb2e77
(In reply to Michael Tremer from comment #28) > Would you please install the fix then, hit the Save button on the connection > and test again? Preliminary tests show that the problems for Windows have been fixed. I am attaching the logs. Tests on other platforms, such as Linux and Android, will also be required. Regards
Tested out with Network Manager on Arch Linux and on an Android phone with the OpenVPN for Android app. Connections working without any issues. Also the ping on my Android phone now works. Previously the ping didn't work although the connection was successfully made and I could use ssh to access a server on the green system being connected to and also run the IPFire WUI at the server end of the tunnel.
(In reply to Adolf Belka from comment #34) > Tested out with Network Manager on Arch Linux and on an Android phone with > the OpenVPN for Android app. > > Connections working without any issues. > > Also the ping on my Android phone now works. Previously the ping didn't work > although the connection was successfully made and I could use ssh to access > a server on the green system being connected to and also run the IPFire WUI > at the server end of the tunnel. Did you also perform tests on Android using a static address pool?
(In reply to iptom from comment #35) > Did you also perform tests on Android using a static address pool? Yes. I have been using the static address pool IP's for the last 5 or 6 years with all my OpenVPN clients.
> Yes. I have been using the static address pool IP's for the last 5 or 6 > years with all my OpenVPN clients. Which version of Android did you test it on?
I'm afraid that in my case, the connection from Android 15 does not work with a static address pool. exception parsing IPv4 route: [route] [192.168.233.0] [255.255.255.0] [10.200.211.1] : tun_prop_route_error: route destinations other than vpn_gateway or net_gateway are not supported exception parsing IPv4 route: [route] [192.168.232.0] [255.255.255.0] [10.200.211.1] : tun_prop_route_error: route destinations other than vpn_gateway or net_gateway are not supported Client OpenVPN Connect Current Version: 3.7.1 (10568) IPFire 2.29 (x86_64) - Core-Update 197 Development Build: master/d4eb2e77
Created attachment 1658 [details] staticpool-log-androidclient
Created attachment 1659 [details] dynamicpool-log_androidclient
(In reply to iptom from comment #38) > I'm afraid that in my case, the connection from Android 15 does not work > with a static address pool. > > exception parsing IPv4 route: [route] [192.168.233.0] [255.255.255.0] > [10.200.211.1] : tun_prop_route_error: route destinations other than > vpn_gateway or net_gateway are not supported > > exception parsing IPv4 route: [route] [192.168.232.0] [255.255.255.0] > [10.200.211.1] : tun_prop_route_error: route destinations other than > vpn_gateway or net_gateway are not supported > > Client OpenVPN Connect Current Version: 3.7.1 (10568) > IPFire 2.29 (x86_64) - Core-Update 197 Development Build: master/d4eb2e77 Did you edit and save this connection as well? I looks like the CCD file has not been updated.
(In reply to Michael Tremer from comment #41) > Did you edit and save this connection as well? I looks like the CCD file has > not been updated. The connection has been added in the new version of IPFire—after applying the fix.
Could you post the content of the CCD file then, please? It should be in /var/ipfire/ovpn/ccds.
(In reply to Michael Tremer from comment #43) > Could you post the content of the CCD file then, please? > > It should be in /var/ipfire/ovpn/ccds. # OpenVPN Client Configuration File # Allocated IP address from ovpnstaticpool ifconfig-push 10.200.211.2 255.255.255.0 # DHCP Options # Networks routed to the server push "route 192.168.233.0 255.255.255.0 10.200.211.1" push "route 192.168.232.0 255.255.255.0 10.200.211.1"
(In reply to iptom from comment #37) > > Yes. I have been using the static address pool IP's for the last 5 or 6 > > years with all my OpenVPN clients. > > Which version of Android did you test it on? I tested it out on Android 11. My phone manufacturer has stopped doing any Android updates after 11 for my phone model but as it still functions well I don't have any intent tp spend more money on an new phone. However maybe more important I am using the "OpenVPN for Android" app for my client whereas I suspect, based on your logs you are using the "OpenVPN Connect" app. Can you confirm if that is the case? The "OPenVPN for Android" app is designed to work with the OpenVPN Community server while the "OpenVPN Connect" app is designed to work with the OpenVPN Connect server (Paid server option). OpenVPN do say that their OpenVPN Connect client can in many cases also work with the Community Server as long as the Community Server does not use the functions that OpenVPN Connect does not support. I always had problems using the OpenVPN Connect app so I stopped trying to use it and used the OpenVPN for Android app and that has always connected to the IPFire OpenVPN Community server. It might be worth trying out the OpenVPN for Android app on your Android phone to see if you still have the same problem.
(In reply to Adolf Belka from comment #45) > (In reply to iptom from comment #37) > However maybe more important I am using the "OpenVPN for Android" app for my > client whereas I suspect, based on your logs you are using the "OpenVPN > Connect" app. Can you confirm if that is the case? > I have been using “OpenVPN Connect” for many years. After updating to 197, it works fine on dynamic pool.
To make things more interesting, in the “Core-Update 197 Development Build: master/97469fbd” version, the “OpenVPN Connect” client works correctly with static and dynamic address pools. ;)
Created attachment 1660 [details] android-Staticpool-on-ver-97469fbd-log_
Comment on attachment 1660 [details] android-Staticpool-on-ver-97469fbd-log_ To make things more interesting, in the “Core-Update 197 Development Build: master/97469fbd” version, the “OpenVPN Connect” client works correctly with static and dynamic address pools. ;)
The latest changes have been merged and built. These are expected to resolve the routing problems that this bug is related to. It would be good if @iptom can test those out. The build version is Core-Update 197 Development Build: master/0088442c
(In reply to Adolf Belka from comment #50) > The latest changes have been merged and built. These are expected to resolve > the routing problems that this bug is related to. > > It would be good if @iptom can test those out. > > The build version is > > Core-Update 197 Development Build: master/0088442c At the moment, I do not have access to the test environment that was created. However, I have updated another IPFire to Core Update 197 Development Build: master/d6ec7e0b. It seems that after the update, you can connect to internal resources from Android 15 using the OpenVPN Connect Current Version 3.71 (10568) client (static pool and dynamic pool) Also from Windows 10 + OpenVPN v2.6.14 community edition client.
(In reply to iptom from comment #51) > (In reply to Adolf Belka from comment #50) > > The latest changes have been merged and built. These are expected to resolve > > the routing problems that this bug is related to. > > > > It would be good if @iptom can test those out. > > > > The build version is > > > > Core-Update 197 Development Build: master/0088442c > > At the moment, I do not have access to the test environment that was created. > > However, I have updated another IPFire to Core Update 197 Development Build: > master/d6ec7e0b. > > It seems that after the update, you can connect to internal resources from > Android 15 using the OpenVPN Connect Current Version 3.71 (10568) client > (static pool and dynamic pool) > > Also from Windows 10 + OpenVPN v2.6.14 community edition client. You have a different build number as a further update was done after my testing but nothing to do with this issue. So it has also been verified now by the bug reporter so this makes all the known bugs resolved and CU197 will likely get its full release towards the end of this week or early next week.
https://www.ipfire.org/blog/ipfire-2-29-core-update-197-released