0

I have a VPN server (strongswan) used for testing that I connect to via IKEv2 on a variety of systems (here, I tried Windows, Ubuntu, & Android), normally without issues. This morning, I was on a train in the UK (a Transpennine Express, which use Icomera.com) and connected to the onboard wifi. This is an IPv4-only network and utilises OpenDNS to block certain sites. Unfortunately, they block stack exchange, so I connected to my VPN to try to bypass these restrictions. It worked fine on some sites, such as news.bbc.co.uk, and some of twitter.com (it allowed access to https://abs.twimg.com at some addresses like /responsive-web/web/runtime.21a6d542388d1e3e4.js and /responsive-web/web/main.d9a47f436e41de1a4.js but blocked others like /responsive-web/web/i18n-rweb/en.10f7da63e9b736204.js and /responsive-web/web/icon-default.3c3b224a61f8b0e54.png). However, other domains did not work at all; google.com and amazon.com for example. What could be stopping certain communication?

ping and traceroute worked on all domains and returned valid IPs (over both v4 and v6, via the VPN - the issues still occurred if I disabled IPv6). Connecting via telnet to sites via port 80 worked, but when I tried wget it would get stuck after a redirect (normally to https, although the below failed redirecting to a http address):

wget -vv -4 google.com
--2019-09-02 08:39:18--  http://google.com/
Resolving google.com (google.com)... 172.217.18.14
Connecting to google.com (google.com)|172.217.18.14|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://www.google.com/ [following]
--2019-09-02 08:39:18--  http://www.google.com/
Resolving www.google.com (www.google.com)... 216.58.205.228
Connecting to www.google.com (www.google.com)|216.58.205.228|:80... connected.
HTTP request sent, awaiting response... ^C

Using adb (Android debug shell, connected to my mobile in case there was a peculiarity with my hardware), I tried the same - it does not have wget and so I used curl, but with the same result:

NB1:/ $ curl google.com
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.
</BODY></HTML>

NB1:/ $ curl https://google.com
curl: (28) Operation timed out after 300191 milliseconds with 0 out of 0 bytes received

If I try to SSH in to the server that the VPN is hosted on (I'm not using the key here), whilst connected to the VPN:

 ssh -v user@1.2.3.4
OpenSSH_7.6p1 Ubuntu-4, OpenSSL 1.0.2n  7 Dec 2017
debug1: Reading configuration data /jkl/ssh_config
debug1: /abc/ssh_config line 19: Applying options for *
debug1: Connecting to 1.2.3.4 [1.2.3.4 port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 1.2.3.4:22 as 'user'
debug1: SSH2_MSG_KEXINIT sent

Then nothing, no timeout or message that it can not be authenticated etc. Another SSH server I have access to connected fine.

The VPN server uses Cloudflare 1.1.1.1 DNS servers. Running the command dig +nocmd +multiline +noall +answer TXT resolver.dnscrypt.info returns the actual resolver it appears that it is using the correct DNS configuration over the VPN:

Attempt 1:

resolver.dnscrypt.info. 10 IN TXT "Resolver IP: 162.158.85.239"

Attempt 2:

resolver.dnscrypt.info. 10 IN TXT "Resolver IP: 162.158.82.32"

Clearly it's not a DNS error as addresses are resolved, and the VPN is connecting and receiving data correctly over multiple ports (at least 22, 25, 80, 443). What could be stopping certain communication here? It's almost like there is some sort of DPI going on, and it seems related to secure communications - certain HTTPS connections, and the above SSH. It isn't a connection issue - I ran a script pinging in the background every second, and when that failed I obviously stopped trying to diagnose the issue.

The only relevant question asking similar I can find is Cisco ASA: Part of the traffic via VPN is blocked785363 here about a Cisco ASA device but that's not causing the issues as they only appear on the network I was connected to. I am assuming it's to do with the OpenDNS setup used but can't figure out how it's working.

Nothing immediate is apparent in the logs of the server in question.

For reference, when not connected to the VPN (and allowing the unsafe certificate) I see this when attempting to access stackoverflow.com in Chrome:

This site is blocked due to content filtering.
stackoverflow.com
Sorry, stackoverflow.com has been blocked by your network administrator.

You can still get FREE movies, TV shows and magazines through our TPE App or at tv.tpexpress.co.uk.

This site was blocked due to the following categories: Forums/Message boards

 Diagnostic Info
ACType
0
Block Type
aup
Bundle ID
640224
Domain Tagging
-
Host
block.opendns.com
IP Address
176.12.107.132
Org ID
2218188
Origin ID
72833478
Prefs
-
Query
url=8485666876808770837177808815688078&ablock&server=lon15&prefs=&tagging=&nref
Server
lon15
Time
2019-09-02 08:48:01.341364541 +0000 UTC m=+5779291.314972467
LTPCGO
  • 508
  • 1
  • 3
  • 15
  • There is a good amount not debugging here. But what is the actual question that someone should answer? – Andy Shinn Sep 03 '19 at 00:48
  • What could be stopping certain communication here? I've clarified it in the post above with bold and a small rewrite. I don't quite understand the first sentence in your comment by the way, do you want me to remove some of the post? I think a lot was superfluous but as I don't have access to the network now I wanted to add as much info as I could whilst I had it in my VM. – LTPCGO Sep 03 '19 at 00:55
  • Sorry, the word "not" is supposed to be "of". The one thing that comes to mind is DNS hijacking where the DNS is not going over the VPN but regular traffic is. This, the special "proxies" IPs returned by DNS do not actually respond properly or at all over the VPN. It might make sense to show IPs for blocked services over the VPN regular (such as at home) and while on the train. – Andy Shinn Sep 03 '19 at 01:22
  • @AndyShinn oh, well...that's good then! I had ruled out DNS issues after I ran a dig command resolving the actual DNS server used, and I've added those to the post. Using DNS-over-HTTPS didn't help either. – LTPCGO Sep 03 '19 at 01:33
  • i would suggest in this case to use 1) a bind (named) installation to cache dns request and 2) i. e. ziproxy as a proxy ibstance due to its installed and configured in less as 5 mins, and set the dns and proxy to the vpn server which listen to a lan ip so that also the proxy is used to rewuest dns quierys fron the Browser – djdomi Sep 03 '19 at 05:39
  • @djdomi you're suggesting I do this locally, correct? It doesn't seem to be a DNS issue given that the addresses in the post do belong to Google, and I saw this issue even when trying to communicate via an IP address – LTPCGO Sep 03 '19 at 07:37
  • nah i mean you said you use oublic dns servers, i seen in the past most service providers, hijacking these to reroute these ips through there own dns, thstd why i suggest to setup a dns server on the vpn server – djdomi Sep 03 '19 at 20:58
  • @djdomi ahh ok; yes I already do something very similar on the server, as some domains are available to VPN users which are not in public DNS records. For others, the names are resolved using Cloudflare. It certainly wasn't using the DNS server provided by the icomera network. – LTPCGO Sep 03 '19 at 21:40
  • yeh but i suggest really to use a dns servee that forward or resolve directly as these ips are not used by public and this also gices the ability to see id the request will be handled fine and also reduce a lot of uneeded traffic – djdomi Sep 03 '19 at 22:10
  • It was not DNS, but MTU, that was the issue – LTPCGO Sep 16 '20 at 12:49

1 Answers1

0

I recently had opportunity to test again the network in question.

The solution here was to do with the MTU. Further analysis of the payload with curl -v showed the handshake failed after the Client hello and no response being seen, even though the VPN server saw this, which made me suspect an issue in the routing.

Looking further, the MTU on the client side was 1500, which typically works fine but in this network configuration failed. The fix was to lower the MTU, and could probably be implemented more reliably on the server side by altering MTU and MSS settings for iptables.

Different domains, with differing lengths, returned different sized payloads which did not cause an issue, hence the inconsistency.

LTPCGO
  • 508
  • 1
  • 3
  • 15