You have two options from a networking perspective:
Lots of NAT. By default, I assume your VMs are set to use NAT mode in whatever virtualization solution you have, which makes this a little tricky. Doable, but tricky.
"Bridge" the VMs to the actual network that the host systems are on as well, which removes the NAT headaches. This is the easier option.
Option 1: VM Networking in NAT Mode
NOTE: I have never gotten this to work reliably, I have always used Bridged mode which is far more reliable.
VMware and VBox both are set up to permit NAT, and port forwards. This is all fine and dandy, but there's some headaches this brings.
You cannot easily set up NAT port forwarding unless you have VMware Workstation Pro. This is because the virtual network editor for NAT port forwards is not shipped with Workstation Player or the older VMware Player software versions.
Assuming you have the Virtual Network Manager/Editor though do the following on the system that has the VM that will be the 'server':
(1) Open the Virtual Network Manager / Editor, and select the one adapter with "NAT" as the "external connection" listing. It'll look something like this image shows:
(2) Select "NAT Settings", and you'll get a window like this one:
(3) Under the "Port Forwarding" area, click "Add". You get a window like this one:
Set the information as follows:
Host Port: Likely to be the same port you're having the Server listen
on in the VM, but it can be something else if you want.
Type: TCP or UDP is dependent on your server and how it listens. Safe
to assume TCP here, though, most active-connection server things are
IP Address: The IP address of the VM. You can get this with
ip -4 addr list from inside the VM on the command line.
Virtual Machine Port: The port that the server application will be
Description: A description of what this port forward is for.
You'll probably have to shut off your VM temporarily, and restart the VMware services with
sudo systemctl restart vmware so it reloads all the port forwarding/bridging rules.
(4) Start up the VM with the server on it. From the Client VM, make sure you tell the Client to connect to the IP Address of the computer that is running the Server VM (so if the laptop with the Server VM on it has IP address of 192.168.250.20, the Client VM's application should try and connect to 192.168.250.20.)
Note that this will not work in all cases, and I strongly recommend the use of Bridged mode instead.
I have never gotten VBox NAT network port forwarding to behave. If you are using VBox, I strongly suggest you use Bridged mode instead of NAT. (While this doesn't clearly answer for VBox, I tried testing these Port Forwards from VBox and couldn't get it to work at all).
Not that I didn't try, but on 16.04, VirtualBox was not able to connect outbound to anything, and never set up any virtual network interfaces for NAT capabilities; I assumed then that it can't work right without Bridged but I can't find why it never brought up NAT capacity.
Option 2: VM Networking: Bridged Mode
You will need to run the VMs in "Bridged" mode and then use IP addresses from your own LAN/Wifi network that are assigned to the VMs (as a result of "bridged" allowing the VMs to connect to and look like they're on the actual network of the host computers).
Firstly, configure the VMs on both systems to use the "Bridged Network" mode. How this shows will be different from VM solution to VM solution, but it'll always say "Bridged" or similar (at least, in VMware or VBox). Make sure the device that you're "bridged" to is your preferred network card (wifi or ethernet), so you're properly going out to the right network with the VM for an IP address.
Secondly, reboot the VMs if they're already online. This should get them a brand new IP address from the same network as the host machines. (It should be in the same subnet range even).
Thirdly, point the client of the one VM to the IP of the server on the other VM. Because the networking is Bridged, it should just connect. You may have to tweak the VMs on the guests to make sure it permits connections though.
That should be it then, for the VMs, and they should be able to interconnect without issue.