<div dir="ltr"><div class="gmail_extra">Hi Paul<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 9, 2014 at 10:11 PM, Paul Wouters <span dir="ltr"><<a href="mailto:paul@nohats.ca" target="_blank">paul@nohats.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">On Thu, 9 Jan 2014, markd lists wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Hoping someone can help me understand the behaviour of an policy group based OE setup (<a href="http://0.0.0.0/0" target="_blank">0.0.0.0/0</a> in private-or-clear). Specifically what<br>
happens when there are no TXT or IPSECKEY RR for either host.<br>
</blockquote>
<br></div>
It should insert a /32 to /32 %pass eroute in the most common case, but<br>
it does depend on the contents of the /etc/ipsec.d/policies/* files.<br>
Normally, 0/0 is in the "privateorclear" meaning try private, fall back<br>
to clear. I see those in your output, eg:<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
12 <a href="http://10.236.54.8/32" target="_blank">10.236.54.8/32</a> -> $ip_of_my_local_dns_server_1/<u></u>32 => %pass<br>
</blockquote>
<br></div>
That shows 12 cleartext packets to your local nameserver.<div class="im"><br></div></blockquote><div><br></div><div>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<br>
</div><div><br></div><div>Cleaning up the output (removing the root nameserver entries) it looks like<br><br>root@is01:~# ipsec eroute<br>83 <a href="http://10.236.54.8/32">10.236.54.8/32</a> -> <a href="http://0.0.0.0/0">0.0.0.0/0</a> => %trap <- assume installed by <a href="http://0.0.0.0/0">0.0.0.0/0</a> in /etc/ipsec.d/policies/private-or-clear<br>
2986 <a href="http://10.236.54.8/32">10.236.54.8/32</a> -> <a href="http://10.236.54.7/32">10.236.54.7/32</a> => <a href="mailto:tun0x1004@10.236.54.7">tun0x1004@10.236.54.7</a> <- installed by conn is01-is02-ptp<br>
46 <a href="http://10.236.54.8/32">10.236.54.8/32</a> -> $ip_of_my_local_dns_server_1 => %pass <- assume installed by entry in /etc/ipsec.d/policies/clear<br>42 <a href="http://10.236.54.8/32">10.236.54.8/32</a> -> $ip_of_my_local_dns_server_2 => %pass <- assume installed by entry in /etc/ipsec.d/policies/clear<br>
</div><div><br>The hosts involved were:<br><br>is01 running libreswan-3.7 - 10.236.54.8<br></div><div>and a second box (no IPSEC software) trying to connect to is01 (ping, ssh, etc) being caught by the %trap rule<br>"jumpbox" - 10.236.33.241 or 10.236.33.242 <br>
</div><div></div><div><br>When I start ipsec on is01<br></div><div>* 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)<br>
</div><div>Traffic from is01 <> is02 works fine across the ptp tunnel<br></div><div>Traffic from jumpboxes to is01 fails to connect (the no explicit failure shunt messages)<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
.. TXT lookup and failure for our explicitly specified leftid (purposefully not in DNS)<br>
</blockquote>
<br></div>
Note that you are looking at what we now call the "old OE" code. The<br>
idea of the new OE code is that no such logic exists within the IKE<br>
daemon, but that external events (eg triggered by a DNS server plugin)<br>
will instruct pluto to setup something specific.<div class="im"><br></div></blockquote><div><br></div><div>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!<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
| DNS query 7 for TXT for is01.infrasec.orion.altus. (gw: @is01.infrasec.orion.altus)<br>
| * processed 0 messages from cryptographic helpers<br>
| next event EVENT_PENDING_DDNS in 23 seconds<br>
| next event EVENT_PENDING_DDNS in 23 seconds<br>
|<br>
| * processed 0 messages from cryptographic helpers<br>
| next event EVENT_PENDING_DDNS in 23 seconds<br>
| next event EVENT_PENDING_DDNS in 23 seconds<br>
|<br>
| *received adns message<br>
| asynch DNS answer 7 no TXT record for is01.infrasec.orion.altus.<br>
<br>
.. IPSECKEY lookup and failure<br>
</blockquote>
<br></div>
Note that IPSECKEY was never fully implemented. Only TXT records (and<br>
the old-style KEY records from before KEY was restricted to internal-DNS<br>
only and renamed to DNSKEY)<div class="im"><br></div></blockquote><div><br></div><div>In case its relevant, I only see the TXT lookups and not the IPSECKEY lookups<br>root@is01:~# tcpdump -n -i eth0 'port 53'<br>
..<br>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)<br>15:35:47.084249 IP $ip_of_my_local_dns_server_1.53 > 10.236.54.8.50818: 35832 0/1/0 (124)<br>
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)<br>15:35:48.081130 IP $ip_of_my_local_dns_server_2.53 > 10.236.54.8.38158: 31211 0/1/0 (124)<br>..<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
and finally a "no explicit failure shunt" message and removal of the hold shunt (where I assumed a %pass rule would be installed)<br>
</blockquote>
<br></div>
It should yes, doesn't it, passed on the "ipsec eroute" command I see<br>
below, it does?<br>
<br></blockquote><div><br></div><div>It doesn't, no %pass is installed for anything not covered by the /32's in policies/clear or conn is01-is02-ptp<br><br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Note this code path has not been tested since about 2005. It must have<br>
suffered some bit rot. We are looking at a different way of implementing<br>
things now, and are hoping to have some proof of concept code and an<br>
internet draft out in 2-3 weeks. (We are specifically meeting to work<br>
on this in Sna Francisco next week)<span class=""><font color="#888888"><br>
<br>
Paul<br>
</font></span></blockquote></div><br></div><div class="gmail_extra">Very excited to hear that - you guys are doing great work here, happy to help with testing :)<br><br></div><div class="gmail_extra">Mark<br><br></div></div>