

Glad I could help! 😃


Glad I could help! 😃


Ok, I grabbed a few screen shots for you as well. Here is a site that will link you to MEBx setup that enables AMT: http://h10032.www1.hp.com/ctg/Manual/c03883429
When power on your ProDesk G3, you can access the MEBx setup by pressing Ctrl+P or they also say F6 or Escape will get you there. Intel AMT runs on a different IP address than what your OS gets. You can assign DHCP or a static IP address and setup your admin password. You can then access the portal from http://ipaddress:16992 There should be a method of access what would show on the screen through a KVM like access but I use MeshCentral for that so I couldn’t tell you how to do it without.
Hopefully, that gives you a start. Feel free to reach back out if you have any questions. Thank you!



I’m not in front of my computer atm, but I think I have something that can help you out. I have a 3-node Lenovo Thin client cluster that I manage their KVMs using the Intel vPro. I even went a step further using MeshCentral running on a VM to centralize my KVM access since I have 3 of them, but that’s another story.
Anyway, I’ll see if I can grab you some URLs in the morning if someone else doesn’t beat me to it or you find it on your own running google queries.


3-Node ESXi cluster with 10 Debian VMs, 3 Windows VMs, and one FreeBSD VM


deleted by creator


They call it a tcpdump but Wireshark analyzes all network traffic. You can use the udp.port == 51820
Do you have a laptop? Probably more tools and easier to test from there.


Meant to say if you still get stuck, run Wireshark on your FW and your VPS and run a tcp dump and filter the traffic to see where the data stops.
You can also use traceroute to your public IP on the port 51820 and check your connectivity or even curl: -v http:////publicip:51820


Did you setup a NAT on the firewall? You have to setup a static NAT on the interface that your Public IP sits on and to the private IP address of your VPS (you are using a private network space from one of the other interfaces on your FW right?).
Make sure that the policy that you create with the NAT includes UDP 51820 (unless you changed the default port) People often mistake using TCP which is a different protocol. If that doesn’t work, then look at the traffic on your FW
So I’m not sure if this is the problem affecting your friend, however, RCS messaging uses additional ports rather than just the standard tcp/443 port to send traffic. This port is specifically tcp/5223. If your friend connects to a wireless network that has a firewall that doesn’t have the port open, then the RCS messages will fail to send/receive until they are either connected to their cellular network or a wireless network that doesn’t have that port blocked.
The catch is, if you try to send a message while you are on a network where the traffic isn’t allowed, the RCS message doesn’t attempt to resend right away after changing to a network where the traffic is allowed.
I have a firewall in my house that has very strict rules and I had to enable a firewall policy to allow this traffic to be able to send / receive RCS messages when I was connected to my home’s WiFi. My wife’s company WIFi network has that port blocked so she doesn’t connect to it anymore and RCS works just fine.
If you want to see if this is the case for your friend’s phone, have them use their mobile network while sending / receiving RCS messages to test.