[vpn-devel] [Patch] Interface / address issues.

[Zephaniah E. Loss-Cutler-Hull]

On 06/28/2010 12:54 PM, Matthew Grooms wrote:
> On 4/8/2010 5:32 PM, Zephaniah E. Loss-Cutler-Hull wrote:
>> So, our setup:
>>
>> Cisco PIX on the remote end, RSA key exchange plus xauth.
>>
>> On the local end is a Linux box, x86-64 Ubuntu 9.10, with a 2.6.33.2
>> kernel.
>>
>> With stock ike we manage to connect, the tunnel gets setup, and tcpdump
>> shows that packets we send reach the other side, and that we get the
>> decrypted response packets back on the primary interface (eth0 in our
>> main test case), and then the kernel drops those packets on the floor.
>>
>> Regardless of iptables setup, packets coming in the wrong interface are
>> discarded, and this renders ike non-functional.
>>
>>  From our prospective, the easiest fix was the attached patch (against
>> SVN head), which allows the specification of a script to run to do the
>> adding/removing of addresses, along with some modifications to allow
>> arbitrary interface strings to be passed through.
>>
>> This script uses ip from the iproute package to add and remove addresses
>> from the given interface, it also understands the interface 'default' to
>> mean the interface attached to the default route.
>>
>> Due to things being somewhat intertwined in the diff, this patch also
>> fixes a typo in vpna/sites.ui (adpter vs adapter, with the code
>> expecting adapter), and throws the UpdateAuthentication call into
>> vpna/sites.cpp (ikeaSite::load) between parsing auth-method and
>> ident-client-type.
>>
>> An example script is attached as well.
>>
>> This has been tested, and works quite well in our environment.
>>
>> This is all Copyright (C) 2010 JetPay, LLC, under the license currently
>> at the top of each patched file.
>>
>> (A more permissive license should be possible if Screw Soft needs it.)
>>
> 
> Hi Zephaniah,
> 
> Thanks for submitting the patch. Your approach looks similar to the
> method  used by ipsec-tools and no doubt other ike daemons. The problem
> with discarded packets is related to the rp_filter feature of the Linux
> kernel. For more information, please see this post ...

Thank you, we finally tracked that down about a week and a half ago,
with some definite beating of heads against the wall when we got it.
> 
> http://lists.shrew.net/mailman/htdig/vpn-help/2008-November/001827.html
> 
> ... I'm not sure why this kernel feature enforces the check on packets
> received under the protection of an IPsec tunnel. It shouldn't. While I
> like the idea of adding the UP/DOWN scripts as they could be useful for
> many reasons, I don't think we need another adapter mode. While I agree
> it would be useful on Linux, other platforms assign multiple addresses
> without creating an interface aliases. This means you can't set the MTU
> without effecting the traffic to/from the primary interface address.

Understood on that point.

However this brings us to another point where we ended up having to
spend some time here, NetworkManager integration.

(If you have an alternate solution to this, I'd love to hear it.)

At the moment, NetworkManager likes to stomp on things like DNS
configuration files enough to break things, to what degree depends on
the exact configuration, the most common is breaking the search paths,
but definitely up to reconfiguring interfaces in, annoying ways.

The first patch did not address the problem sufficiently to implement a
NM VPN plugin as the up/down script, a modified version helped with DNS,
however routing information proved to be a very significant sticking point.

At the moment we have patches to iked to allow the client to specify
that it needs to handle most of the fun with setting up the interface,
and a horrible mess of a client which integrates with NM. (I would be
surprised if you were interested in taking the client as it stands
today, but I am unsure when I'm going to have time allotted to fix
things up further.)

Right now, I still need to spend a bit of time removing the up/down
script changes from the patches, and then if possible feedback on the
direction this is going would be greatly appreciated.

Thank you,
Zephaniah E. Loss-Cutler-Hull.
JetPay, LLC.
> 
> Thanks again,
> 
> -Matthew

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <https://lists.shrew.net/pipermail/vpn-devel/attachments/20100630/55f49b8a/attachment-0003.bin>