Some of you may recall that a whilst back I wrote a blog entry (two actually) regarding Vodacom messing with (and breaking) TCP/IP. Specifically they adjust (present tense seeing that it’s still happening) the ISN from the TCP connection initiator (client) to the server, and they hold up RFC 1948 (here) to substantiate why they do this. As explained in my previous entry regarding this issue their reason is bogus and invalid. I additionally proceeded to explain why their inherent disregard for the TCP/IP standards by which the rest of the world abides in fact creates additional exposure for exploiting such vulnerabilities. Whilst my response at the time was quite harshly phrased it remains valid.
This entry is written out of some slight frustration – yet again with Vodacom. We run a PPTP VPN firewall for a (large) number of clients. As of approximately a week ago these clients are having severe issues connecting to the VPN specifically when connecting from the Vodacom 3G network. Also the reason why I went back and re-checked these ISN adjustments that were being made at the time. It seems, however, that they are still making these (justified or not) adjustments. They have now gotten the “systems provider” to fix up the sequence number adjustments inside of selective ACK options inside TCP segments fortunately.
My frustration also grows from the fact that the solutions the Vodacom call center are now giving me are in direct contradiction to what I was being told about a year and a half ago. At the time they said I need to get off the InternetVPN APN and onto the normal Internet APN because it no longer uses private IP addresses and contains full support for VPNs etc etc … … and now I’m being told to revert back to the InternetVPN APN. You try and explain how to do this to 100+ different clients, how and why it’s required and more importantly you consistently get some snotty comment down the lines of “yea yea, you’re just using this as an excuse for breaking this and that”, so explaining to them that it’s Vodacom that changed something (whilst accurate) isn’t really an option as it’s just perceived as instigation against a “company bigger than yourself”. The end result? Vodacom yet again gets away with breaking stuff, and the small guys takes the fall.
The other solution that I’ve been offered is to put the server on the unrestricted APN. Didn’t you listen the first time round? The server ISN’T on 3G for, amongst others, the fact that you’re messing with TCP/IP options, it’s damn expensive at the traffic volumes we’re requiring, not to mention slow in comparison with wired connections such as ADSL (yes I know 7.2Mbps is more than 4Mbps, I don’t care, it’s NOT comparable, be it due to latency, high packet loss or jitter, I’d rather have a 512Kbps ADSL than any kind of 3G connection @ 7.2Mbps).
Anyhow, now I return to figuring out what is causing breakage this time.
*Sigh*… If only all those big boys could be held liable or at the very least accountable in a transparent way so that clients will get off one’s back. I mean, it’s not like you’re _not_ going to spend time and effort on trying to fix the issue or at least find out what is failing. -_-
Complaining about service when they’re getting it… *grumble*
In this particular case they fixed the problem before I could track it down. Which is quite an accomplishment.
Let me tell you a bit about mobile Internet connections. No matter what your provider says, it’s not a real Internet connection (i.e. it is not using TCP/IP). Mobile networks emulate some protocols from the TCP/IP protocol suite, among them TCP, UDP and ICMP. They only do it to a certain degree and in most cases the emulation is not entirely transparent (for example, many providers reduce the quality of JPEG images when browsing Internet web pages to conserve bandwidth). To avoid applications running into timeouts all the time, many signal a successful TCP SYN-SYNACK-ACK handshake even though an end-to-end connection hasn’t been established yet.