IPSEC IKEv2 не скрывает HTTPS

Я использую Linux strongSwan U5.3.5 / K4.4.0-116-generic в Ubuntu 16.04 с клиентом IOS 11 IKEv2.

Соединение могло быть успешно установлено на моем клиенте (IOS 11), и если я перейду на веб-страницу проверки ip, например myip.com показывает адрес VPN-сервера.

Однако я обнаружил, что если я подключаюсь к настроенному порту на том же сервере для HTTPS, он может быть заблокирован моим злым брандмауэром nat, даже если установлен IKEv2.

Я понимаю, что IPSEC создаст туннель через порт 500/4500 и сделает весь трафик зашифрованным. Поэтому мне интересно, как моя компания или другой (национальный) брандмауэр будет различать разный трафик? то есть отбросить мой https-запрос на произвольный порт.

Я пробовал напрямую использовать IP-адрес для доступа, т.е. https: //xx.xx.xx.xx: 12345, но, похоже, это не имеет значения.

Я подозреваю, что этот туннель не является сквозным туннелем (от моего iphone к серверу). Поскольку мой iphone каким-то образом находится за NAT, соединение между IOS и шлюзом моей компании не шифруется. Это причина?

Вот соединение ipsec.conf:

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

[Обновление] После некоторых проб и ошибок, я считаю, что причина в том, что описал BillThor. Я обнаружил, что в среде WIFI без цензуры, когда я подключаюсь к порту HTTPS на том же (IKEv2) сервере1, это отдельная ссылка TCP.

С другой стороны, когда я подключился к другому L2TP-серверу2 (не HTTPS) изнутри цензурированного Wi-Fi, я смог успешно подключиться к исходному HTTPS-порту server1.