On Thu, Mar 21, 2019 at 6:44 PM David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote: > > On Thu, 2019-03-21 at 00:13 +0000, Phillips, Tony wrote: > > More info. One of my coworkers and I did some more diagnostics this > > afternoon: > > > > He used iperf3 to do some generic benchmarking today, and we poked > > around in some tcpdumps taken during 1MB iperf pushes. > > > > When sending TCP traffic from the open connect client VM to the > > target (an ordinary RHEL VM, recall that the VPN is terminated on a > > hardware Palo Alto along the way) we observe an average of about > > 2.7MB/sec with around 10% of packets getting retransmitted according > > to both iperf and netstat -s. The first packet that gets > > retransmitted after the TCP socket is opened has relative sequence > > number 4142 consistently... as in every time we tried (at least four > > separate runs during an hour or so). > > > > When going in the other direction, we get 36MB/sec with about 0.3% of > > packets getting retransmitted. We didn’t do as much poking in these > > dumps these since they performed 10x-15x faster, but I would hazard a > > bet that in these cases, it’s the ACKs that are getting lost dropped. > > > > This definitely hints (if not shouts) at a send buffer overflow on > > the VPN side. Do I have this right? High packet loss from client→VPN, low packet loss from VPN→client? If so, I'm guessing your problems are MTU-related. The GlobalProtect gateways seem to lack any ability to inform the client about either (a) the MTU of the VPN internal network or (b) the gateway's best guest of the PMTU between the client and the gateway… at least there's no mechanism that I was able to discern while developing the GP support in OpenConnect. The gateways actually send an MTU field in the client configuration response (https://gitlab.com/openconnect/openconnect/blob/v8.02/gpst.c#L622) but it is *always zero* on real PA servers. 👎👎👎 Currently, OpenConnect just makes a guess based on the TCP path-MTU between the client and VPN gateway: https://gitlab.com/openconnect/openconnect/blob/v8.02/gpst.c#L322-403 Try using `--mtu` to set a smaller MTU than whatever is being guessed, and see if that improves the client-to-VPN (upstream) throughput. The better way to handle this would probably be to do a binary search like what OpenConnect already does for DTLS (https://gitlab.com/openconnect/openconnect/blob/v8.02/dtls.c#L515-625). Dan _______________________________________________ openconnect-devel mailing list openconnect-devel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/openconnect-devel
