Hi Paul On Thu, Jan 9, 2014 at 10:11 PM, Paul Wouters <[email protected]> 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@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 => [email protected]<- 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@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
_______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
