wireguard: allow to set IPv6 endpoint

[naito.yuichiro_gmail.com]

Summary

Most of codes work for IPv6 endpoint, but handling of IPv6 address length is wrong.
This patch fixes to support both of the size of sockaddr_in and sockaddr_in6.
I can confirm this patch works for IPv6 endpoint.

Test Plan

Wireguard tunnel can be set up via IPv6.

[donner]

sys/dev/if_wg/module/if_wg_session.c

1885–1894

So we have uninitialized space, if sa_len < sizeof(...)?
So we can overwrite memory, if sa_len > sizeof(...)?

[grehan]

There's a more complete fix for this in the pfsense repo, that also stores the source address so CARP destination addresses will work:

https://github.com/pfsense/FreeBSD-src/commit/1940e7d3

... also the minor fix for ipv6 tcpdump

https://github.com/pfsense/FreeBSD-src/commit/825ed9ee

[naito.yuichiro_gmail.com]

In D28933#647903, @grehan wrote:

There's a more complete fix for this in the pfsense repo, that also stores the source address so CARP destination addresses will work:

https://github.com/pfsense/FreeBSD-src/commit/1940e7d3

I think it's better than my code.
Would you please commit pfsense patch after my patch?
It will record the authors of the codes clearly.

... also the minor fix for ipv6 tcpdump

https://github.com/pfsense/FreeBSD-src/commit/825ed9ee

I think it's also necessary for us.

sys/dev/if_wg/module/if_wg_session.c

1885–1894

I'll fix to see sa_family to determine the length of sockaddr_in{6}.

[naito.yuichiro_gmail.com]

Fix to see sa_family to determine the length of struct sockaddr_in{6}.

[zarychtam_plan-b.pwste.edu.pl]

The IPv6 endpoint is accepted fine, but the tunnel is still not able to carry the data, at least legacy IP. Is it the complete solution or am I missing anything? At a glance, some outgoing and returning traffic can be dumped on the wg(4) interface, but it doesn't look fully functional since it behaves like a sinkhole with no local exit.

[naito.yuichiro_gmail.com]

In D28933#648167, @zarychtam_plan-b.pwste.edu.pl wrote:

The IPv6 endpoint is accepted fine, but the tunnel is still not able to carry the data, at least legacy IP. Is it the complete solution or am I missing anything? At a glance, some outgoing and returning traffic can be dumped on the wg(4) interface, but it doesn't look fully functional since it behaves like a sinkhole with no local exit.

Yes, this patch works for me.
I'm going to show you a simple example between hostA and hostB.

After setting up wireguard tunnel:

hostA:
ifconfig wg0 inet 10.0.0.1
route add -host 10.0.0.2 -iface wg0

hostB:
ifocnfig wg0 inet 10.0.0.2
route add -host 10.0.0.1 -iface wg0
ping 10.0.0.1

Could you try this one?
wg(4) is a interface so that outgoing packet must be routed via the interface.

[grehan]

FYI the cumulative pfsense wireguard changes are in D28962

[naito.yuichiro_gmail.com]

In D28933#648397, @grehan wrote:

FYI the cumulative pfsense wireguard changes are in D28962

D28962 looks good to me.
If you commit D28962, I'll close this review.

[zarychtam_plan-b.pwste.edu.pl]

In D28933#648321, @naito.yuichiro_gmail.com wrote:

In D28933#648167, @zarychtam_plan-b.pwste.edu.pl wrote:

The IPv6 endpoint is accepted fine, but the tunnel is still not able to carry the data, at least legacy IP. Is it the complete solution or am I missing anything? At a glance, some outgoing and returning traffic can be dumped on the wg(4) interface, but it doesn't look fully functional since it behaves like a sinkhole with no local exit.

Yes, this patch works for me.
I'm going to show you a simple example between hostA and hostB.

After setting up wireguard tunnel:

hostA:
ifconfig wg0 inet 10.0.0.1
route add -host 10.0.0.2 -iface wg0

hostB:
ifocnfig wg0 inet 10.0.0.2
route add -host 10.0.0.1 -iface wg0
ping 10.0.0.1

Could you try this one?
wg(4) is a interface so that outgoing packet must be routed via the interface.

Works, it was probably my fault.

[grehan]

D28962 now committed with 95331c228a39

[naito.yuichiro_gmail.com]

I'm glad the issue has been solved.
Thanks everyone for reviewing and testing my code.