Testing out CU198 with OpenVPN-2.7_alpha3

Testing out CU198 with OpenVPN-2.7_alpha3

[Adolf Belka]

Hi All,

I have built and done initial testing of CU198 with OpenVPN-2.7_alpha3. Here is my initial feedback.

My N2N connection connected and I could ping between both ends. The status on the OpenVPN WUI page showed as Connected.

Only item was that when rebooting the following message shows up in the boot log when the N2N connection is started

DEPRECATED: --persist-key option ignored. Keys are now always persisted across restarts.


I the tested out the old existing Android and Linux Laptop client connections.

In both cases at the client ends they said they were connected.

On the Linux Laptop I could ping to a PC on the green network. For both the Linux Laptop and Android phone I could access the WUI page of the IPFire system. The logs showed that the clients were connected.

However in both cases the OpenVPN WUI page stayed showing the RW connections as disconnected. Accessing the OpenVPN Connection Statistics never showed any connection existing.

So the status methodology for the RW's does not seem to be working with OpenVPN-2.7, even though the connections were successfully connected and the standard openvpn logs show the rw clients as connected.

I will have another go with new client connections and see if that shows anything different with regard to the status.

Also need to remember this is the alpha3 release so there might be bugs still and maybe that is what I am experiencing.

So RW connections get made but stay showing as disconnected when they are actually connected.
N2N connections show as connected and are connected.

Regards

Adolf

Re: Testing out CU198 with OpenVPN-2.7_alpha3

[Michael Tremer]

Hello Adolf,

This is really valuable work because we might have to start transitioning OpenVPN changes a lot sooner than the final release is coming out because of all this bad, static configuration stuff on both sides of the connection.

But this actually proves the opposite. The —-persist-key option can be easily dropped then. We use it everywhere and it will then become the default. Very good.

Regarding the status, there have been many changes over the years and it usually should be easy to fix it. Normally more information is being added and we just need to account for it. Hopefully that is a 5 minute job.

So with this information, I am very relaxed and hopeful that the new 2.7 release will be an easy update for us and everyone using OpenVPN.

Best,
-Michael

> On 17 Aug 2025, at 14:43, Adolf Belka <adolf.belka@ipfire.org> wrote:
> 
> Hi All,
> 
> I have built and done initial testing of CU198 with OpenVPN-2.7_alpha3. Here is my initial feedback.
> 
> My N2N connection connected and I could ping between both ends. The status on the OpenVPN WUI page showed as Connected.
> 
> Only item was that when rebooting the following message shows up in the boot log when the N2N connection is started
> 
> DEPRECATED: --persist-key option ignored. Keys are now always persisted across restarts.
> 
> 
> I the tested out the old existing Android and Linux Laptop client connections.
> 
> In both cases at the client ends they said they were connected.
> 
> On the Linux Laptop I could ping to a PC on the green network. For both the Linux Laptop and Android phone I could access the WUI page of the IPFire system. The logs showed that the clients were connected.
> 
> However in both cases the OpenVPN WUI page stayed showing the RW connections as disconnected. Accessing the OpenVPN Connection Statistics never showed any connection existing.
> 
> So the status methodology for the RW's does not seem to be working with OpenVPN-2.7, even though the connections were successfully connected and the standard openvpn logs show the rw clients as connected.
> 
> I will have another go with new client connections and see if that shows anything different with regard to the status.
> 
> Also need to remember this is the alpha3 release so there might be bugs still and maybe that is what I am experiencing.
> 
> So RW connections get made but stay showing as disconnected when they are actually connected.
> N2N connections show as connected and are connected.
> 
> Regards
> 
> Adolf
> 
> 

Re: Testing out CU198 with OpenVPN-2.7_alpha3

[Adolf Belka]

Hi Michael,

On 18/08/2025 13:47, Michael Tremer wrote:
> Hello Adolf,
> 
> This is really valuable work because we might have to start transitioning OpenVPN changes a lot sooner than the final release is coming out because of all this bad, static configuration stuff on both sides of the connection.
> 
> But this actually proves the opposite. The —-persist-key option can be easily dropped then. We use it everywhere and it will then become the default. Very good.
> 
> Regarding the status, there have been many changes over the years and it usually should be easy to fix it. Normally more information is being added and we just need to account for it. Hopefully that is a 5 minute job.

Based on your input I had a look at the differences in the status log from 2.6 and 2.7

With 2.6 the Real Address is IP:PORT

With 2.7 it is UDP4:IP:PORT

So that definitely looks like it should be easy to fix.

> 
> So with this information, I am very relaxed and hopeful that the new 2.7 release will be an easy update for us and everyone using OpenVPN.

It does look like it should not be so stressful an update as we have had from 2.5 to 2.6

Regards,

Adolf.


> 
> Best,
> -Michael
> 
>> On 17 Aug 2025, at 14:43, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>
>> Hi All,
>>
>> I have built and done initial testing of CU198 with OpenVPN-2.7_alpha3. Here is my initial feedback.
>>
>> My N2N connection connected and I could ping between both ends. The status on the OpenVPN WUI page showed as Connected.
>>
>> Only item was that when rebooting the following message shows up in the boot log when the N2N connection is started
>>
>> DEPRECATED: --persist-key option ignored. Keys are now always persisted across restarts.
>>
>>
>> I the tested out the old existing Android and Linux Laptop client connections.
>>
>> In both cases at the client ends they said they were connected.
>>
>> On the Linux Laptop I could ping to a PC on the green network. For both the Linux Laptop and Android phone I could access the WUI page of the IPFire system. The logs showed that the clients were connected.
>>
>> However in both cases the OpenVPN WUI page stayed showing the RW connections as disconnected. Accessing the OpenVPN Connection Statistics never showed any connection existing.
>>
>> So the status methodology for the RW's does not seem to be working with OpenVPN-2.7, even though the connections were successfully connected and the standard openvpn logs show the rw clients as connected.
>>
>> I will have another go with new client connections and see if that shows anything different with regard to the status.
>>
>> Also need to remember this is the alpha3 release so there might be bugs still and maybe that is what I am experiencing.
>>
>> So RW connections get made but stay showing as disconnected when they are actually connected.
>> N2N connections show as connected and are connected.
>>
>> Regards
>>
>> Adolf
>>
>>
> 
> 

Re: Testing out CU198 with OpenVPN-2.7_alpha3

[Adolf Belka]

Hi Michael,

On 27/08/2025 15:24, Adolf Belka wrote:
> Hi Michael,
> 
> On 18/08/2025 13:47, Michael Tremer wrote:
>> Hello Adolf,
>>
>> This is really valuable work because we might have to start transitioning OpenVPN changes a lot sooner than the final release is coming out because of all this bad, static configuration stuff on both sides of the connection.
>>
>> But this actually proves the opposite. The —-persist-key option can be easily dropped then. We use it everywhere and it will then become the default. Very good.
>>
>> Regarding the status, there have been many changes over the years and it usually should be easy to fix it. Normally more information is being added and we just need to account for it. Hopefully that is a 5 minute job.
> 
> Based on your input I had a look at the differences in the status log from 2.6 and 2.7
> 
> With 2.6 the Real Address is IP:PORT
> 
> With 2.7 it is UDP4:IP:PORT
> 
> So that definitely looks like it should be easy to fix.

I have tested out some changes and have been able to get the OpenVPN Connection statistics and the Status display for each of the connection lines to work again.

So when we come to upgrade to OpenVPN-2.7.x then I know what changes will be needed.

Regards,

Adolf.


> 
>>
>> So with this information, I am very relaxed and hopeful that the new 2.7 release will be an easy update for us and everyone using OpenVPN.
> 
> It does look like it should not be so stressful an update as we have had from 2.5 to 2.6
> 
> Regards,
> 
> Adolf.
> 
> 
>>
>> Best,
>> -Michael
>>
>>> On 17 Aug 2025, at 14:43, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>>
>>> Hi All,
>>>
>>> I have built and done initial testing of CU198 with OpenVPN-2.7_alpha3. Here is my initial feedback.
>>>
>>> My N2N connection connected and I could ping between both ends. The status on the OpenVPN WUI page showed as Connected.
>>>
>>> Only item was that when rebooting the following message shows up in the boot log when the N2N connection is started
>>>
>>> DEPRECATED: --persist-key option ignored. Keys are now always persisted across restarts.
>>>
>>>
>>> I the tested out the old existing Android and Linux Laptop client connections.
>>>
>>> In both cases at the client ends they said they were connected.
>>>
>>> On the Linux Laptop I could ping to a PC on the green network. For both the Linux Laptop and Android phone I could access the WUI page of the IPFire system. The logs showed that the clients were connected.
>>>
>>> However in both cases the OpenVPN WUI page stayed showing the RW connections as disconnected. Accessing the OpenVPN Connection Statistics never showed any connection existing.
>>>
>>> So the status methodology for the RW's does not seem to be working with OpenVPN-2.7, even though the connections were successfully connected and the standard openvpn logs show the rw clients as connected.
>>>
>>> I will have another go with new client connections and see if that shows anything different with regard to the status.
>>>
>>> Also need to remember this is the alpha3 release so there might be bugs still and maybe that is what I am experiencing.
>>>
>>> So RW connections get made but stay showing as disconnected when they are actually connected.
>>> N2N connections show as connected and are connected.
>>>
>>> Regards
>>>
>>> Adolf
>>>
>>>
>>
>>
> 

Re: Testing out CU198 with OpenVPN-2.7_alpha3

[Michael Tremer]

Hello Adolf,

This is great.

I would suggest to create a Git branch somewhere and push those changes right now. That way, we will only have to merge them later and not even think about what changes we need and why.

Best,
-Michael

> On 27 Aug 2025, at 17:58, Adolf Belka <adolf.belka@ipfire.org> wrote:
> 
> Hi Michael,
> 
> On 27/08/2025 15:24, Adolf Belka wrote:
>> Hi Michael,
>> On 18/08/2025 13:47, Michael Tremer wrote:
>>> Hello Adolf,
>>> 
>>> This is really valuable work because we might have to start transitioning OpenVPN changes a lot sooner than the final release is coming out because of all this bad, static configuration stuff on both sides of the connection.
>>> 
>>> But this actually proves the opposite. The —-persist-key option can be easily dropped then. We use it everywhere and it will then become the default. Very good.
>>> 
>>> Regarding the status, there have been many changes over the years and it usually should be easy to fix it. Normally more information is being added and we just need to account for it. Hopefully that is a 5 minute job.
>> Based on your input I had a look at the differences in the status log from 2.6 and 2.7
>> With 2.6 the Real Address is IP:PORT
>> With 2.7 it is UDP4:IP:PORT
>> So that definitely looks like it should be easy to fix.
> 
> I have tested out some changes and have been able to get the OpenVPN Connection statistics and the Status display for each of the connection lines to work again.
> 
> So when we come to upgrade to OpenVPN-2.7.x then I know what changes will be needed.
> 
> Regards,
> 
> Adolf.
> 
> 
>>> 
>>> So with this information, I am very relaxed and hopeful that the new 2.7 release will be an easy update for us and everyone using OpenVPN.
>> It does look like it should not be so stressful an update as we have had from 2.5 to 2.6
>> Regards,
>> Adolf.
>>> 
>>> Best,
>>> -Michael
>>> 
>>>> On 17 Aug 2025, at 14:43, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>>> 
>>>> Hi All,
>>>> 
>>>> I have built and done initial testing of CU198 with OpenVPN-2.7_alpha3. Here is my initial feedback.
>>>> 
>>>> My N2N connection connected and I could ping between both ends. The status on the OpenVPN WUI page showed as Connected.
>>>> 
>>>> Only item was that when rebooting the following message shows up in the boot log when the N2N connection is started
>>>> 
>>>> DEPRECATED: --persist-key option ignored. Keys are now always persisted across restarts.
>>>> 
>>>> 
>>>> I the tested out the old existing Android and Linux Laptop client connections.
>>>> 
>>>> In both cases at the client ends they said they were connected.
>>>> 
>>>> On the Linux Laptop I could ping to a PC on the green network. For both the Linux Laptop and Android phone I could access the WUI page of the IPFire system. The logs showed that the clients were connected.
>>>> 
>>>> However in both cases the OpenVPN WUI page stayed showing the RW connections as disconnected. Accessing the OpenVPN Connection Statistics never showed any connection existing.
>>>> 
>>>> So the status methodology for the RW's does not seem to be working with OpenVPN-2.7, even though the connections were successfully connected and the standard openvpn logs show the rw clients as connected.
>>>> 
>>>> I will have another go with new client connections and see if that shows anything different with regard to the status.
>>>> 
>>>> Also need to remember this is the alpha3 release so there might be bugs still and maybe that is what I am experiencing.
>>>> 
>>>> So RW connections get made but stay showing as disconnected when they are actually connected.
>>>> N2N connections show as connected and are connected.
>>>> 
>>>> Regards
>>>> 
>>>> Adolf

Re: Testing out CU198 with OpenVPN-2.7_alpha3

[Adolf Belka]

Hi Michael,

On 28/08/2025 10:46, Michael Tremer wrote:
> Hello Adolf,
> 
> This is great.
> 
> I would suggest to create a Git branch somewhere and push those changes right now. That way, we will only have to merge them later and not even think about what changes we need and why.

Will do so.

I found in the deprecated options section of OpenVPN a comment that says

WARNING: This migration approach will not work after the release of OpenVPN v2.7. As of that release, BF-CBC, CAST or RC2 ciphers will not be accepted any more.

This is in the section on migrating away from deprecated ciphers.

However there is also the statement in removal of insecure ciphers

For now we will not officially remove them and focus on educating users. Maybe at some point the SSL libraries will start dropping them.

I tested out running openvpn with BF-CBC in the ciphers-data-fallback and got the following message in the openvpn-2.7 logs

WARNING: INSECURE cipher (BF-CBC) with block size less than 128 bit (64 bit).  This allows attacks like SWEET32.  Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). Support for these insecure ciphers will be removed in OpenVPN 2.7.

I also then manually changed the server.conf file to have data-ciphers also set to BF-CBC and then restarted openvpn-rw and the same above message is shown but openvpn-rw is running.

So the insecure ciphers will still be accepted but there will be a warning in the logs.

On the compression front, I found the following statement in the openvpn-2.7 changes

--------------
Remove support for compression on send

We can't disable compression support on receive because
that would break too many configurations out there. But
we can remove the support for compressing outgoing traffic,
it was disabled by default anyway.

Makes "--allow-compression yes" an alias for
"--allow-compression asym" and removes all resulting dead code.
--------------

So the compress outgoing was disabled by default anyway but in 2.7 the code will no longer exist in openvpn

I don't believe this changes how we are using the compress migrate option but I thought I would flag it up for you to see.

Interesting that they are saying now that they can't as standard disable compression support on receive due to so many user configs using it.

Regards,

Adolf.


> 
> Best,
> -Michael
> 
>> On 27 Aug 2025, at 17:58, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>
>> Hi Michael,
>>
>> On 27/08/2025 15:24, Adolf Belka wrote:
>>> Hi Michael,
>>> On 18/08/2025 13:47, Michael Tremer wrote:
>>>> Hello Adolf,
>>>>
>>>> This is really valuable work because we might have to start transitioning OpenVPN changes a lot sooner than the final release is coming out because of all this bad, static configuration stuff on both sides of the connection.
>>>>
>>>> But this actually proves the opposite. The —-persist-key option can be easily dropped then. We use it everywhere and it will then become the default. Very good.
>>>>
>>>> Regarding the status, there have been many changes over the years and it usually should be easy to fix it. Normally more information is being added and we just need to account for it. Hopefully that is a 5 minute job.
>>> Based on your input I had a look at the differences in the status log from 2.6 and 2.7
>>> With 2.6 the Real Address is IP:PORT
>>> With 2.7 it is UDP4:IP:PORT
>>> So that definitely looks like it should be easy to fix.
>>
>> I have tested out some changes and have been able to get the OpenVPN Connection statistics and the Status display for each of the connection lines to work again.
>>
>> So when we come to upgrade to OpenVPN-2.7.x then I know what changes will be needed.
>>
>> Regards,
>>
>> Adolf.
>>
>>
>>>>
>>>> So with this information, I am very relaxed and hopeful that the new 2.7 release will be an easy update for us and everyone using OpenVPN.
>>> It does look like it should not be so stressful an update as we have had from 2.5 to 2.6
>>> Regards,
>>> Adolf.
>>>>
>>>> Best,
>>>> -Michael
>>>>
>>>>> On 17 Aug 2025, at 14:43, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> I have built and done initial testing of CU198 with OpenVPN-2.7_alpha3. Here is my initial feedback.
>>>>>
>>>>> My N2N connection connected and I could ping between both ends. The status on the OpenVPN WUI page showed as Connected.
>>>>>
>>>>> Only item was that when rebooting the following message shows up in the boot log when the N2N connection is started
>>>>>
>>>>> DEPRECATED: --persist-key option ignored. Keys are now always persisted across restarts.
>>>>>
>>>>>
>>>>> I the tested out the old existing Android and Linux Laptop client connections.
>>>>>
>>>>> In both cases at the client ends they said they were connected.
>>>>>
>>>>> On the Linux Laptop I could ping to a PC on the green network. For both the Linux Laptop and Android phone I could access the WUI page of the IPFire system. The logs showed that the clients were connected.
>>>>>
>>>>> However in both cases the OpenVPN WUI page stayed showing the RW connections as disconnected. Accessing the OpenVPN Connection Statistics never showed any connection existing.
>>>>>
>>>>> So the status methodology for the RW's does not seem to be working with OpenVPN-2.7, even though the connections were successfully connected and the standard openvpn logs show the rw clients as connected.
>>>>>
>>>>> I will have another go with new client connections and see if that shows anything different with regard to the status.
>>>>>
>>>>> Also need to remember this is the alpha3 release so there might be bugs still and maybe that is what I am experiencing.
>>>>>
>>>>> So RW connections get made but stay showing as disconnected when they are actually connected.
>>>>> N2N connections show as connected and are connected.
>>>>>
>>>>> Regards
>>>>>
>>>>> Adolf
> 
> 
> 

Re: Testing out CU198 with OpenVPN-2.7_alpha3

[Michael Tremer]

Hello Adolf,

> On 2 Sep 2025, at 11:34, Adolf Belka <adolf.belka@ipfire.org> wrote:
> 
> Hi Michael,
> 
> On 28/08/2025 10:46, Michael Tremer wrote:
>> Hello Adolf,
>> This is great.
>> I would suggest to create a Git branch somewhere and push those changes right now. That way, we will only have to merge them later and not even think about what changes we need and why.
> 
> Will do so.
> 
> I found in the deprecated options section of OpenVPN a comment that says
> 
> WARNING: This migration approach will not work after the release of OpenVPN v2.7. As of that release, BF-CBC, CAST or RC2 ciphers will not be accepted any more.
> 
> This is in the section on migrating away from deprecated ciphers.
> 
> However there is also the statement in removal of insecure ciphers
> 
> For now we will not officially remove them and focus on educating users. Maybe at some point the SSL libraries will start dropping them.
> 
> I tested out running openvpn with BF-CBC in the ciphers-data-fallback and got the following message in the openvpn-2.7 logs
> 
> WARNING: INSECURE cipher (BF-CBC) with block size less than 128 bit (64 bit).  This allows attacks like SWEET32.  Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC). Support for these insecure ciphers will be removed in OpenVPN 2.7.
> 
> I also then manually changed the server.conf file to have data-ciphers also set to BF-CBC and then restarted openvpn-rw and the same above message is shown but openvpn-rw is running.
> 
> So the insecure ciphers will still be accepted but there will be a warning in the logs.

This should not *really* bother us because we should soon have all servers supporting NCP. That way, all clients which also support NCP will automatically migrate away from the statically configured ciphers (no matter what it is). If people are using clients that are still not supporting NCP (pre 2.4), those will break when they are removing support for these ciphers on the server side. However, even 2.5 is already EOL, so nobody should be on OpenVPN <= 2.3.

> On the compression front, I found the following statement in the openvpn-2.7 changes
> 
> --------------
> Remove support for compression on send
> 
> We can't disable compression support on receive because
> that would break too many configurations out there. But
> we can remove the support for compressing outgoing traffic,
> it was disabled by default anyway.
> 
> Makes "--allow-compression yes" an alias for
> "--allow-compression asym" and removes all resulting dead code.
> --------------
> 
> So the compress outgoing was disabled by default anyway but in 2.7 the code will no longer exist in openvpn
> 
> I don't believe this changes how we are using the compress migrate option but I thought I would flag it up for you to see.
> 
> Interesting that they are saying now that they can't as standard disable compression support on receive due to so many user configs using it.

The configuration might still include “compress”, but actually, OpenVPN won’t really compress any data any more. The “compress migrate” option might sometimes add a special header which was formerly required when compression was enabled, but it won’t compress the payload any more. Currently, our server is configured to accept compressed packets (if the client really insists), but it will never send a compressed packed as that would make the stream vulnerable to the voracle attack.

So this should not really affect us. In fact it is a good thing because we can rely on clients >= 2.7 never to send any compressed data either which would be a security benefit.

So, all green lights from me on the 2.7 front for now!

-Michael

> 
> Regards,
> 
> Adolf.
> 
> 
>> Best,
>> -Michael
>>> On 27 Aug 2025, at 17:58, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>> 
>>> Hi Michael,
>>> 
>>> On 27/08/2025 15:24, Adolf Belka wrote:
>>>> Hi Michael,
>>>> On 18/08/2025 13:47, Michael Tremer wrote:
>>>>> Hello Adolf,
>>>>> 
>>>>> This is really valuable work because we might have to start transitioning OpenVPN changes a lot sooner than the final release is coming out because of all this bad, static configuration stuff on both sides of the connection.
>>>>> 
>>>>> But this actually proves the opposite. The —-persist-key option can be easily dropped then. We use it everywhere and it will then become the default. Very good.
>>>>> 
>>>>> Regarding the status, there have been many changes over the years and it usually should be easy to fix it. Normally more information is being added and we just need to account for it. Hopefully that is a 5 minute job.
>>>> Based on your input I had a look at the differences in the status log from 2.6 and 2.7
>>>> With 2.6 the Real Address is IP:PORT
>>>> With 2.7 it is UDP4:IP:PORT
>>>> So that definitely looks like it should be easy to fix.
>>> 
>>> I have tested out some changes and have been able to get the OpenVPN Connection statistics and the Status display for each of the connection lines to work again.
>>> 
>>> So when we come to upgrade to OpenVPN-2.7.x then I know what changes will be needed.
>>> 
>>> Regards,
>>> 
>>> Adolf.
>>> 
>>> 
>>>>> 
>>>>> So with this information, I am very relaxed and hopeful that the new 2.7 release will be an easy update for us and everyone using OpenVPN.
>>>> It does look like it should not be so stressful an update as we have had from 2.5 to 2.6
>>>> Regards,
>>>> Adolf.
>>>>> 
>>>>> Best,
>>>>> -Michael
>>>>> 
>>>>>> On 17 Aug 2025, at 14:43, Adolf Belka <adolf.belka@ipfire.org> wrote:
>>>>>> 
>>>>>> Hi All,
>>>>>> 
>>>>>> I have built and done initial testing of CU198 with OpenVPN-2.7_alpha3. Here is my initial feedback.
>>>>>> 
>>>>>> My N2N connection connected and I could ping between both ends. The status on the OpenVPN WUI page showed as Connected.
>>>>>> 
>>>>>> Only item was that when rebooting the following message shows up in the boot log when the N2N connection is started
>>>>>> 
>>>>>> DEPRECATED: --persist-key option ignored. Keys are now always persisted across restarts.
>>>>>> 
>>>>>> 
>>>>>> I the tested out the old existing Android and Linux Laptop client connections.
>>>>>> 
>>>>>> In both cases at the client ends they said they were connected.
>>>>>> 
>>>>>> On the Linux Laptop I could ping to a PC on the green network. For both the Linux Laptop and Android phone I could access the WUI page of the IPFire system. The logs showed that the clients were connected.
>>>>>> 
>>>>>> However in both cases the OpenVPN WUI page stayed showing the RW connections as disconnected. Accessing the OpenVPN Connection Statistics never showed any connection existing.
>>>>>> 
>>>>>> So the status methodology for the RW's does not seem to be working with OpenVPN-2.7, even though the connections were successfully connected and the standard openvpn logs show the rw clients as connected.
>>>>>> 
>>>>>> I will have another go with new client connections and see if that shows anything different with regard to the status.
>>>>>> 
>>>>>> Also need to remember this is the alpha3 release so there might be bugs still and maybe that is what I am experiencing.
>>>>>> 
>>>>>> So RW connections get made but stay showing as disconnected when they are actually connected.
>>>>>> N2N connections show as connected and are connected.
>>>>>> 
>>>>>> Regards
>>>>>> 
>>>>>> Adolf
> 
>