waykbastion lost peer-to-peer connections, now requires relay only

Hi All,

ok ive been able to identify the issue i believe,

it appears ONLY MAC AGENTS are having this issue,
i can connect from my android and ios clients to windows agents no problem and the logs shows the clients ip there for direct connection and it even uses it,

however the minute i try connecting to a MAC AGENT, the is no direct connection possible, its only relay!?

Regards

Simon

Hi Simon

Can you please share with us a log file from the client side, showing a connection onto both a Windows and macOS Agent? Either by PM or at wayk@devolutions.net.

(I think you're pretty comfortable with enabling / grabbing the log file but please ask if something is unclear)

Thanks and kind regards,

Hi Richard,

you should have a PM from me :)

Regards

Simon

Hi Simon

Thanks for sending it over. Strange indeed, that the direct connection is not advertised by your macOS Agent. If possible, could you send the logs from that machine? We're interested in both the global and client log, so:

~/Library/Application Support/Wayk/logs/WaykAgent.log
/Library/Application Support/Wayk/logs/NowService.log

To clarify things: the changelog refers to specific cases where your external URL is http. If this is the case, you will receive a warning that P2P connections might not work; because the Wayk Agent and Client won't use insecure websockets by default. The TCP relay is not configured by default either, so in this case connectivity likely won't work over the internet. However - *direct* connections should still work.

Of course none of that applies, since you are using https, and you are expecting a direct connection. The Agent should always advertise the direct route; there are only two cases I can think of that it wouldn't work:

• Direct connections can be disabled, but currently I think that's controlled by an environment variable (and if you had configured it, you would know about it)
• The Agent couldn't create a TCP listener for whatever reason

The second case is a bit more nuanced; since the macOS Agent isn't able to respond well to changes in network configuration (Windows does better here). The Agent logs should tell us more, if available.

Thanks and kind regards,

Hi Simon

As a further thought, it really sounds like the TCP listener was not created when the macOS Agent started. The Agent will wait ~15s for the network to be available on startup. Maybe the machine (re)booted and the network was not available at that time?

You could try restarting the machine and see if that helps.

In any case, the logs would tell us the full story.

Thanks and kind regards,

Hi Richard,

the issue machine is actually both a fresh install of OSX 10.14 in a VM on parallels desktop and my own personal mac laptop,
so i cant see this being a restart issue, but more of a waykagent issue?

i have DM you the logs

Regards

Simon

Hi Simon

Thanks for the logs

It looks like, at the point the agent daemon was started, it didn't have network connectivity yet.

With the machine up-and-running, first close WaykAgent.app if it's running and then try this:

sudo launchctl kickstart -k system/NowService

Wait a moment or two for the service to reboot; then check if you can access via direct connection.

I'm not proposing this as a solution but to help clarifiy the issue.

Thanks and kind regards,

Hi Richard,

that seemed to do the trick! but its a manual process to get direct connection working!

i didnt even need to close the waykagent.app, just simply kickstart the service, and then when i connected, it showed in the logs the internal ip as a direct connection option!

so im guessing the nowsession isnt doing the logical
"is direct connection listening? no? let me restart the service or start listening again in case of an issue on start up"

also this happens on both the vm and my macbookpro so i think the app is starting up too quickly, and trying to listen on the computers ip but the ip isnt ready yet!

Regards

Simon

Hi Simon

Indeed. When connecting through the relay, the Agent opens an outgoing connection(s) to the relay server at connection time. For a direct connection, the listeners are created and bound to the system network interfaces at start time. In this case, the system doesn't "know" it's about to receive a connection, so there's no retrograde steps the service can take at that time.

Historically, the Agent would wait up to 15s on start to find at least one network interface with a routable IP, but wouldn't reconfigure itself if the network setup changed later. We resolved this on Windows some time ago, but I can see that was never done on macOS or Linux. I'll enter a ticket for this and we'll get the feature caught up. I'll post back here once I have an update on that.

Thanks and kind regards,