I find myself wanting to make a lot of suggestions that are probably just general blind troubleshooting, and not so much based on the actual symptoms you're experiencing. There is still some good that can come of systematically excluding even remote possibilities, such as turning off firewalls, antivirus, LAN driver updates, etc.; even though the symptoms don't exactly match. If anything it'll reassure about what isn't the problem. That being said, some of these suggestions don't fit the symptoms, but I can't imagine what does offhand.
Let me try to understand the symptoms out loud here....
Your windows Host (laptop) can connect to the Internet, ping external IPs, ping the guest IP, ping other LAN devices, and resolve hostnames.
[ping 8.8.8.8, ping 192.168.?.?, nslookup www.google.com]
Your linux guest set to use NAT cannot load a website or ping external IPs..but it can connect to any other VM running on the host with ping, ssh, and therefore presumably any other sort of connection directly, without using NAT. It can also connect to other devices on the LAN, that don't include the host and other VMs on the host, by using NAT. Whether or not it resolves hostnames might depend on if you're using google's DNS (external WAN) or if the gateway acts as a DNS (Internal LAN) because you said you could not ping 8.8.8.8 but you can ping other LAN devices, which presumably would include the gateway/router.
So the host has full connectivity. It's gotten it's IP from the gateway/router. It can ping everything. It's performing NAT. The guest is utilizing NAT. The guest can communicate freely with the host and other VMs on one subnet without using NAT, and it can communicate on the LAN with other local devices using NAT. The guest can resolve external hostnames with DNS?? (check if you haven't with nslookup).
The only part where something really doesn't work is when the guest tries to access something on the external/WAN network? You noticed the problem, or the problem occured, after you moved a VM from Workstation to Player on a different PC. I have personally never converted a VM or opened it with a different program with the exception of installing "Windows XP Mode" in VMWare player, I don't know what's invloved or what can go wrong. I would assume the files are very similar, but I would also assume the options available in the .vmx file might differ slightly.
OK here's a flurry of dumb ideas that don't fit the symptoms...but might be worth eliminating from the problem...
Disable any proxies or proxy auto configuration on the guest and host. Set to "none"
Make sure your linux guest isn't a misconfigured DNS server. Look for Bind probably.
Reset the router/gateway or reset specific options to fully release any hold on IPs, MAC, or hostnames.
You might be onto something with the router remembering old mac addresses. I have a AT&T Uverse gateway that remembers mac, hostname, and assigned the same IP to that device every time with DHCP. I have at times setup a new VM to take over the role of an older one, but thought it easier to reuse the same statically assigned IP address to keep things simple. The gateway wouldn't let me statically assign the IP address because it still had it assigned to an invisible device that also had port forwards assigned. This gateway has an option to clear the device list that works wonders when the weird stuff starts happening. Also when I create port forwards on the router, it's done using hostnames rather than by IP. So when forwarding rules are enabled for a particular MAC, IP, or hostname...getting that MAC, IP, or hostname to release is impossible unless I also remove those forwards. These are also things that powercycling the router would not affect, it would boot right back up with the same list of devices and same forwarding rules.
Disable all software firewalls
To disable the host firewall in windows 7, control panel / windows firewall, then click the link to "turn windows firewall on or off". It shouldn't be contributing to the problems you're having, but reducing the number hoops you're jumping through while testing will at the very least rule out some things. As for linux, I think firewalls tend to be off to begin with, but SELinux with some distros is on to begin with. In either case try to disable both to test.
Punch a Kitten.
No one ever suspects the kitten.
Restart vmware NAT service.
To restart the vmware NAT service, go to control panel/administrative tools/services, then scroll down to "vmware NAT service" and right-click on it and "restart". Frankly, rebooting should do the same thing I imagine, so I'm not sure how well this works. This seemed to apply more to people that had intermittent problems that needed a quick way to reset it.
Make sure no active antivirus or network shields are running of any kind.
These things can really be a wildcard sometimes when you mix frequent cutting edge updates with heuristics and it all the sudden decides to block something random.
Try a clean test install.
Last I checked, when you create a fresh new linux VM, the default configuration is NAT. Without changing a thing from defaults, you should immediately have Internet access. Even if you don't perform a disk install, and instead just boot from a live cd/dvd ISO, you should have NAT connection immediately. Since some of the settings for vmware networking devices are global and apply to all VMs using that connection, this should give you some indication whether it's a problem unique to that one VM or if it's a more general problem with VMWare settings.
Clean test install an alternate distro.
Perhaps try an alternate distro too if you feel brave. I can't recall which one you said you used. If it's fedora, it's got SELinux probably..which is just another complicated layer on your onion. I can't say I ever made sense of it. It probably can't get much easier than any of the Ubuntu varieties...I like Kubuntu myself.
Reinstall/Update VMWare Player.
Reinstall VMWare Tools on the guest.
Update/Reinstall the hosts network drivers.
Disable the VMnet0 (bridged) and VMnet1 (host-only) adapters on the host if you plan to not use them. I've found they can really slow things down in general just by being there.
Uninstall other Virtualization software, ie: Virtualbox, MS Virtual Machine OR make sure you disable their devices/protocols for you hosts LAN connection. Each installs it's own bridged networking protocol, and I've found they do not always play nice together. Try to eliminate any possibility of conflict and disable any unnecessary network components for your host LAN adapter, including QoS and IPv6 if your hardware or ISP don't support them.
Check the hosts network settings to see if it's set for public, home, or work network. For testing purposes, try work network. Change it to public when you're back on a public network.
Make sure c:\windows\system32\drivers\etc\hosts and \etc\hosts are pretty much in their original default state, and free of customizations you might be unaware of.
I've seen some windows security software go nuts using the hosts file as a blacklist for shadey hostnames. I've also seen malware use them to redirect to shadey websites. It can't hurt to look. The hosts file is a bit of an odd duck on widows because it doesn't have an extension. Using notepad to edit the hosts file used to be tricky because it insisted on saving the file with an extension or not at all, I'm fairly sure this is not longer a problem..but I wanted to mention it just in case.
Make certain the host isn't infected.
We can't go blaming everyting that goes wrong in the world on a virus...but it does happen often enough that when nothing else makes sense...it's worth really checking into. Some malware can hide well and do strange things with networking. Some act as their own proxy and DNS. Check for rootkits and bootkits. Bootkits are great at hiding because they take over the hard drives Master Boot Record (MBR), boot before windows, and run outside of windows entirely. Kaspersky makes a nice lightweight bootkit scanner called tdsskiller.exe. I'm a also big fan of Avast and Malwarebytes Anti-Malware. Avast seems to have a rootkit/bootkit scanner as well here.
Make sure windows is up to date.
99% of the time you can't go wrong here. This can also be another test of the suggestion above, as many viruses will block access to windows update. You can skip "recommended updates" and just focus on the critical stuff. These days windows scolds you if you don't have auto updates enabled, so the chances you've neglected this are slim..but worth mentioning.
Finally out of dumb ideas. Since you mentioned that you're not very familiar with windows networking, I'll leave you with a short list of windows networking commands that may or may not help your troubleshooting somehow. Ping of course, pathping, tracert, netstat, nbtstat, ipconfig (much like ifconfig in linux), and nslookup. Linux I'm not as familiar with but I know of ping, nslookup, and ifconfig.
On a pretty unrelated note....if you're concerned with wireless security and coffee shop weirdos sniffing your packets, and since you're already familiar with ssh...take a look at http://en.wikipedia.org/wiki/Tunneling_protocol#Secure_shell_tunneling. You could setup a proxy back at home to establish an encrypted tunnel connection to over a public network using the laptop, and use it's presumably safer internet connection. This is the best diagram ever.