[Swan-dev] regression in 3ecec8adc Re: [Swan-commit] Changes to ref refs/heads/master

[Antony Antony]

thanks this could work too. However, it looks a bit strange with %defaultroute only picking v4 address.

Yesterday I tried USE_DNSSEC=false, and this worked for me. 

It seems your fix need me to add hostaddrfamily even when the host has no IPv6 address and address family is picked using %defaultroute, just because destination has A and AAAA record. I don't like this idea of extra hostaddrfamily for simple case as mine.  May be it is a good idea for some advanced use case. A simple case should follow the RFC 3484 (gai.conf).

Here is my 0.02 cent note
Yesterday, I looked a bit more what is going on here. I do not have an IPv6 address(global, just link local) pluto still send messages to IPv6 destination and do not try IPv4 address. Which looks a bit strange in this day and age:) Fixing %defaultroute route to the right thing address family is probably a bit more work. My suspicion is the libunbound integration in pluto is not following gai.conf. USE_DNSSEC=false disabled that and went back to gethostbyname. It seems to fix the issue. Or we are hard coding AF_INET in the call to gethostbyname. Which worked for me:)

When resolving destination using libc ,getaddrinfo, follows gai.conf, which is based on RFC 3484,destination address selection. I am not 100% gethostbyname use getaddrinfo. And I think libreswan libunbound integration is not following gai.conf/RFC3484.

In my case, where I noticed the issue, host had no global IPv6 address and
gai.conf is specifically configured to prefer IPv4, yet pluto kept on sending messages to unroutable IPv6 address. Also without trying the next IPv4 address. This is weired.

I recomend reverting all recent fixes related to this and fix libunbound calls and may be %defaultroute. Otherwise  However, a better fix for destination address selection is probably a different discussion!

also would recomend subnetaddrfamily instead of clientaddrfamily. 
may be even leave connaddrfamily for clientaddrfamily. I do not have strong feeling about this.

On Wed, Jun 06, 2018 at 01:17:52AM -0400, Paul Wouters wrot
> On Tue, 5 Jun 2018, Antony Antony wrote:
> 
> > this commit seems to break one of my v4 only tunnel.
> > The remote end resolve to both v6 and v4 (A and AAAA) and it used to work. Now suddenly it is pickinug v6 and not able establish the v4 tunnel.
> 
> This should now be fixed. Note if you are using connaddrfamily= that
> this keyword has been obsoleted now and should not be needed (and is
> ignored with a warning)
> 
> Only when using DNS that resolves to both A and AAAA might you need a
> keyword, but then you need to use either hostaddrfamily= for the
> left/right or clientaddrfamily= for the leftsubnet/rightsubnet family.
> 
> It is also no longer needed to use any *addrfamily= keyword for 6in4 or
> 4in6 connecions.
> 
> Paul