Very cool. Any chance of [ knock protected services , knock listening ] X [ ipv6, ipv4+6 ] as well as current ipv4 only (knock & ports)?

Hi,

Should the ipv6 or ipv4 support be choosen at build time ?

I mean, could the ip buffers be defined as following ?

#ifdef _IPV4_SUPPORT_
    dst_ip[INET_ADDRSTRLEN];
#else
    dst_ip[INET6_ADDRSTRLEN];
#endif

or maybe this is going to be defined in a variable in fwknopd.conf and then the ip buffers should be defined as :

dst_ip[INET6_ADDRSTRLEN];

but I am not sure about the side effects :)

I have started to replace all of the occurence of MAX_IPV4_STR by INET_ADDRSTRLEN for consistency purposes since this macro is already defined out of the fwknop source code.

Ideally I think fwknop be able to support both ipv4 and ipv6 at run time without having to recompile (which would make it harder for users whenever there are mixed v4/v6 environments). The ipv6 compatibility work should also probably go into a dedicated branch which can be merged in when it's ready since it is going to be a large set of changes.

In the meantime, what's the current way of forcing IPv4 with fwknop?

I'm on an IPv6-enabled network, trying to connect to an IPv6 server and I do this:

fwknop -n server.example.com
ssh -4 server.example.com

That doesn't work because the DNS resolver gives me an IPv6 address for server.example.com. I have to hack /etc/hosts and put an IPv4 address in there for the server in order to make the fwknop call work. Is there a nicer work-around?

So, ssh -4 is able to resolve to an IPv4 address? I need to add the ability to force IPv4 then too. In your case the resolver must be returning both v6 and v4 addresses.

So, ssh -4 is able to resolve to an IPv4 address? I need to add the ability to force IPv4 then too.

It would be great if fwknop had a -4 option as well. In fact, until IPv6 support is in, it probably makes sense to default to whatever ssh does with -4.

In your case the resolver must be returning both v6 and v4 addresses.

Yes, my resolver returns both IPv4 and IPv6 addresses when I'm at work. Only IPv4 when I'm at home.

Ok, looks like the client just needs to require the AF_INET family from getaddrinfo(). I'll send you a patch for testing.

I've pushed a commit to master (b03c007) to add a new --server-resolve-ipv4 option. If you pull from git and recompile then the client should function in your environment I think. Please let me know if there are any issues with this code. Once I start on the full IPv6 support there will be additional options along these lines, but hopefully this will work in the meantime.

That patch works for me, thanks!

Any reason what that shouldn't be the default until IPv6 is supported? There's really no point in using IPv6 addresses right now when we know they're not going to work.

Is this still an open issue? Did fwknop 'add full ipv6 support'? if yes, close this issue and maybe make it more obvious in documentation. If no, are there plans to do so?

IPv6 support is coming likely in fwknop-3.0. So, fwknop does not yet support IPv6 today. There was a switch to getaddrinfo() in the client which will make supporting IPv6 easier (and this is already in current fwknop releases), but the main effort will be in getting the server to work with it. Actually it would be interesting to see how the new command open/close cycle stuff might help with this. But, the SPA packet format will also have to be updated to handle it.

Is this work currently in flight? I have a need for this functionality and am interested in contributing to the solution.

ipv6 work has not yet started, though it's on my short list of things to look at.

https://www.iab.org/2016/11/07/iab-statement-on-ipv6/

The IAB expects that the IETF will stop requiring IPv4 compatibility in new or extended protocols. Future IETF protocol work will then optimize for and depend on IPv6.

Preparation for this transition requires ensuring that many different environments are capable of operating completely on IPv6 without being dependent on IPv4 [see RFC 6540]. We recommend that all networking standards assume the use of IPv6, and be written so they do not require IPv4. We recommend that existing standards be reviewed to ensure they will work with IPv6, and use IPv6 examples.

In case you could need some additional motivation (but ofc it's ok if it'll take some time) 😉.

Hi there, I just got contracted by Asahi Net, Inc. from Tokyo, Japan to contribute IPv6 support to the fwknop project. I will try to achieve this until the beginning of July this year. Any hint or procedure I should follow to achieve this the best way possible for this work to be easily integrated to the project is more than welcome!
My first concern is with the protocol itself and how to document/standardize it. I have to proceed and deliver a working implementation regardless of its approval upstream here, so the sooner this can be clarified, the better IMHO.

Hello @khorben. Adding IPv6 support to fwknop would indeed be an amazing contribution. I would start with a lightweight approach to this.

On the server side, the easiest path would be to use the CMD_CYCLE feature to interface with a local firewall that is applying IPv6 policy (such as ip6tables). This way you wouldn't have to write something analogous to the 'server/fw_util_iptables.c' code, and the CMD_CYCLE feature is generally a lot more powerful anyway.

The bulk of the work as you said would need to be on the SPA protocol itself. We had in the past the idea of a binary protocol, but I would not try to implement this for IPv6 support because it represents a total rewrite essentially. If you keep the current ascii protocol, but extend the current implementation to support an IPv6 address at every place that we can have an IPv4 address, then this would work. The result would not be backwards compatible, but IPv6 support is important enough to warrant this I think. Fortunately, the access request field is the main thing to concentrate on, and perhaps dealing with NAT too (although this is less important in IPv6 except that gateways between v4 and v6 would still be relevant here). Here is a good overview of all SPA packet formats and associated data:

https://github.com/mrash/fwknop/blob/master/test/spa_fuzzing.py#L35

I might well be able to implement most, if not all, of the support for IPv6 without even breaking compatibility.
The protocol is text-based and there is no ambiguity that I can think of between IPv4 and IPv6 addresses, so I expect to be able to do this successfully.

Any news?