On Wed, 2019-04-10 at 17:01 +0300, Daniel Lenski wrote: > On Tue, Apr 9, 2019 at 5:45 PM David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote: > > > > On Tue, 2019-04-09 at 17:32 +0300, David Woodhouse wrote: > > > FWIW I can't ping 172.16.0.2 from my client either, which is odd. But > > > everything else, including netperf, is working over that link. And I > > > *can* ping 172.16.0.1 (the client) from the server side. > > > > Oh, haha that's because the incoming response is eaten by the GPST > > protocol's udp_catch_probe() function. > > Are you sure about that? > > 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. Because I don't think my server (which is just Linux with XFRM-configured ESP) would respond as we want, to its public address. > Because of this, a *normal* ping of the external address of the VPN > gateway should *not* be "eaten" by the GPST protocol's > udp_catch_probe() function. > > > This makes client→server ping work, but don't bother because it isn't > > important for our tests. > > 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. > diff --git a/gpst.c b/gpst.c > index a0dc81f..c0b7641 100644 > --- a/gpst.c > +++ b/gpst.c > @@ -1300,10 +1300,14 @@ int gpst_esp_send_probes(struct > openconnect_info *vpninfo) > int gpst_esp_catch_probe(struct openconnect_info *vpninfo, struct pkt *pkt) > { > struct ip *iph = (void *)(pkt->data); > + static char magic[16] = "monitor\x00\x00pan ha "; > + > return ( pkt->len >= 21 > && iph->ip_p==1 /* IPv4 protocol field == ICMP */ > && iph->ip_src.s_addr == vpninfo->esp_magic /* source == magic address */ > - && pkt->len >= (iph->ip_hl<<2)+1 /* No short-packet segfaults */ > - && pkt->data[iph->ip_hl<<2]==0 /* ICMP reply */ ); > + && pkt->len >= (iph->ip_hl<<2) + ICMP_MINLEN + sizeof(magic) /* No short-packet segfaults */ > + && pkt->data[iph->ip_hl<<2]==0 /* ICMP reply */ > + && !memcmp(&pkt->data[(iph->ip_hl<<2) + ICMP_MINLEN], magic, sizeof(magic)) > + ); > } > #endif /* HAVE_ESP */ > > Thanks, > Dan
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openconnect-devel mailing list openconnect-devel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/openconnect-devel
