search

dlenski / openconnect

OpenConnect client extended to support Palo Alto Networks' GlobalProtect VPN
680 stars 130 forks source link

Successfull authentication but no connection on Elementary OS Loki #15

Closed thraxte closed 7 years ago

thraxte commented 7 years ago

Problem description

  1. i've successfully get the connection going but the packets do not reach the destination servers i've used 
sudo openconnect --protocol=gp myhost.com --dump -vvv

i've checked the interface and routes configured correctly, but the ping, traceroute or any type of packed reach the destination

Operating system and openconnect-gp version

openconnect-gp version:

$openconnect --version
OpenConnect version v7.08-1ubuntu5
Using GnuTLS. Features present: PKCS#11, RSA software token, HOTP software token, TOTP software token, Yubikey OATH, System keys, DTLS

operating system:

$ uname -a
Linux Aslan 4.4.0-71-generic #92-Ubuntu SMP Fri Mar 24 12:59:01 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

GlobalProtect VPN information

$ sudo openconnect --protocol=gp myhost.com --dump -vvv
Please enter your username and password.
Username: mmuser
Password: 
POST https://myhost.com/ssl-vpn/login.esp
Attempting to connect to server 201.246.158.230:443
Connected to 201.246.158.230:443
SSL negotiation with myhost.com
Connected to HTTPS on myhost.com
> POST /ssl-vpn/login.esp HTTP/1.1
> Host: myhost.com
> User-Agent: PAN GlobalProtect
> X-Pad: 00000000000000000000000000
> Content-Type: application/x-www-form-urlencoded
> Content-Length: 166
> 
> jnlpReady=jnlpReady&ok=Login&direct=yes&clientVer=4100&prot=https:&server=myhost.com&computer=Aslan&user=mmuser&passwd=mypassword
Got HTTP response: HTTP/1.1 200 OK
Date: Mon, 03 Apr 2017 16:05:27 GMT
Server: PanWeb Server/ - 
ETag: "1fd6a-1dcf-56c4d8d6"
Content-Length: 584
Connection: keep-alive
Keep-Alive: timeout=30, max=19
Pragma: no-cache
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Content-Type: application/xml; charset=UTF-8
Expires: Thu, 19 Nov 1981 08:52:00 GMT
X-FRAME-OPTIONS: DENY
Set-Cookie: PHPSESSID=xxxxx; secure; HttpOnly
Set-Cookie: PHPSESSID=xxxxx; secure; HttpOnly
Set-Cookie: PHPSESSID=xxxxx; secure; HttpOnly
Set-Cookie: PHPSESSID=xxxxx; secure; HttpOnly
Set-Cookie: PHPSESSID=xxxxx; secure; HttpOnly
Set-Cookie: PHPSESSID=xxxxx; secure; HttpOnly
Set-Cookie: PHPSESSID=xxxxx; secure; HttpOnly
Set-Cookie: PHPSESSID=xxxxx; secure; HttpOnly
Set-Cookie: PHPSESSID=xxxxx; secure; HttpOnly
Set-Cookie: PHPSESSID=xxxxx; secure; HttpOnly
Set-Cookie: PHPSESSID=xxxxx; secure; HttpOnly
Set-Cookie: PHPSESSID=xxxxx; secure; HttpOnly
Set-Cookie: PHPSESSID=xxxxx; secure; HttpOnly
Set-Cookie: PHPSESSID=xxxxx; secure; HttpOnly
Set-Cookie: PHPSESSID=xxxxx; secure; HttpOnly
Set-Cookie: PHPSESSID=xxxxx; secure; HttpOnly
HTTP body length:  (584)
< <?xml version="1.0" encoding="utf-8"?><jnlp><application-desc><argument>(null)</argument><argument>xxxxx</argument><argument>xxxxxxx</argument><argument>gateway-N</argument><argument>myuser</argument><argument>A name</argument><argument>vsys1</argument><argument>DOMAIN</argument><argument>(null)</argument><argument></argument><argument></argument><argument></argument><argument>tunnel</argument><argument>-1</argument><argument>4100</argument><argument></argument></application-desc></jnlp>
GlobalProtect login returned authentication source=
POST https://myhost.com/ssl-vpn/getconfig.esp
> POST /ssl-vpn/getconfig.esp HTTP/1.1
> Host: myhost.com
> User-Agent: PAN GlobalProtect
> Cookie: PHPSESSID=xxxxx
> X-Pad: 00000000000
> Content-Type: application/x-www-form-urlencoded
> Content-Length: 245
> 
> client-type=1&protocol-version=p1&app-version=3.0.1-10&os-version=linux-64&clientos=linux-64&hmac-algo=sha1%2cmd5&enc-algo=aes-128-cbc%2caes-256-cbc&authcookie=portal&gateway=gateway-N&user=mmuser&domain=DOMAIN
Got HTTP response: HTTP/1.1 200 OK
Date: Mon, 03 Apr 2017 16:05:27 GMT
Server: PanWeb Server/ - 
ETag: "1fd64-1f2-56c4d8d6"
Content-Length: 2847
Connection: keep-alive
Keep-Alive: timeout=30, max=18
Pragma: no-cache
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Content-Type: application/xml; charset=UTF-8
Expires: Thu, 19 Nov 1981 08:52:00 GMT
X-FRAME-OPTIONS: DENY
HTTP body length:  (2847)
< 
<   <response status="success">
<       <need-tunnel>yes</need-tunnel>
<       <ssl-tunnel-url>/ssl-tunnel-connect.sslvpn</ssl-tunnel-url>
<       <portal>gateway-N</portal>
<       <user>mmuser</user>
<       <lifetime>32400</lifetime>
<       <timeout>7200</timeout>
<       <disconnect-on-idle>3600</disconnect-on-idle>
<       <bw-c2s>1000</bw-c2s>
<       <bw-s2c>1000</bw-s2c>
<       <gw-address>201.246.158.230</gw-address>
<       <ip-address>172.23.61.114</ip-address>
<       <netmask>255.255.255.255</netmask>
<       <dns>
<           <member>172.24.0.222</member>
<           <member>172.24.0.223</member>
<       </dns> 
<       <wins>
<       </wins> 
<       <default-gateway>172.28.69.256</default-gateway>
<       <mtu>0</mtu>
<       <dns-suffix>
<           <member>myhost.com</member>
<       </dns-suffix> 
<       <no-direct-access-to-local-network>no</no-direct-access-to-local-network>
<       <access-routes>
<           <member>192.168.0.0/16</member>
<           <member>172.31.0.0/16</member>
<       </access-routes> 
<       <ipsec>
<           <udp-port>4501</udp-port>
<           <ipsec-mode>esp-tunnel</ipsec-mode>
<           <enc-algo>aes-128-cbc</enc-algo>
<           <hmac-algo>sha1</hmac-algo>
<           <c2s-spi>0x59567F16</c2s-spi>
<           <s2c-spi>0x6F66ED52</s2c-spi>
<           <akey-s2c>
<               <bits>160</bits>
<               <val>xxxxx</val>
<           </akey-s2c> 
<           <ekey-s2c>
<               <bits>128</bits>
<               <val>xxxxx</val>
<           </ekey-s2c> 
<           <akey-c2s>
<               <bits>160</bits>
<               <val>xxxxxx</val>
<           </akey-c2s> 
<           <ekey-c2s>
<               <bits>128</bits>
<               <val>xxxxxx</val>
<           </ekey-c2s> 
<       </ipsec> 
<   </response>
TCP_INFO rcv mss 1460, snd mss 1460, adv mss 1460, pmtu 1500
No MTU received. Calculated 1410
Parameters for incoming ESP: SPI 0x6f66ed52
ESP encryption type AES-128-CBC (RFC3602) key 
ESP authentication type HMAC-SHA-1-96 (RFC2404) key 
Parameters for outgoing ESP: SPI 0x59567f16
ESP encryption type AES-128-CBC (RFC3602) key 
ESP authentication type HMAC-SHA-1-96 (RFC2404) key 
Send ESP probes
Connected as 172.23.61.114, using SSL
Received ESP packet of 84 bytes
ESP session established with server
Received ESP packet of 84 bytes
Received ESP packet of 84 bytes
ESP tunnel connected; exiting HTTPS mainloop.
Sent ESP packet of 100 bytes
Sent ESP packet of 116 bytes
Sent ESP packet of 116 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 116 bytes
Sent ESP packet of 116 bytes
No work to do; sleeping for 10000 ms...
No work to do; sleeping for 10000 ms...
No work to do; sleeping for 10000 ms...
No work to do; sleeping for 10000 ms...
No work to do; sleeping for 10000 ms...
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
No work to do; sleeping for 10000 ms...
Received ESP packet of 148 bytes
Sent ESP packet of 180 bytes
No work to do; sleeping for 10000 ms...
Received ESP packet of 132 bytes
Sent ESP packet of 164 bytes
No work to do; sleeping for 10000 ms...
Received ESP packet of 132 bytes
Received ESP packet of 164 bytes
Sent ESP packet of 164 bytes
Sent ESP packet of 196 bytes
No work to do; sleeping for 10000 ms...
Received ESP packet of 132 bytes
Sent ESP packet of 164 bytes
No work to do; sleeping for 10000 ms...
Received ESP packet of 148 bytes
Sent ESP packet of 180 bytes
No work to do; sleeping for 10000 ms...
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
No work to do; sleeping for 6000 ms...
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
No work to do; sleeping for 6000 ms...
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
No work to do; sleeping for 1000 ms...
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
No work to do; sleeping for 1000 ms...
Send ESP probes for DPD
No work to do; sleeping for 5000 ms...
Received ESP packet of 84 bytes
No work to do; sleeping for 10000 ms...
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
No work to do; sleeping for 7000 ms...
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
No work to do; sleeping for 7000 ms...
Received ESP packet of 100 bytes
Received ESP packet of 100 bytes
Sent ESP packet of 132 bytes
Sent ESP packet of 132 bytes
No work to do; sleeping for 10000 ms...
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
No work to do; sleeping for 9000 ms...
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
No work to do; sleeping for 9000 ms...
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
Sent ESP packet of 100 bytes
No work to do; sleeping for 4000 ms...
No work to do; sleeping for 4000 ms...
Send ESP probes for DPD
No work to do; sleeping for 5000 ms...
Received ESP packet of 84 bytes
No work to do; sleeping for 10000 ms...
^CPOST https://accesoremoto.claro.com.sv/ssl-vpn/logout.esp
SSL negotiation with accesoremoto.claro.com.sv
Connected to HTTPS on accesoremoto.claro.com.sv
> POST /ssl-vpn/logout.esp HTTP/1.1
> Host: accesoremoto.claro.com.sv
> User-Agent: PAN GlobalProtect
> Cookie: PHPSESSID=xxxxx
> X-Pad: 00000000000000000
> Content-Type: application/x-www-form-urlencoded
> Content-Length: 111
> 
> computer=Aslan&authcookie=xxxxxx&portal=gateway-com-N&user=mmuser&domain=DOMAIN
Got HTTP response: HTTP/1.1 200 OK
Date: Mon, 03 Apr 2017 16:06:22 GMT
Server: PanWeb Server/ - 
ETag: "1fd6b-251-56c4d8d6"
Content-Length: 159
Connection: keep-alive
Keep-Alive: timeout=30, max=19
Pragma: no-cache
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Content-Type: application/xml; charset=UTF-8
Expires: Thu, 19 Nov 1981 08:52:00 GMT
X-FRAME-OPTIONS: DENY
HTTP body length:  (159)
< 
<   <response status="success">
<       <portal>gateway-N</portal>
<       <domain>MYDOMAIN</domain>
<       <user>mmuser</user>
<       <computer>Aslan</computer>
<   </response>
Logout successful
RTNETLINK answers: No such process
RTNETLINK answers: No such process
User canceled (SIGINT); exiting;
$
dlenski commented 7 years ago

Hmmm… looks like everything is fine, except that your VPN's routing configuration is quite strange.

The routes enabled for the VPN are…

        <access-routes>
            <member>192.168.0.0/16</member>
            <member>172.31.0.0/16</member>
        </access-routes>

But all the VPN-internal addresses I can see in your debug log are not in either of these routes: DNS servers are in 172.24.0.0/16, and the VPN-internal IP address is in 172.23.0.0/16. How about the addresses of the hosts you're trying to connect to? Are those also not in the routes specified in the config?

Try this: after connecting with openconnect, run this to route the entire 20-bit block IPv4 private address space over the VPN.

$ sudo ip route add 172.16.0.0/12 dev tun0

After doing that… can you contact the hosts you're trying to connect to? If so, the problem is with the server-side configuration of the VPN.

thraxte commented 7 years ago

Hi.

Thanks for your comments.

The routes are there, i just removed them as there are also some public ips on those routes.

The host i'm trying to reach is 17.17.72.XX which is part of those segments, but i've also tested some other ip's which I know can be reached with the windows client but no luck here.

I've also tried inserting the new route as you suggested, but no luck either.

See a more complete route list here.

<       <access-routes>
<           <member>192.168.0.0/16</member>
<           <member>172.31.0.0/16</member>
<           <member>172.28.0.0/16</member>
<           <member>172.26.0.0/16</member>
<           <member>172.25.215.0/24</member>
<           <member>172.25.213.0/24</member>
<           <member>172.25.212.0/24</member>
<           <member>172.24.0.0/16</member>
<           <member>172.23.0.0/16</member>
<           <member>172.22.0.0/16</member>
<           <member>172.20.0.0/16</member>
<           <member>172.18.0.0/16</member>
<           <member>172.17.0.0/16</member>
<           <member>172.16.0.0/16</member>
<           <member>10.254.5.0/24</member>
<           <member>10.200.5.0/24</member>
<           <member>10.15.1.18/32</member>
<           <member>10.6.0.20/32</member>
<           <member>172.31.3.0/24</member>
<           <member>10.6.0.0/24</member>
<           <member>10.196.52.0/24</member>
<           <member>10.95.70.0/24</member>
<           <member>10.95.61.0/24</member>
<           <member>10.144.85.0/24</member>
<           <member>10.146.33.0/24</member>
<           <member>172.25.0.0/16</member>
<           <member>172.28.10.0/24</member>
<           <member>10.118.1.0/24</member>
<           <member>172.24.0.222/32</member>
<           <member>172.24.0.223/32</member>

also the routes are configured system-wide

$ route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.43.1    0.0.0.0         UG    600    0        0 wlp3s0
10.6.0.0        *               255.255.255.0   U     0      0        0 tun0
10.6.0.20       *               255.255.255.255 UH    0      0        0 tun0
10.15.1.18      *               255.255.255.255 UH    0      0        0 tun0
10.95.61.0      *               255.255.255.0   U     0      0        0 tun0
10.95.70.0      *               255.255.255.0   U     0      0        0 tun0
10.118.1.0      *               255.255.255.0   U     0      0        0 tun0
10.144.85.0     *               255.255.255.0   U     0      0        0 tun0
10.146.33.0     *               255.255.255.0   U     0      0        0 tun0
10.196.52.0     *               255.255.255.0   U     0      0        0 tun0
10.200.5.0      *               255.255.255.0   U     0      0        0 tun0
10.254.5.0      *               255.255.255.0   U     0      0        0 tun0
172.16.0.0      *               255.255.0.0     U     0      0        0 tun0
172.17.0.0      *               255.255.0.0     U     0      0        0 tun0
172.18.0.0      *               255.255.0.0     U     0      0        0 tun0
172.20.0.0      *               255.255.0.0     U     0      0        0 tun0
172.22.0.0      *               255.255.0.0     U     0      0        0 tun0
172.23.0.0      *               255.255.0.0     U     0      0        0 tun0
172.23.61.112   *               255.255.255.255 UH    0      0        0 tun0
172.24.0.0      *               255.255.0.0     U     0      0        0 tun0
172.25.0.0      *               255.255.0.0     U     0      0        0 tun0
172.25.212.0    *               255.255.255.0   U     0      0        0 tun0
172.25.213.0    *               255.255.255.0   U     0      0        0 tun0
172.25.215.0    *               255.255.255.0   U     0      0        0 tun0
172.26.0.0      *               255.255.0.0     U     0      0        0 tun0
172.28.0.0      *               255.255.0.0     U     0      0        0 tun0
172.28.10.0     *               255.255.255.0   U     0      0        0 tun0
172.31.0.0      *               255.255.0.0     U     0      0        0 tun0
172.31.3.0      *               255.255.255.0   U     0      0        0 tun0
192.168.0.0     *               255.255.0.0     U     0      0        0 tun0
192.168.43.0    *               255.255.255.0   U     600    0        0 wlp3s0
dlenski commented 7 years ago

Okay, I just noticed another unusual detail in your VPN's config:

        <gw-address>201.246.158.230</gw-address> <!-- external VPN gateway -->
        <ip-address>172.23.61.114</ip-address> <!-- your computer's VPN-internal IP address -->
        <default-gateway>172.28.69.256</default-gateway> <!-- normally the *same* as IP address -->

172.28.69.256 doesn't make any sense. .256 is not a valid IP address.

Furthermore, it doesn't really make sense for a peer-to-peer VPN (GlobalProtect or otherwise) to tell the client to use a default gateway isn't the same as the IP address. (The original openconnect authors apparently agree that this is weird or meaningless.)

So… two questions for you:

  1. Is your VPN really sending this bizarre config? Or did you obfuscate it, and the <default-gateway> is actually the same as the <ip-address>?
  2. When you connect under Windows, does your computer get a predictable, repeatable IP address from the VPN… and if so, is that predictable, repeatable address the same as the one you're getting with openconnect?
dlenski commented 7 years ago

Also, given that the routing configuration here is unclear, it'd be helpful to save the routing configuration with this VPN under Windows (use route print) so we can see what the official GlobalProtect client is doing with these settings.

thraxte commented 7 years ago

Sorry for the delay.

The default gw really is the same ip addres. My mistake when cleaning the sensitive information. I´ve attached logs and routes taken from the windows client.

windows routes.txt vpn log.txt

I´m suspecting this might be a issue between openconnect and ElementaryOS. I´ve tryed to connect to a juniper endpoint which gest successfully conected, but no packets are sent or received on that case.

dlenski commented 7 years ago

Okay. So no VPN clients are working on the Linux side? Do you have some overly-aggressive firewall or IP-filter running? You should check that sudo tcpdump -v -i tun0 shows packets going to/from the tunnel interface when you try to ping hosts inside the VPN. If not, then packets are getting dropped before they make it to openconnect.

Assuming that's not the case, the Windows log shows that you are getting a persistent IP address of 172.18.62.19.

It's possible that there is some special mechanism by which your VPN doesn't work unless you request this specific address. I've seen a couple reports of this before.

Try this to do a 2-phase connection. First login and get the authentication cookie:

$ eval $(openconnect --prot=gp --authenticate vpn-address.com)
Please enter your username and password
Username: 
Password:

Check that the environment variables got set as expected:

$ env | egrep 'COOKIE|HOST|FINGERPRINT'
COOKIE='authcookie=deadbeefdeadbeef&portal=PORTAL&user=USERNAME&domain=DOMAIN'
HOST='gateway.ip.address'
FINGERPRINT='sha256:...'

Now we'll append &preferred-ip=172.18.62.19 to the cookie, telling the server that you want your normal "reserved" IP address, and do the second connection phase:

$ openconnect --prot=gp "$HOST" -C "${COOKIE}&preferred-ip=172.18.62.19"
...

Does the network connectivity work when you do this?

thraxte commented 7 years ago

Hi. I don't have any firewall/ip filter running. I've checked and the packets are being sent to the tun0 interface.

I've done the test the way you suggested but the results are the same.


$ ping 172.17.72.201
PING 172.17.72.201 (172.17.72.201) 56(84) bytes of data.
^C
--- 172.17.72.201 ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 7054ms

$ ifconfig -a
enp2s0    Link encap:Ethernet  HWaddr c4:2c:03:32:6d:e6  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:16 

eth0      Link encap:Ethernet  HWaddr 4a:d7:05:73:02:5e  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:998 errors:0 dropped:0 overruns:0 frame:0
          TX packets:998 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1 
          RX bytes:100685 (100.6 KB)  TX bytes:100685 (100.6 KB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:172.23.62.204  P-t-P:172.23.62.204  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1410  Metric:1
          RX packets:26 errors:0 dropped:0 overruns:0 frame:0
          TX packets:52 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:4072 (4.0 KB)  TX bytes:4719 (4.7 KB)

wlp3s0    Link encap:Ethernet  HWaddr 60:33:4b:1c:dc:70  
          inet addr:192.168.43.141  Bcast:192.168.43.255  Mask:255.255.255.0
          inet6 addr: fe80::4efb:b15f:99b1:9e6a/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6402 errors:0 dropped:0 overruns:0 frame:54385
          TX packets:5718 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:4986992 (4.9 MB)  TX bytes:991947 (991.9 KB)
          Interrupt:17 
sh
dlenski commented 7 years ago

I don't have any firewall/ip filter running. I've checked and the packets are being sent to the tun0 interface.

Okay, so it seems that packets are getting sent to the tun0 interface, and to the VPN gateway over the public Internet. But the only packets that are received from the VPN gateway are keepalive packets.

I've done the test the way you suggested but the results are the same.

I'm running out of ideas here, but a few things to try…

Beyond that I'm out of ideas… you'd need to run mitmproxy to log the connection from a Windows system and see how it differs from the way I think it works.

0atman commented 7 years ago

Getting a very similar "good connection but no data" on ubuntu, here's my log vpnlog.md.txt

0atman commented 7 years ago

--no-dtld doesn't work for me

POST https://[gateway]/ssl-vpn/login.esp
GlobalProtect login returned authentication source=RADIUS Authentication
POST https://[gateway]/ssl-vpn/getconfig.esp
No MTU received. Calculated 1410
Set up DTLS failed; using SSL instead
Connected as 10.211.167.12, using SSL
GPST Dead Peer Detection detected dead peer!
POST https://[gateway]/ssl-vpn/getconfig.esp
SSL negotiation with [gateway]
Server certificate verify failed: signer not found
Connected to HTTPS on 63.137.86.165
No MTU received. Calculated 1410
Failed to connect ESP tunnel; using HTTPS instead.
^CPOST https://[gateway]/ssl-vpn/logout.esp
SSL negotiation with [gateway]
Server certificate verify failed: signer not found
Connected to HTTPS on [gateway]

loop

dlenski commented 7 years ago

I'm afraid that I have no further insight into what's wrong with these connections. OpenConnect is doing exactly what the GP protocol expects it to do, based on my knowledge of it.

Do either of you know how to run mitmproxy to log the Windows connection to figure out what the official client is doing differently?

I have a couple small helper scripts for mitm'ing the GP VPN which I'll share if so …

dlenski commented 7 years ago

@0atman, this is very weird: in your ESP mode log, at least the keepalive/ping packets are successfully transmitted, but in HTTPS-only mode (--no-dtls) the keepalive packets aren't getting through.

That's a puzzling inconsistency. If you can run the get-portal-config.py script, what version is the GP server software reporting?

0atman commented 7 years ago

Found the problem: The network I was connecting over was heavily filtered. Over the normal Internet it works great! Thank you so much for your help! Now, to persuade IT to officially bless this...!

dlenski commented 7 years ago

Found the problem: The network I was connecting over was heavily filtered. Over the normal Internet it works great! Thank you so much for your help!

Huh… your original logs showed:

  1. ESP probe (ping) packets worked, even though others apparently didn't:
Parameters for incoming ESP: SPI 0x309d4974
ESP encryption type AES-128-CBC (RFC3602) key 0xf5bed1a32c727cbb2b1b897d0d4f7bba
ESP authentication type HMAC-SHA-1-96 (RFC2404) key 0x9422f7f8233bfed9175ea84681a2e84e648ac560
Parameters for outgoing ESP: SPI 0x6a198c3a
ESP encryption type AES-128-CBC (RFC3602) key 0x5ac8008a4db7dc073c14fc5a231407bd
ESP authentication type HMAC-SHA-1-96 (RFC2404) key 0x03eee97daa9c706e824707e4586c07614cac101e
Send ESP probes
Connected as 10.211.167.10, using SSL
No work to do; sleeping for 5000 ms...
Received ESP packet of 84 bytes
ESP session established with server
Received ESP packet of 84 bytes
Received ESP packet of 84 bytes
ESP tunnel connected; exiting HTTPS mainloop.

[about 10 seconds of trying to connect to stuff]
  1. HTTPS setup transactions worked (obviously), but HTTPS tunnel didn't work.

I have no idea what kind of network filtering would cause these symptoms!!

Now, to persuade IT to officially bless this...!

Good luck, but lack of support from IT is the reason I created this in the first place. OpenConnect is supposed to behave in a way that's indistinguishable from the "official" client(s), so that IT can't not support it :angry:

0atman commented 7 years ago

lack of support from IT is the reason I created this in the first place. OpenConnect is supposed to behave in a way that's indistinguishable from the "official" client(s), so that IT can't not support it

The word "Hero" is thrown about a lot these days, but it is correct in this instance :-D

dlenski commented 7 years ago

@thraxte, are you still having a problem here? Did --no-dtls fix anything?

peshoicov commented 7 years ago

I had a similar issue - connected successfully and had internet connection, but then I was unable to reach our internal services like JIRA, Jenkins or Git. Running the client with --no-dtls fixed the issue :)