On Wed, Feb 6, 2019 at 1:47 AM David Woodhouse <dwmw2 at infradead.org> wrote: > > On Tue, 2019-02-05 at 11:23 -0800, Daniel Lenski wrote: > > Great! > > > > David, > > How would you feel about merging in support for the `--request-ip` > > option if it's only functional for GlobalProtect right now? (Recall > > that our tests on Cisco servers confirm it doesn't work? at least not > > on all of them? and it definitely doesn't work with ocserv, nor with > > Juniper.) Maybe have it error out if `--request-ip` is specified with > > a protocol that doesn't support it? or just warn since it's merely a > > "request" anyway? > > > > Presumably we'd want an API function and protocol feature flags for > > this as well. > > Yeah, let's do it. Let's make it work with ocserv, and with IPv6. Great. For the AnyConnect/ocserv protocol, this will basically mean adding "X-CSTP-Address" request header with the value of the desired IPv4 and/or IPv6 address. ocserv will need support for this header (probably configurable, for security reasons, etc.). Nikos, assuming that I get the details right, do you have any objection in principle to using this header as the mechanism by which the client can request a specific address? > For a protocol where we don't even know how to ask, reject the option. Juniper. Right. > For AnyConnect, we can let it be a 'best effort' perhaps? It'll be "best effort" with GlobalProtect too, since it's not possible to guarantee that the server will be willing/able to provision a specific address, and the server just ignores it if you can request an address it can't provide. Thanks, Dan
