-- 2 identical identities can't connect to the same VPN a...

[mdk]

@sillsd -- 2 identical identities can't connect to the same VPN at the same time. 

I think that you just answered your own question. The VPN-server could be enforcing a limit of one simultaneous session per identity.

Presumably, your company has many of its employees working-from-home, and each employee has a unique identity.

[sillsd]

As per my initial post, this problem only started after switching from a 3rd-party Wifi router to Bluecurve.  The old router seems to have appended something to packets to ensure the VPN connections from different devices were unique.  The Bluecurve modem doesn't, and I haven't found any settings that allow me to do this.

[mdk]

@sillsd -- The BlueCurve is doing NAT ("Network Address Translation").

One of your computers opens a port on your local computer, and tries, from its unique and private IP-address, to connect, to the VPN-server on the Internet. However, the BlueCurve "translates" the private IP-address to the public IP-address of the BlueCurve, and changes the port-number.  So, the VPN-server sees that "public" IP-address, and a port-number that does not match the port-number on your computer. The VPN-server sends its responses to the public IP-address of your router, with the translated port-number. Then, the BlueCurve recognizes that the translated port-number was generated from the port-number on your computer, and sends the response to the "private" IP-address, and port-number, that your computer has opened.

What this means is that the BlueCurve is doing this "translation" for both computers on your local network. The BlueCurve should be capable of handing multiple "private" IP-addresses, and should be "translating" and "reverse-translating" the port-numbers.

So, I think that there is no need to put extra "tag" information in the packets being sent from the BlueCurve.

[sillsd]

What you describe sounds reasonable, and if this were happening we shouldn't have a problem connecting 2 separate devices from our local network to the same VPN server.  The fact remains, pre-Bluecurve (using a different WiFi modem behind an old Shaw cable modem), we had no problem doing this, and post-Bluecurve, we cannot connect more than one local device to the same VPN server.

[mdk]

@sillsd -- post-Bluecurve, we cannot connect more than one local device to the same VPN server.

Is the problem connecting more than one device, or a problem connecting multiple devices with the same ID/password?

Are you sure that it is the "same" VPN server?  System administrators have been known to roll-out a software upgrade that has unexpected problems.  Shaw rolled-out a new Voice Mail server very recently, and now all my V.M. messages are announced as if I were in the Mountain Timezone, instead of being in the Pacific Timezone. Oops!

[sillsd]

We are 2 devices behind the Bluecurve gateway.  We each connect to the same VPN server with different userid's.  We know it is a single VPN server -- we are a very small company and are in close communication with the administrator.  The problem started when we switched over from our old Wifi gateway through an old Shaw cable modem, to Bluecurve.  There were no updates/changes on the VPN server side or to our devices around this time period.

[mdk]

@sillsd -- We each connect to the same VPN server with different userids. 

OK. That rules out one possibility -- namely that the VPN-server does not allow any ID to be logged-in more than once at a time -- no "simultaneous" sessions.

> we ... are in close communication with the administrator.

What does he/she/they say about what is seen on the VPN-server? Error-messages in its log-files?

[shaw-tony]

@sillsd just to confirm, off VPN, are both your connections solid with no issues? Your modem signals from the wall outlet are a bit off-spec, what connection troubleshooting steps have you tried so far?

[sillsd]

Yes, we rarely have any problems with the VPN -- it's stable, and although we don't move huge amounts of data, it's as fast as we need it to be.

[sillsd]

I can't recall, but I think it was confirming the rejection of a connection request from a 2nd identical source.  Will reconfirm later this week.