Need Workaround for Blocked SMB Port 139

I run a virtual 10.6 OS X server where my clients (Mac and Windows) are distributed outside the server's local network and I want to serve files off the server to my clients. I'd like for them to mount the folder space on their desktop.

I can get my Mac users to connect fine via AFP. WebDAV works too for both Mac and PC. But I can't get the Windows users to connect because my server's internet provider blocks port 139 which is reserved for SMB. VPN won't help because my PC users are outside the server local network...which uses port 139 that is blocked by my provider.

The way I see it, there are two ways for windows users to get access to a Mac OS X Server

1) move my folder structure into the folder that serves WebDAV (/Library/WebServer/Documents) and let my Windows users connect via WebDAV (I'd configure AFP to serve these same folders). However, this means all of my files have to be in this folder. I find it pretty cumbersome to have my entire folder directory buried inside my WebDAV folder.

2) remap my server to provide SMB on another port besides 139. I called Apple Enterprise Support who said this is pretty involved and they won't support it unless I go with a higher-priced service plan.

I'm trying to find an alternative solution such as using another protocol (NFS, AFP for Windows??) that will allow Windows users outside my local network to connect to my server.

Can anything think of an alternative solution?

iMac 24", Mac OS X (10.5.6)

Posted on Jan 21, 2011 12:46 PM

Reply
14 replies

Jan 21, 2011 2:18 PM in response to Tobin Anthony

Hi

Ultimately and for your situation it might be best if you changed your ISP?

Server Mount Block (SMB) uses port 445:

http://www.petri.co.il/whatis_port_445_inw2kxp.htm

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?

http://www.grc.com/port_445.htm
http://www.grc.com/port_139.htm

Port forwarding is achieved in the Firewall/NAT device you're using at your Network's edge.

Tony

Jan 21, 2011 2:45 PM in response to Tobin Anthony

Hi

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:

http://www.softpedia.com/get/Network-Tools/Misc-Networking-Tools/PC-MACLAN.shtml

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?

Tony

Jan 26, 2011 9:43 AM in response to Tobin Anthony

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.

UDP 67,137-138,1433-1434,1719
TCP 67,135,139,1720

Your results will vary, but these are ones I've seen blocked quite a few times.

ProtocolGeek

Jan 26, 2011 12:22 PM in response to Tobin Anthony

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".

Feb 1, 2011 4:48 AM in response to Tobin Anthony

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.

Oct 12, 2011 1:31 PM in response to Tobin Anthony

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?

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

Need Workaround for Blocked SMB Port 139

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.