Open Stack

Hi,

See inline answers to PCM questions:

2013/5/30 Nachi Ueno <nachi at ntti3.com>:
> Hi Francois, PCM
>
> Great work.
> I'm now +1 for StrongSwan because the file issue is resolved.
>
>
> 2013/5/29 Paul Michali <pcm at cisco.com>:
>> See inline PCM:
>>
>> On May 28, 2013, at 12:37 PM, Eleouet Francois wrote:
>>
>>>> I think you want to test $file, right?
>>>
>>> Yes, sorry for that, shouldn't have add it as it was meaningless for
>>> the example.
>>>
>>>> Does sound like we want to use Strongswan, if at all possible. This sounds like it'll do that, huh?
>>>
>>> To my opinion, It would be better regarding its documentation and support.
>>>
>>> The only concern is about strongswan requiring some extra information in
>>> /etc or /var/run (as it will only see its own files in it). It isn't a
>>> problem for the current use case, but it may be required for some extra
>>> plugin we may want to use in the future (lots of may...)
>>>
>>> By the way, I tested it against an actual quantum router deployment,
>>
>> PCM: I'd be interested in hearing more about how you set this up.  Are you using DevStack?

It wasn't on devstack (but shouldn't matter). I used a router with two
ports, one in a tenant network hosting a VM, and another on provider
network that was used as IPsec tunnel source IP.

>>> it
>>> works fine but requires some extra tricks: we have to insert iptables
>>> rules for traffic to be correctly encrypted. Strongswan is able to insert
>>> its own filter rules using "leftfirewall" parameter. Anyway, it doesn't
>>> manages nat rules, so IPsec traffic from VMs won't cross the router until
>>> we add this kind of iptables rule:
>>>
>>> iptables -t nat -D POSTROUTING -s local_cidr -d peer_cidr -m policy \
>>> --dir out --pol ipsec --reqid 16384 --proto 50 -j ACCEPT
>>
>> PCM: Just so I better understand the rule…
>>
>> Is this applying an IPSec policy on a new connection creation between the source/dest?
>>
>> How does it modify the packet (POSTROUTING/output direction)?

Yes, it's applied at connection creation, it doesn't changes the packet,
but prevents netfilter from dropping/modifying it (assuming wee don't
want to nat trafic prior to send it on tunnel...)

Btw, sorry for the error in the above iptables command, we have to insert
the rule, not delete it:
iptables -t nat -I POSTROUTING 1 ...

>> Can you elaborate on the --reqid?
>> Is that the specific policy that is to be applied?
>> How does that relate to what we are setting up in StrongSwan?

To answer your question, I figured out I was misunderstanding reqid...
I was just deriving default rules set-up by strongswan in filter table.
It appears that netfilter is able to figure out if packet has matched an
IPsec policy, a generic rule like this seems to work fine:

iptables -t nat -I POSTROUTING 1 -m policy --dir out --pol ipsec -j ACCEPT

(Which is may be easier to set-up by the driver)

There is not much doc about netfilter/xfrm interaction...

This kind of map are not very accurate as they don't reflects current
behaviour, but may provide some explanation:
http://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg
http://www.strongswan.org/docs/netfilter.pdf

The only accurate doc I found so far is here:
http://lwn.net/Articles/160869/ and kernel source...

It looks like traffic is matched against IPsec policies after routing,
but not encrypted until it crosses netfilter POSTROUTING hook. If
traffic has been nated, it is checked again against IPsec policies.
That's why traffic won't be encrypted in actual q-router configuration
(as NATed trafic won't match IPsec policy)
For the same reason, the previous iptable rule will also work (as
netfilter will see packet as already marked by xfrm as matching an
IPsec policy, and won't NAT it)

>>> Strongswan can set it automatically if we provide it with a custom _updown
>>> script (using "leftupdown" parameter).
>>
>> PCM: Can you elaborate on this more?

/usr/lib/ipsec/_updown is called by strongswan when an IPsec connection
(containing "leftfirewall" or "lefthostaccess" parameter) is set up.
Different rules can be inserted providing a custom script in the
"leftupdown" parameter.

>>> IptablesManager could also be an
>>> option (reqid is also configurable).
>>>
>>> Note: this extra driver complexity is probably not specific to strongswan,
>>> it's probably the same in openswan (not tested).
>>
>> PCM: Great stuff Francois! I was on vacation and have been trying to catch up since the long holiday weekend.
>>
>> Sounds like we're going to try StrongSwan. I had been peeking at OpenSwan a bit and found a book (reading through it to get some background on all this).
>>
>> I see you provided another script too. Will try that out. Does that have the mapping that Nachi is looking for, to support our primary use case (site to site), or do we need to work on the mapping?
>>
>> Would like to coordinate who's doing what, so we don't duplicate effort here. Nachi/Francois, just let me know what you're working through and what you'd like me to look into (I'm new to IPSec and Free/Open/StrongSwan, but can help out as needed).
>
> Nachi: I'm going to write driver implementation ( it is a little bit
> off schedule)

On my side, I'm not sure I can't do much more now, I may help reviewing
code once first WIP will be proposed (if needed...).
Some suggestions anyway:
-To refine API mapping proposal, you could check it interoperates with
IPsec gateway (you may have access to some cisco appliances ;) Providing
cisco IPsec configuration templates would be great to ease VPNaaS use.
-If Nachi implements the driver, you may start working on strongswan
wrapper as it'll probably be self contained.
-Or work on distinct driver (to let the choice between openswan and
strongswan), but It may be too much for first implementation...

Regards,
Francois.

> Best
> Nachi
>
>>
>> Regards,
>>
>> PCM
>>
>>
>>
>>
>>>
>>> Francois.
>>