[Openswan dev] IPsec over IPv6 including 6to4 ... some success, and some documentation opportunities

[John Denker]

On 10/01/2008 08:42 AM, Paul Wouters wrote:

> Since you have just done this, how about doing an example
> config to be installed in /etc/ipsec.d/examples and perhaps
> a README.IPv6 with your findings and issues to date?

See next paragraph:

> I would like to start a README.IPv6 based on your email and your
> weg page, if you have no objections. I'll also incorporate some
> of the information in the man page for ipsec.conf.

Yes, that sounds great.

There is an example and lots of discussion at
  http://www.av8n.com/computer/htm/ipv6-howto.htm#sec-ipsec

Can you just grab that?  

If you need more/different/better stuff, please explain
more precisely what you want.

>> 3) When using kernel IPsec, it is allowable and often
> 
> Note that "kernel IPsec" is confusing, hence our insistence
> to talk about KLIPS or NETKEY.

OK, will do.

>> advantageous to specify "interfaces=%none".  This ought
>> to be prominently documented somewhere.  And if you ask
>> me, it ought to be the default when using kernel IPsec.
> 
> Tuomo, do you agree that "%none" would work better then "%defaultroute"
> in most cases?

Note that interfaces=%none is related to, and possibly dependent
on, the following:
 
>> And connections ought to be routed using the actual route,
>> not the "defaultroute".  This is easy to do using
>> "ip route get to ....".  I have scripts that do this, but
>> it ought to become the standard built-in behavior.
> 
> Recently, the updown scripts were split into a klips and a netkey
> version, so if you have modifications for us to _start.netkey, we
> would like to review and test those and if possible incorporate
> your enhancements.

OK.  That will take some time.

Also: that should probably be discussed in a separate thread.  
I say this because there are a lot of folks out there using
the current stable distros, and they need to be told that they 
can do Openswan IPsec over IPv6 with the tools they already
have.

Improvements are good, but they are a separate issue.

>> 4) When using kernel IPsec, if you use tcpdump or some such
>> to look at the interface (e.g. eth0), by the time tcpdump
>> gets its hands on the packet, it has already been decrypted.
>> As a workaround, it pays to define an alias device (e.g.
>> eth0:1) so you can get your hands on the packets fresh off
>> the wire, before they are decrypted.  The problem and the
>> workaround ought to be documented somewhere.
> 
> I did not realise this was possible. Can you give a little more
> detail on how this works?

Here's a /little/ more detail.  Consider (or try!) the following
scenario:  Set up a host-to-host tunnel from East to West.  On East, 
do
  ping west -p feedfacedeadbeef
On West, run tcpdump on interface eth0 and observe that tcp prints
cleartext for the arriving ICMP echo requests (but prints cryptotext
for the outgoing IMCP echo replies).

Next, still on West, bring up an alias device:
  ifconfig eth0:1  1.2.3.4 netmask 255.255.255.0
The address (1.2.3.4) is arbitrary and meaningless.

Then do tcpdump on device eth0:1.  Observe cryptotext in both directions.

That's about all I think to say right now.  If that's not 100% 
clear, please ask a more specific question.


>> 5) Openswan IPsec works even when the first hop is a 6/4\6 tunnel
>> via a "6to4" device, i.e. IP protocol 41.  The 6to4 device is
>> weird enough that we might have expected some trouble.  One
>> slightly tricky point is that you need not (and must not)
>> specify a leftnexthop when using this device.  This ought
>> to be documented somewhere.
> 
> See above.

Which above?  Please clarify, unless it's already been covered.

>> 6) When using kernel IPsec, when the host is performing IPsec
>> for a subnet, if the peer tries to contact the host via its
>> address on the subnet, the traffic gets thrown away.  This
>> ought to be documented somewhere.  Klips was better behaved
>> in this regard (although some deft fiddling with the routing
>> tables was required).
> 
> The option for this is the leftsourceip= option, though I am
> not sure if it will work fine with IPv6. Please let me know if
> that works.

OK, let me work on it.


On 10/01/2008 09:32 AM, Anthony Tong wrote:
> 
>> I have modifications too for 2.4.x to handle the ipv6 routes, but
>> there is an issue with route cleanups that I havent had time
>> to look at closely and I am not even sure whether openswan is the
>> culprit. os is rhel5.
>> 
>> When openswan shuts down and runs its corresponding route deletes
>> some ipv6 routes dont go away. The ip -6 route del work fine but I think
>> something bumped the refcount on the route (and it wasnt from the
>> openswan helper script changes) so it takes an extra delete to get rid
>> of it.
>> 
>> I know this is kinda vague and on older software revisions, it's been a
>> while. Out of curiosity, have you looked at your ip -6 route after a
>> openswan shutdown.. anything odd?

The short answer is that I haven't looked carefully.
As Sarah Palin said, "I'll hafta get back to ya on that"