Can an ISP cause problems establishing an SMS connection?

BigO1120

What’s up everyone!?!?

I work for a major retail company in the Business Technology department. I provide all kinds of support for our sales force and I’ve been having problems establishing SMS connections from my office to the sales person’s home office. We have an outside DSL connection on site that we use to test out VPN connectivity issue when users send me their laptop.

The problem here is this…

We have about 100 people in our sales force and right now we have 10 reports cases in where we’re not able to establish SMS connection (but there are about 40 other users out there having the same problem). 6 of those reported cases the ISP of those users is AT&T DSL. Our engineers are pinning the cause on the ISP and are asking me to have the users convert to another ISP. I don’t think the ISP is the cause here. One of the laptops in question was here on site and we were not able to establish SMS connection when I had it connected to the outside DSL we have. This particular laptop was a newly imaged laptop so it had an updated version of SMS (no new update is available). I was able to establish connection to the laptop when I had it connected directly to our network via IP and host name.

I checked to make sure that the SMS installation was not corrupted and that there were no issues with our SMS servers. I am still unable to establish connection. Unfortunately our engineers will not do anything else until I have the users switch ISP to rule out the ISP theory.

ANY IDEAS!?!?!?

:

sprkymrk

Are there any errors in the event logs of either the client or server?

BigO1120

sprkymrk wrote:

Are there any errors in the event logs of either the client or server?

None on the server...but unfortunately we can't check the user's logs because the company's policy does not grant users administration rights to access that information. Plus, I'm not giving out my admin credentials to anyone.

sprkymrk

I thought you brought some in for testing. Can you check the logs on those?

sprkymrk

Random thoughts:

Firewall on clients? Firewall on network? What VPN client do you use? Did the problem start recently or has it been ongoing? Is it just the SMS client that won't connect? Can they connect to other resourses through the VPN such as file servers, email, the sysvol share on a DC, etc.?

Paul Boz

I seriously doubt the ISP is blocking sms connectivity. There's no real reason to. The fact that not all of the issues are sourcing from the same ISP should tip you off that it's not an ISP issue. I've never heard of blocking SMS ports.

Here's a comprehensive list of ports which SMS uses.

http://support.microsoft.com/kb/826852

I'd bounce that list off of any configured firewalls and ACL's that may be set up at the branch offices.

mikej412

BigO1120 wrote:

Unfortunately our engineers will not do anything else until I have the users switch ISP to rule out the ISP theory.

I'd consider replacing the engineers first, if that's an option, rather than having 40 (or was it 50 total?) users users jump through a hoop and change ISPs.

sprkymrk

Paul Boz wrote:

I seriously doubt the ISP is blocking sms connectivity. There's no real reason to. The fact that not all of the issues are sourcing from the same ISP should tip you off that it's not an ISP issue. I've never heard of blocking SMS ports.

Here's a comprehensive list of ports which SMS uses.

http://support.microsoft.com/kb/826852

I'd bounce that list off of any configured firewalls and ACL's that may be set up at the branch offices.

I thought of that too, but everything should be tunneled through the VPN anyway - which would make it something like UDP 500 and IP type 50 depending on the VPN client (IPSec, PPTP, etc.). I just wondered if maybe they were using a couple of different VPN clients that don't use the same protocols.

BigO1120

sprkymrk wrote:

I thought you brought some in for testing. Can you check the logs on those?

I had the user go to the office yesterday (in Missouri) and I was able to SMS into her laptop. I logged on with admin rights and checked the logs. No error messages. I spoke with our ENGINEERS again and they're still sticking to their ISP guns! I KNOW for a fact that the ISP is not the cause...just a coincidence that the reported cases have AT&T as the ISP.

Any other ideas? Please!

BigO1120

Well, I just had one of our users change services from DSL to Cable (just to prove our "engineers" wrong) and it turns out that I'm STILL unable to establish a remote connection to the user's laptop.

I notified the engineer who I'm battling but I'm still waiting to hear back from him to see what his answer is. If he tells me to have others convert to Cable I'm going to go to his cube and slap him over the face with his keyboard while I tell him that the ISP is not at fault.

Wish me luck (on the beating)!!!!

BigO1120

OK...after months of dealing with this problem I have YET to find someone who can explain to me why this problem happens!

Another problem I discovered during this time is when I connect to a user by their Computer Name and when I connect to the same user by their IP address I connect to a completely different system. I have the 2nd user refresh their IP configurations and that resolves the problem but I see this happen on a daily basis...why is that? DNS and IP all point to each other.

Ahriakin

If you are using a VPN tunnel (you implied it but did not verify) then the type of traffic inside the tunnel cannot be filtered by the ISP, they never see it, all they see is whatever protocol you are using for the tunnel. Any filters would have to be on the client or your side.
Your DNS server will remember their PC from the last time they registered with it, or the DHCP server did in the case of older clients. When they are offsite and dial in they likely have a completely different address which if assigned by the head end device and it is not registering with the DNS server will lead to these kind of problems.
Get the problematic client to disable their firewall when VPN'd in. If you don't already have it install and then run NMAP against their IP, it will tell you which ports are open, make sure the SMS ports are. If they are not then there is a filter between you and the client. Test with another client on the same VPN head-end, within the same assigned IP subnet and verify the ports show as open. If they do then the problem lies squarely on the client PC. As to what it is, haven't a clue but besides checking the usual firewall options I'd also check that there isn't one enabled on your VPN client software (many include mini stateful firewalls that are easy to miss).

dtlokee

Some other random thoughts:

1. MTU sizes on the clients using DSL, that PPPoE header can get ya.
2. Since SMS uses AD and the Global Catalog servers, what's going on with the client DNS configuration, can they locate a domain controller/global catalog server, or are they using thei ISP DNS server causing it to fail when connecting to the domain.
3. Possibly a delay issue causing it to time out, maybe the round trip latency is too high for SMS and it is failing.

I wouldn't think it has anything to do with the port numbers in use across the Internet, like Ahriakin said, The ISP only sees the port/protocol numbers in use by the VPN tunnel.