VPN over Satellite - Why it doesn't always work at full bandwidth

I came across an interesting situation recently whereby a customer had to move datacentres and had to reconnect their Satellite connected remote sites to connect to a different datacentre using different VPN technologies. Through the move we discovered and interesting situation regarding Satellite and VPN that I thought warranted a quick post.

Some background about Satellite communications...
Satellite communications have inherit limitations in regards to round trip time (RTT) due to the distance packets travel in order to get from source to destination (i.e. propagation delay). RTT of Satellite links are typically above the 500ms mark. Consider what this delay does to network communications. UDP will suffer the RTT delay associated with opening the connection (i.e. handshake) with a back-n-forth of 500ms required for each part of the handshake but after that the performance across these high-RTT links may not be so bad. Once the stream is opened data will quite happily flow until its finished as UDP doesn't care if bits are lost along the way it just sends one after another until its sent everything (i.e. connectionless).

On the other hand consider TCP. It also has to establish a handshake and will require the 500ms delay for each back-n-forth of the setup. However, once the handshake is completed the data stream, compared to UDP, behaves nothing like the UDP stream! It chugs!

TCP is a connection orientated protocol and it will only send the next chunk of data once the last chunk it has sent has been acknowledged and received successfully. Over short-RTT links this isn't such a big deal, we lose a packet and we simply kick it off again and wait for the other end to acknowledge. In standard networks, because the RTT is low, the penalty for doing this is negligible... and life goes on. Over satellite links the delay associated with a lost chunk of data in a TCP stream is very detrimental due to the 500ms per-direction back-n-forth required to restart the chunk that was lost.

To get around the inherit limitations of TCP over Satellite (and make it workable), network boffins came up with some fancy optimization. Satellite providers these days typically provide some sort of TCP/UDP header optimization for their services that buffers packets and tricks the PCs at either end of the Satellite into thinking the network is more responsive than it is or that data can be sent quicker than what the typical RTT back-n-forth would dictate under normal circumstances. This works great provided the optimization technology supports the protocols you're using.... (*ominous fore-shadowing*).

Now what about VPNs? Typical IPSEC VPNs over Satellite behave pretty similar to the vanilla TCP situation described above (i.e poorly) except (you guessed it) the Satellite modems can't optimize the TCP/UDP packet headers tunnels across the VPN. This is because the TCP packet headers are encapsulated and encrypted inside ESP packets (i.e. the modem can't see it's TCP or optimize it). Similar is true for IP Tunnels (i.e. using GRE)!

Overall this results in a lot of frustration and stock-standard VPNs connecting without issue but not forwarding traffic at speeds that non-VPN traffic operates at.

How to configuring VPNs over Satellite links in a way that can be optimized...
So in the wall of text above, we noted that UDP is connectionless, that satellite modems do some form of spoofing to trick TCP/UDP into working fast despite the poor RTT and that VPNs hide the underling TCP/UDP from the modems preventing this optimization! Phew!

A standard VPN uses ESP packets for the tunnel... what if we made it use UDP as the transport instead? On a Cisco router this would be configured using the following (note this is default in newer software)

crypto isakmp nat-traversal  20

The above command points to the fact that NAT traversal suffers from the similar issues.

Hope it helps someone!

ASA - Which serial number to lodge PAKs against

ASAs sometimes show one serial number in the "show version" output and a completely different one in the "show inventory" output. If you are tasked with applying a license to your ASA you will probably ask "which serial number do I use?" The simple answer is; use the "show inventory" serial number.

But what if I've already lodged my license against the wrong serial number? Simply email/contact the licensing team (licensing@cisco.com) and they'll sort it out for you.

Solution for nuisance phone calls from 0198339100 to my mobile

So I've been very annoyed lately. I've been getting phone calls from 0198339100 randomly on my mobile... 24/7. The problem was the service would hang up after one or two rings or would hang up on me even if I answered it. Sometimes I'd answer it in time for it to wait 5 seconds before reading me a text message. This was only happening from a single person. As you can imagine, this is really annoying and I'll be honest... a few swear words were said said over the last few days.

Googling the number reveals it's related to Telstra's Talking Text service. Basically if the phone the SMS was sent to is not SMS capable Telstra convert it into a talking text instead where a robot reads it back to you. The problem is I was receiving these calls on my mobile... which handles SMS perfectly well.... so I was stumped as to why Telstra was sending these through to me. The phone calls and annoyance continued for days.

It took me a while but I figured out what the problem was for me and my situation. I have no doubts someone else will have the same issue so I thought I'd make a post.

My desk phone at work is call-forwarded to mobile... So what was happening was a specific person was innocently sending SMSs to me from his mobile but his mobile had my desk phone listed as my primary contact number. Hence I was getting talking text calls on my desk phone... which forwarded to my mobile 4-5 rings afterwards. By the time they connect through to my mobile they're at the end of the default "wait for answer" period and hang up.

How to properly fix it:

• Get the friend/enemy sending SMSs to your desk number to fix it on his end (i.e. change primary contact number to be your mobile rather than desk phone for your contact on his phone).

How to prevent Talking Text from reaching you on mobile:

• Block the 0198339100 number on your mobile. For my Samsung S6 it was a case of clicking [...] next to number and saying "block". It won't stop the friend/enemy from sending SMSs to the wrong spot but will stop your mobile phone from ringing. NOTE: Your desk phone will still ring!

How to disable Talking Text service:

• Disable the message bank service on your desk phone 

How to prevent the calls from being forwarded to your mobile:

• Disable call-forwarding on your desk phone.

How to make it work (i.e. keep talking texts from desk phone forwarding to mobile without hanging up):

• Increase the "time to wait for answer" by calling 0198339999 from your desk phone and follow the prompts.

There is a bunch of technical information here if you have other requirements/etc.

Hope this helps someone. Good luck!