On Wed, Apr 10, 2019 at 5:22 PM David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote: > > On Wed, 2019-04-10 at 17:01 +0300, Daniel Lenski wrote: > > Quick recap: > > 1. GPST uses special ping packets with a "magic payload" to enable and > > keepalive the ESP connection. > > 2. The ping packets are (usually) addressed to the *external* address > > of the VPN gateway, but they always travel over the VPN tunnel, *NOT* > > the default route between client and gateway. > > 3. As I've stated many times before, DON'T BLAME ME, I DIDN'T DESIGN > > THIS :-P: https://github.com/dlenski/openconnect/blob/master/gpst.c#L1210-L1226 > > :) > > Yes, in my nasty "paste this into openssl s_server to pretend to be a > GPST server" hack I include the *internal* address of the server as the > gateway address for the magic ping. Ahhhhhh… sure, that makes sense. > Because I don't think my server > (which is just Linux with XFRM-configured ESP) would respond as we > want, to its public address. Right, no sane server would respond in that way. I don't even want to know how GlobalProtect mangles the routing or forwarding tables in order to induce this behavior in what seems to be their default configuration. > > You probably don't want to merge this because it means you'll get > > periodic, useless ping replies on the VPN tunnel interface (the > > keepalives). Could you instead apply /this/ patch which only catches > > the ping reply IF IT HAS THE MATCHING MAGIC PAYLOAD? > > Yeah, that looks saner than my hack. Thanks. Same patch, slightly cleaned-up, as MR: https://gitlab.com/openconnect/openconnect/merge_requests/39 _______________________________________________ openconnect-devel mailing list openconnect-devel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/openconnect-devel
