There wouldn’t inherently be anything different between the IP traffic being handled over WiFi and the IP traffic being handled over wired Ethernet through the same gateway.
All of the IP traffic finally ends up going through the NAT on the gateway router, such that only the ISP’s public IP address for your service ends up being the “from” IP address; no matter which WiFi or wired Ethernet computer might have initiated the communication. When a reply comes back, it’s the NAT in your gateway router that knows how to translate that back to the local WiFi or wired Ethernet computer who initiated the request.
So your gateway router can’t really “go crazy” and just put a different “from” IP address on packets from a specific computer. Because if it did that, the responses to those packets would never come back to your gateway router. The responses would try to go to whatever “false” IP address had been used as the “from” address, and since it wasn’t your ISP’s public IP address, none of the Internet would cooperate in routing those packets back towards you or your ISP.
I’ve been trying to think of how having a router feature enabled like “DMZ” might create an unusual scenario, but not even that seems to fit with the symptoms. e.g. If you enabled DMZ for this one computer at some point in the past, because it needed to run a game server or similar which needed to be “outside” of your gateway router’s firewall and other normal protection features in order to operate correctly.
But not even that would “make your IP communication look different to Amazon.” It would just make less protection for this one computer if anything attempted to communicate /inbound/ to your ISP IP address.
Agree the non-managed switch between this computer and the gateway router doesn’t sound like a likely suspect either. I suppose you could rule that out definitively with a long enough Ethernet cable, to temporarily plug the problem computer directly into the gateway router, bypassing the non-managed switch.
I will say it’s a little unusual that you’re observing the tethered test “didn’t show a different IP address.” Typically turning on your hotspot would force the use of cellular data rather than “whatever WiFi the phone is connected to.” So it should have been your cellular carrier-assigned IP address instead of your ISP-assigned IP address. Maybe the USB-based tether didn’t have to behave that way, and simply used the phone’s WiFi?
But in that case, what we’re actually saying is the conclusion you already reached. Which is that WiFi connections would be fine when accessing Amazon, even if you slapped a WiFi adapter into the problem computer to use instead of the Ethernet. Since if your IP address didn’t change during the USB-tethered test, that’s essentially the action you were performing.
Perhaps try disabling the Windows Firewall temporarily as a troubleshooting step? Those rules can be tied to specific interfaces and/or specific classes of networks (“Public”, “Private”, etc.), and maybe there is something only applying to the Ethernet interface on that computer.
Not that there is a rule I can say “would directly cause this behavior.” It’s more along the lines of “Amazon is reporting this VPN message for a situation that is not actually a VPN issue”, because something was blocked and it punted to the wrong message.
Disabling the Windows Firewall temporarily would rule that out if the Ethernet connection still didn’t work with Amazon. Note if you have a third-party firewall installed (Norton 360, etc.) that’s the one you have to disable instead of Windows Firewall.
Please know we are really just guessing at this point, looking for something that exposes more clues.
