[Swan] Explicit failure shunt for opportunistic connections

[markd lists]

Hi Paul

On Thu, Jan 9, 2014 at 10:11 PM, Paul Wouters <paul at nohats.ca> wrote:

> On Thu, 9 Jan 2014, markd lists wrote:
>
>  Hoping someone can help me understand the behaviour of an policy group
>> based OE setup (0.0.0.0/0 in private-or-clear). Specifically what
>> happens when there are no TXT or IPSECKEY RR for either host.
>>
>
> It should insert a /32 to /32 %pass eroute in the most common case, but
> it does depend on the contents of the /etc/ipsec.d/policies/* files.
> Normally, 0/0 is in the "privateorclear" meaning try private, fall back
> to clear. I see those in your output, eg:
>
>
>  12         10.236.54.8/32     -> $ip_of_my_local_dns_server_1/32  =>
>> %pass
>>
>
> That shows 12 cleartext packets to your local nameserver.
>
>
Sorry, I should have been more specific. $ip_of_my_local_dns_server_1 and
$ip_of_my_local_dns_server_2 are in /etc/ipsec.d/policies/clear which is
where I assume the %pass rules come from

Cleaning up the output (removing the root nameserver entries) it looks like

root at is01:~# ipsec eroute
83         10.236.54.8/32     -> 0.0.0.0/0          => %trap <- assume
installed by 0.0.0.0/0 in /etc/ipsec.d/policies/private-or-clear
2986       10.236.54.8/32     -> 10.236.54.7/32     =>
tun0x1004 at 10.236.54.7<- installed by conn is01-is02-ptp
46         10.236.54.8/32     -> $ip_of_my_local_dns_server_1  => %pass <-
assume installed by entry in /etc/ipsec.d/policies/clear
42         10.236.54.8/32     -> $ip_of_my_local_dns_server_2  => %pass <-
assume installed by entry in /etc/ipsec.d/policies/clear

The hosts involved were:

is01 running libreswan-3.7 - 10.236.54.8
and a second box (no IPSEC software) trying to connect to is01 (ping, ssh,
etc) being caught by the %trap rule
"jumpbox" - 10.236.33.241 or 10.236.33.242

When I start ipsec on is01
* Traffic from is01 to the 2 DNS servers works fine (for 1 hour after which
the %pass seems to expire until I "stop ipsec", "start ipsec", "ipsec auto
--rereadgroups".. not sure which of salifetime, ikelifetime, etc I need to
play with here)
Traffic from is01 <> is02 works fine across the ptp tunnel
Traffic from jumpboxes to is01 fails to connect (the no explicit failure
shunt messages)



>
>
>> .. TXT lookup and failure for our explicitly specified leftid
>> (purposefully not in DNS)
>>
>
> Note that you are looking at what we now call the "old OE" code. The
> idea of the new OE code is that no such logic exists within the IKE
> daemon, but that external events (eg triggered by a DNS server plugin)
> will instruct pluto to setup something specific.
>
>
Understood, I was aware of some of this from your blog post on "History and
implementation status of OE" and that preso you linked on a previous list
message but I had to try anyway!


>
>  | DNS query 7 for TXT for is01.infrasec.orion.altus. (gw:
>> @is01.infrasec.orion.altus)
>> | * processed 0 messages from cryptographic helpers
>> | next event EVENT_PENDING_DDNS in 23 seconds
>> | next event EVENT_PENDING_DDNS in 23 seconds
>> |
>> | * processed 0 messages from cryptographic helpers
>> | next event EVENT_PENDING_DDNS in 23 seconds
>> | next event EVENT_PENDING_DDNS in 23 seconds
>> |
>> | *received adns message
>> | asynch DNS answer 7 no TXT record for is01.infrasec.orion.altus.
>>
>> .. IPSECKEY lookup and failure
>>
>
> Note that IPSECKEY was never fully implemented. Only TXT records (and
> the old-style KEY records from before KEY was restricted to internal-DNS
> only and renamed to DNSKEY)
>
>
In case its relevant, I only see the TXT lookups and not the IPSECKEY
lookups
root at is01:~# tcpdump -n -i eth0 'port 53'
..
15:35:47.079866 IP 10.236.54.8.50818 > $ip_of_my_local_dns_server_1.53:
35832+ TXT? is01.infrasec.orion.altus. (50)
15:35:47.084249 IP $ip_of_my_local_dns_server_1.53 > 10.236.54.8.50818:
35832 0/1/0 (124)
15:35:48.076588 IP 10.236.54.8.38158 > $ip_of_my_local_dns_server_2.53:
31211+ TXT? is01.infrasec.orion.altus. (50)
15:35:48.081130 IP $ip_of_my_local_dns_server_2.53 > 10.236.54.8.38158:
31211 0/1/0 (124)
..


>
>
>> and finally a "no explicit failure shunt" message and removal of the hold
>> shunt (where I assumed a %pass rule would be installed)
>>
>
> It should yes, doesn't it, passed on the "ipsec eroute" command I see
> below, it does?
>
>
It doesn't, no %pass is installed for anything not covered by the /32's in
policies/clear or conn is01-is02-ptp




> Note this code path has not been tested since about 2005. It must have
> suffered some bit rot. We are looking at a different way of implementing
> things now, and are hoping to have some proof of concept code and an
> internet draft out in 2-3 weeks. (We are specifically meeting to work
> on this in Sna Francisco next week)
>
> Paul
>

Very excited to hear that - you guys are doing great work here, happy to
help with testing :)

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20140110/ffd19dec/attachment.html>