1

I'm using Linux strongSwan U5.3.5/K4.4.0-116-generic on Ubuntu 16.04 with IOS 11 IKEv2 client.

The connection could be successfully established on my client(IOS 11) and if I go to ip check webpage, e.g. myip.com it shows the VPN server's address.

However, I found that if I connect to a customized port on the same server for HTTPS, it could get blocked by my evil nat firewall even when the IKEv2 is established.

My understanding is that IPSEC will create a tunnel through port 500/4500, and making all traffic encrypted. Therefore I am wondering how will my company or other(nation level) firewall distinguish between different traffic? i.e. drop my https request on a arbitary port.

I tried directly using ip address to access, i.e https://xx.xx.xx.xx:12345, but does not seem make a difference.

My suspect is that this tunnel is not a end-to-end(my iphone to server) tunnel. Because my iphone is behind NAT somehow the connection is not encrypted from my IOS to my company gateway. Is this the reason?

Here is the ipsec.conf conn:

config setup
    cachecrls=yes
    uniqueids=yes
    charondebug=""

conn %default
    keyingtries=%forever
    dpddelay=30s
    dpdtimeout=120s


conn IKEv2-EAP-TLS
    auto=add
    type=tunnel
    keyexchange=ikev2
    dpdaction=clear
    dpddelay=300s
    authby=pubkey
    left=%SERVERIP%
    leftid=%SERVERIP%
    leftsubnet=0.0.0.0/0
    leftcert=vpnSrvCert.der
    leftsendcert=always
    right=%any
    rightid=%any
    rightsourceip=10.10.10.0/24
    rightdns=8.8.8.8,8.8.4.4
    rightauth=eap-tls

[Update] After some trial-and-error, I believe the reason is what BillThor has described. I found that at a no censorship WIFI environment, when I connect to the HTTPS port on the same (IKEv2) server1, it's a seperate TCP link.

On the other hand, when I connected to another L2TP server2(not the HTTPS) from inside censored WIFI, I could successfully connect to the original server1's HTTPS port.

chrisky
  • 23
  • 4
  • I'm confused. Is this your company's IPSec VPN we're talking about, or are you using a third-party IPSec VPN in an attempt to bypass your company's firewall policies? – MadHatter Mar 03 '18 at 07:03
  • No, I'm setting up strongswan IPSEC VPN outside at %SERVERIP% to go through company WIFI which is censored – chrisky Mar 03 '18 at 07:16
  • 2
    I'm voting to close this question as off-topic because we don't help people bypass their corporate IT policy. – MadHatter Mar 03 '18 at 09:03
  • It’s not about corp, i can pass the corp by using LTE, it’s about why this could be detected – chrisky Mar 03 '18 at 09:25
  • I understand your attempts to bypass your corporate wifi restrictions aren't working as you think they should. We're just not prepared to help you diagnose it. See our [help page](https://serverfault.com/help/on-topic): "*If your question ... is not about ... unauthorized use or misuse of IT systems ... then you’re in the right place to ask your question!*". – MadHatter Mar 03 '18 at 09:51

1 Answers1

4

VPN traffic is easily detected by packet inspection, or in this case just by the ports in use. It is quite possible your company is aware of what you are attempting or doing.

If your are trying to reach the same IP address as you are using to connect to the VPN, it will not be sent to the VPN. At a minimum, the address of the VPN server is connected to directly. The VPN may be able route the destination for ports not used by the VPN.

As your right side is in the 10.0.0.0/8 private address space, your IP address will undergo Network Address Translation on your end. This is prone to breakage if multiple devices on the same LAN are connecting to the same remote VPN server.

If you want your browser traffic to always be routed to the VPN, you will need to configure your browser to use a proxy server on an address reachable via the VPN. If your address is showing as your local IP address, it is traversing the VPN.

BillThor
  • 27,737
  • 3
  • 37
  • 69
  • With respect, I'm not sure that's right. IPSec allows tunnels where the remote endpoint is also the remote destination (I use them a lot) and in such cases the traffic is indeed sent encrypted. As for the second para, this tunnel is declared with `leftsubnet=0.0.0.0/0`, which means that all traffic should indeed be sent over the tunnel once it's established. – MadHatter Mar 03 '18 at 07:01
  • I tried to connect to the same %SERVERIP% VPN I setup and connect to a HTTPS page at %SERVERIP%, from home wifi, I do see the tcp session seems to be direct from home IP. Not sure if it's relevant. – chrisky Mar 03 '18 at 07:19
  • @MadHatter In transport mode it would work, but this is in tunnel mode. Only the inside IP addresses get passed over the tunnel. – Michael Hampton Mar 03 '18 at 19:59
  • @MichaelHampton I have tunnel mode setups where `left` and `leftsubnet` are the same address (with a `/32` mask in the latter), and likewise `right` and `rightsubnet`. They seem to work. – MadHatter Mar 04 '18 at 03:23
  • @MadHatter And where `left` and `right` are also the same IP addresses of the machines in question? – Michael Hampton Mar 04 '18 at 03:33
  • @MichaelHampton I'm really sorry, Michael, I'm not sure I understand exactly what you're asking. I have tunnel mode connections where traffic between two traffic endpoints, which are also the IPSec tunnel endpoints, is successfully encrypted. Does that answer your question? – MadHatter Mar 04 '18 at 03:39
  • @MadHatter do you have an example of configuration working for IOS 11 (as indicated by OP)? I wasted couple of hours today trying (and testing various configurations for leftsubnet and attr plugin) to make IOS to run HTTP/S traffic via a proxy on the same machine (same external IP) with the VPN concentrator (AWS EC2, so to save money). – rtybase Jan 04 '19 at 17:15
  • @rtybase this isn't my answer, so even if I had such a config to hand, I couldn't easily add it here. I recommend you ask a new question, laying out your particular case in as much detail as you can, asking what you want to know, and linking to this question to show you've done your homework. – MadHatter Jan 05 '19 at 08:08