Ultimately and for your situation it might be best if you changed your ISP?
Server Mount Block (SMB) uses port 445:
NetBios uses port 139. If you're absolutely certain your ISP is blocking port 139 then they may not be blocking port 445? Although I doubt it?
Port forwarding is achieved in the Firewall/NAT device you're using at your Network's edge.
I seriously doubt if you can do what you want to do? You have to figure out a way to break/hack Microsoft's OS so it does not send requests for file shares on those ports. I hate suggesting this but you could try FTP? Although this is another port that is just as exploited as 139 and 445.
There used to be a product available some years ago called PCMaclan. This installs the AFP Protocol and Service on any PC. I doubt if it will work on Vista let alone Win7? Surprisingly it's still available as a download:
Not sure where you'll get a Serial Number or even Support for it any more as Miramar ceased as a company around 2003-2004?
http://www.firebind.com can help you find a port in the outbound (client to Internet) direction that your ISP is NOT blocking, which is of course the first step to employing some sort of port 139 workaround.
TCP 139 is a very common port to be blocked.
Here are a list of ports that are frequently blocked by ISPs, airport WiFi, hotels, etc.
Your results will vary, but these are ones I've seen blocked quite a few times.
Your reasoning is wrong.
As long as you can establish a working tunnel (usually a VPN) between client (remote) and server (LAN) you can have almost any network traffic going through it.
That is as long as the few UDP/TCP ports and/or maybe some protocol used by the tunnel itself isn't blocked by the ISP or by any firewalls/routers between client and server.
The equipment and software used of course needs to be capable and compatible (usually not too hard to accomplish).
You bypass any blocked ports and keep the traffic "private" (often encrypted) by using a tunnel.
If using PPTP VPN you need working GRE protocol and TCP port 1723 (in some routers VPN-) passthrough/forwarding between client and server. And you can use the built-in VPN client available in most Windows versions to connect to an OS X Server PPTP VPN - as long as server and remote client isn't using an IP the same or overlapping IP "range".
Then you have an other problem.
If you only have one public IP and no NATed "LAN" configured on the server, then you have no use of OS X server built-in VPN (PPTP or L2TP).
The VPN can't make things available through the VPN on the same public IP because that traffic will not go through the tunnel. As the server IP is the tunnel endpoint IP, only other IPs in the VPN routing definitions will go through the tunnel.
You either need more public IPs from your ISP, or you can use a private IP subnet on the server.
More Public IPs: you probably will want to protect with the firewall, enter a second ("alias" interface) IP on the server WAN interface and then use that as the address VPN clients get at server services on.
(VPN clients must of course also get an IP from a range the server "knows about" and that's "attached" to/setup as an IP on an(alias) interface, so you'd need more public IPs for VPN clients too).
Private IP subnet: on the server (stay away from using 192.168.0.0/24 and 192.168.1.0/24 subnets) with or without NAT (preferably with NAT if you want to go through the VPN and then to Internet (VPN setup as the default route when client is connected), especially if using your ISP DNS in the VPN client settings). I belive the "Gateway Assistant" use 192.168.1.1/24 for the server LAN interface - which is bad if VPN users tries to connect from a same numbered subnet.
The server services would be available on the private IP you give the server.
NAT requires the firewall running.
The OSX Server virtual machine is running on what machine? and is bridging used?
Putting the whole thing behind a NAT firewall/router would simplify the server config.
I have a client with Comcast Business 50MB connection with 1 IP (Static) Behind the Comcast router, I have a Sonicwall NSA 240. Behind the Sonicwall, I have a Snow Leopard Xserve (last one they made). Currenty we have SMB and AFP open for immediate access for clients working off-site. We can connect to AFP with no problems...at all. SMB only works from business ISP accounts, no problem with Verizon FIOS (resedential or business) works with not issues. However, Cox and Comcast residential accounts block all SMB ports (139/445).
I tried using VPN which is configured at the OSX level using Server Admin (PPTP). Clients are unable to connect after connecting with VPN. Would this be a limitation of OSX and should I be using the Sonicwall for VPN.
From my location I have a business static IP line from Verizon FIOS, I can connect directly from VPN. I can also access the SMB server by typing the IP/Host name in the run command.
Would it be safe to say that getting the VPN configured on the Sonicwall box may resolve our problem?