VST Connect Pro on multiple NIC machine

I’m trying to migrate my production setup to a new machine that has two NICs. Through various experiments it seems that VST Connect Pro is binding to the wrong NIC. I am unable to connect VST Connect Performer to a session originated on the dual NIC host.
I have two machines on the 10.1.1 subnet and one machine on both 10.1.1 and 10.10.1. If I start VST Connect Pro from the dual NIC machine, neither of the other two can connect to it via Performer.
If I start VST Connect Pro on one of the single NIC machines, I can connect to it via Performer on both other machines (including the dual NIC host). So the dual NIC can connect as Performer to the machines on 10.1.1. However these same machines cannot connect to VST Connect Pro hosted on the dual NIC machine.
This appears to indicate that VST Connect Pro is binding “listening” to the 10.10.1 subnet.
Is there a way to force the session to bind to the NIC on 10.1.1?

With further experimenting, it seems that the issue(s) are unidirectional. If I start Connect Pro on one of my two older machines, I am able to connect with Performer from my newer machine. Going the other direction does not work.
I have disabled Norton Smart Firewall to no avail. Removing a NIC for a single interface also did not solve the problem. Nor did uninstall/reinstall of Connect Pro and Performer. It seems to be an issue with discovery on the newer machine.
Anyone know if there’s a service for the discovery protocol that needs to be started? Not sure what to try next.
BTW, the newer machine is running Windows 11. Any chance that’s the root cause?

Trying to follow this. There is no specific address that the Studio side (running the plugin) is listening to.
When you start Performer, it shows a list of local IP addresses that have made themselves known to the local VST Connect network. Do you see all of those?
Pls. describe exactly what you are doing, and what you expect, thanks.

I didn’t say anything about a specific address, but let’s not confuse the issue about that.

Let’s start simple! Let’s start with two machines. If I run the plugin on one and performer on the other, it works as expected. Now, swap the roles, with studio and performer reversed, it does NOT work.

First natural choice…a firewall getting in the way. However, I have disabled the firewall with the same results. So, what else is different? The host where the plugin (studio) version will not see performer is: A. Windows 11 host. B. Dual NIC. C. Norton 360.

What do I expect? For this test to work in BOTH cases.

I’m not sure about your question, but I’m assuming you are talking about when I click on the LAN connect button. In the working scenario, I do see the network address of the studio. The LAN connect button is also lit, as expected.

Now I reverse the roles. Studio on the other machine. Performer LAN connect button NOT lit and I do not see any network address (as expected).

I think my next step is to remove Norton 360 to see if that resolves the issue.

If you are suggesting additional tests, please describe. My current hypothesis is that discovery protocol is failing for one case and working for the other case. I have not broken out Wireshark yet to look at the network traffic.

Removing Norton and disabling Windows firewall, same results.

Cannot get Performer to see the connection If the Windows 11 machine is the studio.

Performer running on two machines sees the connection if I run the studio on a Windows 10 machine.

This begs the question…are there any known apps or services that block network discovery on the studio side, causing the same machine to work with performer but NOT connect Pro as the studio side.

Never had that.

Just my personal opinion, but I removed all anti-spam from all of my machines (those are many) and only gainig advantage. Unless you walk on dark grounds (and probably even then), system protection is sufficient. Just my 2c, though.

As said, I never had that.

…right :slight_smile:

Unfortunately I have no more ideas so far but removing anti-virus stuff.

I get that in the non-working case, the Performer machine does not reveal the network address of the running Studio system when clicking the LAN button? And that you are not logged in on either side - but in that case the LAN button is not activated anyway afaik.

If you run Wireshark you should see both Studio and Performer sending UDP messages, see if anything blocks those. Wouldn’t be surprised if Norton did.

Hope that helps.

On both sides?

You say it works with Windows 10 but not with Windows 11?
Sorry if I missed that. Will make some tests immediately.
Let me reiterate: with Studio running Win 11, Performer Win 10 nothing works, while win10/win10 does in both directions, right?

Yes, I assume something blocks UDP traffic. Maybe Wireshark reveals more.

Wireshark shows that no UDP packets are being generated with studio on the Windows 11 side. With studio on the Windows 10 side, I am seeing UDP packets to port 51117 and once performer connects, responses to UDP port 51113.

I only had Norton on the Windows 11 side, removal did not change anything.

Again, no UDP packets outgoing on the Windows 11 side.

To clarify: Studio on Windows 11 does not work. Studio on Windows 10 side, performer works on both Windows 10 and Windows 11.

For now I could only make a short test, connected two win 11 systems w/o problems and swapped also w/o problems.
Windows 11 Pro Insider Preview v 22H2 on both sides.
Basically it does not look as if Win 11 blocks outgoing UDP by default, so there must be something else on your win11 system I guess.

Well, I’m running Wireshark on both sides, so whatever is “blocking” I am seeing no outgoing UDP packets from 11.

My first thought was a problem with dual NIC on the Windows 11 side. I’m not sure how to confirm. Clearly SOMETHING is causing a problem with UDP outgoing. Removing one NIC and reinstalling did not correct the problem. I’m back to dual NICs.

Not sure what to try next. Windows 11 22H2. Perhaps stopping startup tasks that may already be using ports 51113 or 51117?

A bit more exploration with Wireshark shows UDP packets to UDP port 51117 from Cubase 12, going out on 192.168.56.1. This is NOT the IP address of my wired subnet(s)! This appears to be some kind of network loopback with packets labelled as Interface Id: 0 \Device\NPF_Loopback.

Of course, this makes perfect sense why the Performer would not respond. It’s not on that network! I need to figure out what is going on with my network configuration that’s causing this. I would appreciate any ideas. Otherwise, I will investigate the network configuration.

I removed a couple of packages I was using for MIDI testing with MIDIOX AND removed MIDIOX.

The programs were rtpMIDI and loopMIDI, that were used to route MIDI over Ethernet. Seems plausible that these were potentially interfering.

After rebooting, and starting Wireshark again, I am now seeing the VST Connect UDP traffic on the network and can now connect with Performer.

Quite possible that these were causing problems with VST Connect.

Thanks for sorting it out.
It might be that those use the same ports as VST Connect. However afaik VST Connect should provide a warning in this case, will check.

Could be that they use the same port, or confused connect into using what appeared to be a loopback address.
It would be helpful if both connect and performer would report IP of the subnet(s) they are using, Granted, connect DOES report the IP of the peer performer instances it sees, per your previous comment.
At some point I may verify what software is the culprit. After moving everything to the new machine I no longer need to route MIDI the way I was, for now anyway. Thanks!