I run a small business and I have purchase an inventory software. This software requires there be a server, and workstations that connect to the server in order to run the client software.

For authentication purposes, when the client software tries to connect to the server, the asks for the client's IP and MAC addresses. Everything works just fine when 6 of the client computers, which are on the same local network as the server, connect to server and use the software.

However, I have a remote computer which I have connected to the network via VPN through the router, and I've joined the Windows Domain using this method. However, the server software is programmed to resolve both the IP and the MAC address of any connecting client machines. But because this remote computer is connected via VPN, remotely, it fails to "Resolve" the MAC address.

Is there any hardware, or any kind of configuration that will allow me to have an actual MAC address on the network when I'm connected via VPN? I'm currently using Windows 10 PRO on the remote machine and using its built in VPN connector feature to connect to the Domain. I guess it needs to be as if I'm sitting there on the actual network with a physical MAC.

Also, before you ask, no I am not doing anything illegal or out of bounds for the software we purchased. The company we got it from said if we can make it work with a remote machine, that would be perfectly fine. Hope to have some help!

  • 5
    You cannot resolve a MAC address on a different LAN. – Ron Maupin Sep 22 '17 at 2:57
  • So does this software work if you have a machine on a different local subnet connecting? – mfinni Sep 22 '17 at 16:55

(this should be a comment, but was too long)

From the server's point of view, it should see the MAC address of the device terminating the VPN connection (unless this is on same device as the server). But you've told us nothing about the network architecture.

is programmed to resolve both the IP and the MAC address

TCP/IP on ethernet (and most other media) just doesn't work without being able to resolve the MAC address. OTOH the MAC address is not intended to be visible above the IP layer. Sounds like a dodgy ant-piracy system designed by someone who is convinced everyone wants to steal his software and doesn't understand networks. This implies some ropey bit of code divining the MAC address/IP association - which we can't reverse engineer remotely.


How "I know your IP and MAC address" is an authentication mechanism just boggles the mind. The crazy stuff some people come up with...

At any rate, there's two possibilities I can think of, one (or both) of which might work depending on exactly how this misguided attempt at... whatever the hell they're trying to do... is implemented:

  1. Have the local VPN endpoint NAT the connection. If the nature of the check is "does the MAC address of the received packet match the known MAC address of the source IP of the packet?", then simply NATing the connection to an on-link IP address will work -- because the apparent source IP of the connection matches. On the other hand, if the client-side software sends the IP address and/or MAC it sees on the machine it's running on to the server, and then the server checks that the IP/MAC address on the incoming packet matches the details the client software sends, you're screwed -- in which case, you'll want to try door #2...
  2. Put the remote machine on-net over the VPN. I don't know if the Windows 10 VPN will support this (probably not), but some VPN software (I'm familiar with OpenVPN, specifically) is able to create the rather convincing appearance that a machine over the VPN is, in fact, on the same Ethernet LAN as the other machines on the network. That means that the machine's (VPN) IP address will be in the same IP network as the rest of the LAN machines, it will see Ethernet broadcast packets, and (apparently the important bit for this exercise) the MAC address of packets received by other machines on the LAN will match the machine's interface MAC address. However, the machine will have a second network interface configured for the LAN access, and given the general level of (in)competence displayed so far by the maker of this software, I would not be confident that the software will correctly handle machines that have multiple network interfaces. Which brings us to door number 3...
  3. Put a VM on the local network. Chuck a small VM onto the server, install the client software, connect to it remotely via RDP, and be done with it. It's on the local network (assuming you setup the VM on a bridged network), it'll have a local IP and MAC address, and this deranged PoS can continue believing whatever delusions it wants about what constitutes a valid network topology.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.