On Wed, 2019-04-10 at 17:01 +0300, Daniel Lenski wrote: > On Tue, Apr 9, 2019 at 5:45 PM David Woodhouse <[email protected]> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openconnect-devel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/openconnect-devel
