Comcast started blocking SMB Port 445 in an VON tunnel…?!
-
Until a couple of months ago, I was able to use OpenVPN on my iPhone to connect through my PFSense router (SG-5100), get inside my network, and then access SMB shares using a utility on my iPhone. The utility, FE File Explorer, uses port 445 for SMB access.
A month or two ago, this stopped working. I thought an update to windows had reset my firewall rules, but that isn’t the case. SMB access from non-Comcast locations still lets me access my SMB shares. If I switch back to my cellular network, I can still access the SMB shares, though not as quickly as I could through Wi-Fi.
Since OpenVPN encrypts all the traffic going through the VPN (Including, I would presume, the port number I’m accessing through VPN), how the heck can they block this? It’s very frustrating…
-
@Draco they aren't - not sure what your issue is, but its not your isp blocking traffic inside a vpn tunnel.
-
@johnpoz yet it only happens on Comcast. And it just started a couple months ago; until then, it wasn’t a problem from anywhere. It works fine from every place else I use it that isn’t Comcast, including Tennessee, Europe and Africa (based on recent experiments).
-
@Draco I would suggest you go over how a vpn works - if the isp could see what is inside the tunnel the whole point of a vpn would be useless..
The only thing your isp could see about data flowing through a vpn is the amount of data and which direction its flowing between the 2 IP endpoints. They can't see what port this traffic is on, they can't see even if its tcp or udp, let alone what port this traffic is on.. All they see is the outside tunnel traffic be that tcp or udp and that outside tunnel port 1194 for example the default openvpn port. Which is encrypted. The isp could block the tunnel traffic completely, ie they could block port 1194.. But they can not see inside the tunnel and block a specific protocol.
-
Most probably you are accessing smb out of tunnel, somehow.
Its the only explanation that makes sense. -
@netblues I would agree with that - but to be honest, smb normally blocked across the internet for years and years and years.. Now might be possible if you were on the same network via the same isp.. But normally 445 is actually blocked at the docsis modem level.. Not up in the isp network.
Sometimes you can get this info from the modem via a snmbwalk/get and see something like this
SnmpMib = docsDevFilterIpDestPortLow.2 445 SnmpMib = docsDevFilterIpDestPortHigh.2 445quite often the community string is just public, etc.
There is lots of info on the internet if you want to say look at yours.. Here is one example
https://www.netscylla.com/blog/2019/02/04/Arris-CableModem-SNMP.html
edit: here is a list from comcast(xfinity) of ports blocked
https://www.xfinity.com/support/articles/list-of-blocked-ports
But these blocks can not happen inside a vpn tunnel - because the isp can not see inside a vpn tunnel
-
@johnpoz This is why I said "somehow"
Its strange it works on other networks and not on the same too.In any case, there is NO way for any provider to know what is inside the tunnel, let alone block it .
(unless of course the tunnel is compromised and we have a perfect mitm situation, but then this is not a cyber spy movie too).
-
@johnpoz I understand it quite well, which is why I am mystified! One source suggested that Comcast was blocking a port before it gets out into the tunnel (along the lines of your note about blocking this at the DOCSIS level), but that’s not possible either. Everything leaving my NIC for the tunnel was already encrypted by the VPN client on my computer. Another source suggested that they might be looking at the pattern of traffic, packet sizes, etc. and determining that it could be SMB.
Another alternative is that I’ve somehow messed up my VPN and nothing is encrypted, which is a frightening prospect to consider, and I lack the equipment to directly test that.
-
@Draco not sure what your running into.. And your correct they couldn't even block it at the docsis level in the modem because as it leaves the nic it would be encrypted.
I see there is a few different scenarios going on.. Either your smb traffic is not running inside your tunnel and then sure the 445 port could be blocked. Even if inside the tunnel and just encapsulated - they still shouldn't be able to block specific traffic inside the encapsulation.
Or you have something else going on be it firewall host not liking the tunnel IP of client talking to the server, or your client isn't sending that smb traffic down the tunnel in the first place. Routing issue say on the client end..
But what is not going on is your isp blocking something actually inside your vpn tunnel.
-
@johnpoz If a request is not going through the VPN tunnel, then there is no SMB server to connect to. The iOS program is using port 445 to talk to internal IP addresses. My firewall would not accept any such packets on the WAN interface (in fact. these requests would never make it to my WAN interface for addresses like 192.168.1.0/8). So it must be going through the WAN tunnel, else it could not arrive. And I can PING these internal addresses.
Believe me, if this was straightforward, I would not have posted!
FWIW I just reviewed my OVPN server config, and my tunnel is definitely encrypted (checked the logs on my iPhone too -- handshake with server is performed with the SSL key on my pfSense, then the protocol options for the tunnel using AES-128-GCM without compression).
The SMB traffic from the client end works just fine for everything except Comcast-originated traffic. My SMB client does not know it is talking outside the Firewall though (even have rules to prevent that, with floating rules specifically allowing it over VPN -- else it would not work for any VPN). It has worked fine for a few years. Just stopped a few months ago. I even push routes to the server side mapping requests for my inside LAN from OpenVPN. Again, if SMB didn't like talking to OVPN then it should not work from any client, since the SMB server has no idea what outside IP the requests come from.
I get it if this also makes no sense to everyone here; it makes no sense to me either! I posted in the hope that someone else might have seen this or have some other ideas on how to fix/work around.
-
@Draco while you have something strange going on.. So your saying client X can do everything via the tunnel, expect 445.
What going to say again for 100% for sure there is no way your isp is blocking traffic inside a tunnel - your following a red herring even thinking such a thing could happen.
If this was the case, vpns would be useless.. And lets put our tin foil hats on for a sec and think - ok the isp does have some backdoor/method/mitm thing where they can see inside a tunnel and control traffic inside the tunnel (to block it).
Why would they show there hand by blocking smb.. I mean if I had a way to peek inside what was going on via a vpn connection that transits my network.. I sure wouldn't let it be known that I could do such a thing.. It would tear down the whole fabric of the internet if such a thing was the case.. This would be NSA level sort of stuff.. They sure and the hell are not going to block traffic to tip their hand.
This is a vpn on the client on the remote side, or a vpn on a router like pfsense where traffic is being routed down a vpn to you?
edit:
If this is using some app on your iphone - I would look to that to maybe causing you your issue. You mention FE explorer, quick look that free version only allows its seems one connection. "Number of Connections (SMB, WebDAV, FTP)" Maybe its making some other connection and causing an issue with the smb unless that other connection is not made or something.But it sure isn't comcast blocking smb in the tunnel that is for sure.
-
@Draco said in Comcast started blocking SMB Port 445 in an VON tunnel…?!:
and I lack the equipment to directly test that.
You can do a packet capture with pfSesnse and use Wireshark to read the packets.
If you see SMB in the traffic you are not encrypted. -
