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

[Paul Wouters]

> On Jun 6, 2018, at 04:43, Antony Antony <antony at phenome.org> wrote:
> 
> thanks this could work too. However, it looks a bit strange with %defaultroute only picking v4 address.

We have left=%defaultroute6 to signal wanting to use IPv6 ?

We have no good way to say “either is fine” or “try X, fallback to Y if that doesn’t work”

But nothing should have changed here.

> 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.

That is not intensional and seems to be an unwanted side effect. I will see about addressing that.

> I don't like this idea of extra hostaddrfamily for simple case as mine.  

That feeling is mutual :)

> May be it is a good idea for some advanced use case. A simple case should follow the RFC 3484 (gai.conf).

That might be a good feature for the next release. 

> 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.

I would expect left=%defaultroute to do ipv4 only. 


> My suspicion is the libunbound integration in pluto is not following gai.conf.

We also still have some ID related calls resulting in gethostbyname2() being called for which I proposed in the past to add another blocking unbound ctx. This was not yet fixed.


> 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:)

gethostbyname() does not support ipv6


> 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.
> 

This must be a side effect of resolving in libipsecconf and addcon so by the time pluto gets its whack message, the family is wrong already.

> I recomend reverting all recent fixes related to this and fix libunbound calls and may be %defaultroute.

That would just re-introduce the previous problems of 6in4 or 4in6 breaking. So I would not want to go that way.



> also would recomend subnetaddrfamily instead of clientaddrfamily. 

I thought about that but found it awkward too. The code all calls this client but our configs call it subnet (even though sometimes it is a /32 subnet).  

> may be even leave connaddrfamily for clientaddrfamily. I do not have strong feeling about this.

I moved away from connaddrfamily for two reasons. One is that it really applies to host address family but due to implementation bugs you sometimes had to set it to the client address family and the man page stated that is what you should do. Second, the name “conn” isn’t clear at all whether this means the inner or outer IP address family.

Paul



> 
> 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