Add automated StrongSwan test

Details

  This change introduces a new automated test for StrongSwan PSK
  connectivity.

  site_linux_server.py is modified to do the following:

    vpn_strongswan_config_templates()

      Takes a list of configuration file names, and their contents.
      The contents can have text that is replaced at write-out time
      with runtime information, such as the current server IP number.
    
    vpn_server_config()

      Now suports the 'l2tpipsec' type of VPN connection.

      It is the responsibility of the person writing the test to make
      sure the contents of the provided configuration templates are
      correct, and self-consistent.
    
    vpn_server_kill()
            
      If the current type of VPN is 'l2tpipsec', then all programs
      known to be associated with that system are killed.
            
  site_wifitest.py is modified thusly:
    
    Two types of l2tpipsec configurations are supported

      lt2pipsec-psk
      lt2pipsec-cert
    
    The former uses PSK, and the latter uses certificates.  This
    separation was done to simplify the use of 'connect-vpn' (see
    review 6756032) as well as the starting of the VPN itself.

    
Testing

   Starting StrongSwan causes the default route on the system to go
   through the VPN (which causes active connections to go dead),
   automated testing is incomplete at this point.

   Initiating the VPN using 'connect-vpn l2tpipsec-psk' functions  
   correctly.

   Initiating the VPN using 'connect-vpn l2tpipsec-cert' has not yet
   been tested; I do not have configuration files for certificate mode.

See issue 6756032.

BUG=chromium-os:11824
Testing=See above

Committed: http://chrome-svn/viewvc/chromeos?view=rev&revision=0084cba

[thutt, 2011-03-30 16:25:41]

This StrongSwan test is not finalized (because StrongSwan changes the default
route, and the control connection goes dead), but I think it's along far enough
that it can benefit from some feedback.

[Sam Leffler, 2011-03-31 17:11:27]

since noone else responded yet...

http://codereview.chromium.org/6765030/diff/1/server/site_tests/network_VPN/0...
File server/site_tests/network_VPN/000VPNGenesis (right):

http://codereview.chromium.org/6765030/diff/1/server/site_tests/network_VPN/0...
server/site_tests/network_VPN/000VPNGenesis:69: # slow the system down a tad to
avoid spurious errors.
is there some way to synchronize the controlling host--such as waiting for an
echo to complete after the pkill?  using a sleep makes me nervous

http://codereview.chromium.org/6765030/diff/1/server/site_tests/network_VPN/0...
File server/site_tests/network_VPN/050StrongSwanGenesis (right):

http://codereview.chromium.org/6765030/diff/1/server/site_tests/network_VPN/0...
server/site_tests/network_VPN/050StrongSwanGenesis:6: # Router to to the Server.
mention StrongSwan somewhere in here?

http://codereview.chromium.org/6765030/diff/1/server/site_tests/network_VPN/0...
server/site_tests/network_VPN/050StrongSwanGenesis:11: ###  Create WiFi
connection from Client to Router.
don't think any of the other tests use '###'; not a big deal but prefer
consistency

http://codereview.chromium.org/6765030/diff/1/server/site_tests/network_VPN/0...
server/site_tests/network_VPN/050StrongSwanGenesis:24: [
"vpn_strongswan_config_templates", {
style nit; not sure you're using 4-space indent here like everywhere else?

http://codereview.chromium.org/6765030/diff/1/server/site_tests/network_VPN/0...
server/site_tests/network_VPN/050StrongSwanGenesis:48: "  ip range =
192.168.1.128-192.168.1.254\n"
can this be automatically filled in?

http://codereview.chromium.org/6765030/diff/1/server/site_tests/network_VPN/0...
server/site_tests/network_VPN/050StrongSwanGenesis:84: "connect-delay 5000\n"
much of the above is magic to me; please add comments

http://codereview.chromium.org/6765030/diff/1/server/site_tests/network_VPN/0...
server/site_tests/network_VPN/050StrongSwanGenesis:91: "kind" : "l2tpipsec",
indent

http://codereview.chromium.org/6765030/diff/1/server/site_tests/network_VPN/0...
server/site_tests/network_VPN/050StrongSwanGenesis:93: # @ipsecrets-ip@ should
not be replaced here.
don't understand this; did you mean "should not be used here"?

http://codereview.chromium.org/6765030/diff/1/server/site_tests/network_VPN/0...
server/site_tests/network_VPN/050StrongSwanGenesis:98: }}],
add \n? also is vpn_server_config synchronous? are there startup races?

http://codereview.chromium.org/6765030/diff/1/server/site_tests/network_VPN/0...
server/site_tests/network_VPN/050StrongSwanGenesis:103: [ "client_ping",       {
"ping_ip" : "192.168.1.99", # In xl2tpd.conf.
seems like you can factor out this fixed ip as we do for client/server ping's
etc

http://codereview.chromium.org/6765030/diff/1/server/site_wifitest.py
File server/site_wifitest.py (right):

http://codereview.chromium.org/6765030/diff/1/server/site_wifitest.py#newcode...
server/site_wifitest.py:1257: elif self.vpn_kind == 'l2tpipsec-psk': # aka
'strongswan'
We've tried hard to not have explicit builtin code like this.  Can you try to
factor the l2tp-specific work out into a subclass or something similar so this
doesn't grow when the next hard to support vpn setup requires something similar?

http://codereview.chromium.org/6765030/diff/1/server/site_wifitest.py#newcode...
server/site_wifitest.py:1270: if self.vpn_kind is not None:
see above, it might be time to factor out vpn support into it's own class(es)

[thutt, 2011-04-05 21:38:21]

This change adds a new negative test for the StrongSwan, and it addresses most
of Sam's comments.  Generally, the ones that are not addressed generated a
clarification question.

The StrongSwan test still does not work because the DUT is using the wireless IP
(as I expect it should), but the rspro is only accepting StrongSwan connections
on the wired interface; waiting advice from Paul & Ken.

http://codereview.chromium.org/6765030/diff/1/server/site_tests/network_VPN/0...
File server/site_tests/network_VPN/000VPNGenesis (right):

http://codereview.chromium.org/6765030/diff/1/server/site_tests/network_VPN/0...
server/site_tests/network_VPN/000VPNGenesis:69: # slow the system down a tad to
avoid spurious errors.
On 2011/03/31 17:11:27, Sam Leffler wrote:
> is there some way to synchronize the controlling host--such as waiting for an
> echo to complete after the pkill?  using a sleep makes me nervous

Possibly.  Are you proposing something as simple as running an 'echo ' on the
client, or is there something more complicated you had in mind?

http://codereview.chromium.org/6765030/diff/1/server/site_tests/network_VPN/0...
File server/site_tests/network_VPN/050StrongSwanGenesis (right):

http://codereview.chromium.org/6765030/diff/1/server/site_tests/network_VPN/0...
server/site_tests/network_VPN/050StrongSwanGenesis:24: [
"vpn_strongswan_config_templates", {
On 2011/03/31 17:11:27, Sam Leffler wrote:
> style nit; not sure you're using 4-space indent here like everywhere else?

I've removed this step altogether (unrelated to the indentation).  Any other
locations not up-to-snuff?

http://codereview.chromium.org/6765030/diff/1/server/site_tests/network_VPN/0...
server/site_tests/network_VPN/050StrongSwanGenesis:48: "  ip range =
192.168.1.128-192.168.1.254\n"
On 2011/03/31 17:11:27, Sam Leffler wrote:
> can this be automatically filled in?

Yes, it can.  I don't have it set up for being filled in because I was just
handed a set of 6 config files, and I don't know which knobs are likely to be
tuned.  It's a simple matter of textual replacement with the new implementation.

http://codereview.chromium.org/6765030/diff/1/server/site_tests/network_VPN/0...
server/site_tests/network_VPN/050StrongSwanGenesis:84: "connect-delay 5000\n"
On 2011/03/31 17:11:27, Sam Leffler wrote:
> much of the above is magic to me; please add comments

I agree, it's entirely magic.  I'd like to defer to Ken to provide comments on
what this all means.  I can provide a link to the StrongSwan documentation, but
it's incomplete, so it won't really be much help.

http://codereview.chromium.org/6765030/diff/1/server/site_tests/network_VPN/0...
server/site_tests/network_VPN/050StrongSwanGenesis:91: "kind" : "l2tpipsec",
On 2011/03/31 17:11:27, Sam Leffler wrote:
> indent

Addressed.

http://codereview.chromium.org/6765030/diff/1/server/site_tests/network_VPN/0...
server/site_tests/network_VPN/050StrongSwanGenesis:93: # @ipsecrets-ip@ should
not be replaced here.
On 2011/03/31 17:11:27, Sam Leffler wrote:
> don't understand this; did you mean "should not be used here"?

Yes; the @ipsecrets-ip@ is replaced with a runtime IP.  So, you shouldn't
provide an IP in the control file.

http://codereview.chromium.org/6765030/diff/1/server/site_tests/network_VPN/0...
server/site_tests/network_VPN/050StrongSwanGenesis:98: }}],
On 2011/03/31 17:11:27, Sam Leffler wrote:
> add \n? also is vpn_server_config synchronous? are there startup races?

I did nothing to make it synchronous or asynchronous.  I'm assuming that it is
synchronous.

I don't understand the '\n' comment.

http://codereview.chromium.org/6765030/diff/1/server/site_tests/network_VPN/0...
server/site_tests/network_VPN/050StrongSwanGenesis:103: [ "client_ping",       {
"ping_ip" : "192.168.1.99", # In xl2tpd.conf.
On 2011/03/31 17:11:27, Sam Leffler wrote:
> seems like you can factor out this fixed ip as we do for client/server ping's
> etc

How?  How will the code be able to differentiate between the default ping
(without the IP provided) and a ping of a StrongSwan IP (192.168.1.99) and a
ping of an OpenVPN IP (10.8.0.1)?  I suppose it might be able to use the
'vpn_kind' field, but perhaps you had something else in mind?

[kmixter1, 2011-04-05 21:51:33]

http://codereview.chromium.org/6765030/diff/14002/server/site_linux_server.py
File server/site_linux_server.py (right):

http://codereview.chromium.org/6765030/diff/14002/server/site_linux_server.py...
server/site_linux_server.py:73: "  left=%(@local-listen-ip@)s\n"
I assume this is the IP that the wired interface is on - based on the problems
you saw with connections.

http://codereview.chromium.org/6765030/diff/14002/server/site_linux_server.py...
server/site_linux_server.py:86: "  ip range = 192.168.1.128-192.168.1.254\n"
Is it ok to assume these addresses and the local ip are free for l2tp to assign
to DUT and the local IP for the tunnel?

http://codereview.chromium.org/6765030/diff/14002/server/site_linux_server.py...
server/site_linux_server.py:96: # XXX: or /etc/xl2tpd/xl2tp-secrets?
remove?

http://codereview.chromium.org/6765030/diff/14002/server/site_linux_server.py...
server/site_linux_server.py:100: # XXX: or /etc/xl2tpd/l2tp-secrets?
remove?

http://codereview.chromium.org/6765030/diff/14002/server/site_linux_server.py...
server/site_linux_server.py:110: "ms-dns  192.168.1.1\n"
Please remove these ms-dns and ms-wins lines since we're not testing that they
have any effect.

http://codereview.chromium.org/6765030/diff/14002/server/site_linux_server.py...
server/site_linux_server.py:154: elif self.vpn_kind == 'l2tpipsec': # aka
'strongswan'
again, strongswan != l2tpipsec.  strongswan == ipsec.  l2tp over ipsec involves
3 protocols, two of which are not ipsec/strongswan.

[thutt1, 2011-04-06 01:33:19]

On Tue, Apr 5, 2011 at 2:51 PM, <kmixter@chromium.org> wrote:

I can't actually update the comments on reitveld, getting a
'CapabilityDisabledError'.


>
> http://codereview.chromium.org/6765030/diff/14002/server/site_linux_server.py
> File server/site_linux_server.py (right):
>
>
>
http://codereview.chromium.org/6765030/diff/14002/server/site_linux_server.py...
> server/site_linux_server.py:73: "  left=%(@local-listen-ip@)s\n"
> I assume this is the IP that the wired interface is on - based on the
> problems you saw with connections.
>

Yes.  This allowed me to easily replace with '%defaultroute', '%any' and
specific IP numbers.  %any doesn't help.  Only %defaultroute or the server
IP number will work.



>
>
>
http://codereview.chromium.org/6765030/diff/14002/server/site_linux_server.py...
> server/site_linux_server.py:86: "  ip range =
>
> 192.168.1.128-192.168.1.254\n"
> Is it ok to assume these addresses and the local ip are free for l2tp to
> assign to DUT and the local IP for the tunnel?
>
>
I believe so.  The Wifi on the DUT is 192.168.2.xxx.


>
>
>
http://codereview.chromium.org/6765030/diff/14002/server/site_linux_server.py...
> server/site_linux_server.py:96: # XXX: or /etc/xl2tpd/xl2tp-secrets?
> remove?
>
>
>
http://codereview.chromium.org/6765030/diff/14002/server/site_linux_server.py...
> server/site_linux_server.py:100: # XXX: or /etc/xl2tpd/l2tp-secrets?
> remove?
>
>
Which one of these files is the one the system will actually read?  You
provided one, and the rspro comes configured with the other.  I didn't know
which one was the right one, so I just created both.



>
>
http://codereview.chromium.org/6765030/diff/14002/server/site_linux_server.py...
> server/site_linux_server.py:110: "ms-dns  192.168.1.1\n"
> Please remove these ms-dns and ms-wins lines since we're not testing
> that they have any effect.
>

Done.


>
>
>
http://codereview.chromium.org/6765030/diff/14002/server/site_linux_server.py...
> server/site_linux_server.py:154: elif self.vpn_kind == 'l2tpipsec': #
> aka 'strongswan'
> again, strongswan != l2tpipsec.  strongswan == ipsec.  l2tp over ipsec
> involves 3 protocols, two of which are not ipsec/strongswan.
>
>
Ok, removed.

If I can upload the changes, assuming no unexpected errors, they'll be up
shortly.


-- 
**Diagnosis: Dry, rough, tired hair caused by daily wear and tear.

[thutt, 2011-04-06 17:04:39]

I believe this change addresses all of the concerns mentioned.

The major changes from the last send are the following:

  o Now using wired connection on rspro / DUT for the test for
    StrongSwan tests.  OpenVPN tests still use the Wifi connection.

  o Re-adds facility to specify password, chapuser, chapsecret.
    Without this, 055SrongSwanBadPSK will fail.  Looks like this got
    lost during a battle with 'repo sync' and merge conflicts.

  o I now just write out /etc/xl2tpd/xl2tp-secrets &
    /etc/xl2tpd/l2tp-secrets.

  o All tests pass

 ---------------------------------------------------
    network_VPN                                   PASS
    network_VPN/network_VPN.000VPNGenesis         PASS
      client_ping_00_avg                          2.904
      client_ping_00_frequency                    2412
      client_ping_00_loss                         0
      client_ping_00_max                          3.500
      client_ping_00_min                          2.778
      client_ping_00_phymode                      802.11g
      client_ping_00_recv                         10
      client_ping_00_security                     none
      client_ping_00_xmit                         10
      client_ping_01_avg                          26.064
      client_ping_01_frequency                    2412
      client_ping_01_loss                         0
      client_ping_01_max                          108.028
      client_ping_01_min                          2.793
      client_ping_01_phymode                      802.11g
      client_ping_01_recv                         10
      client_ping_01_security                     none
      client_ping_01_xmit                         10
      connect_acquire_s                           6.132
      connect_assoc_s                             0.025
      connect_config_s                            0.378
      connect_frequency                           2412
      connect_select_s                            4.479
    network_VPN/network_VPN.001VPNNoKindSpecified PASS
    network_VPN/network_VPN.050StrongSwanGenesis  PASS
      client_ping_avg                             17.794
      client_ping_frequency                       2412
      client_ping_loss                            0
      client_ping_max                             21.895
      client_ping_min                             14.664
      client_ping_phymode                         802.11g
      client_ping_recv                            10
      client_ping_security                        none
      client_ping_xmit                            10
      connect_acquire_s                           6.051
      connect_assoc_s                             0.043
      connect_config_s                            0.359
      connect_frequency                           2412
      connect_select_s                            4.477
    network_VPN/network_VPN.055StrongSwanBadPSK   PASS
      connect_acquire_s                           6.080
      connect_assoc_s                             0.045
      connect_config_s                            0.069
      connect_frequency                           2412
      connect_select_s                            4.479
    ---------------------------------------------------
    Total PASS: 5/5 (100%)

  o site_linux_server.py has one more push to remove 'aka strongswan'
    comments, but the tree is presently locked.

[kmixter1, 2011-04-07 07:07:23]

LGTM on the vpn setup stuff with a suggestion to change file names.

http://codereview.chromium.org/6765030/diff/14002/server/site_linux_server.py
File server/site_linux_server.py (right):

http://codereview.chromium.org/6765030/diff/14002/server/site_linux_server.py...
server/site_linux_server.py:96: # XXX: or /etc/xl2tpd/xl2tp-secrets?
On 2011/04/05 21:51:33, kmixter1 wrote:
> remove?

In my build of xl2tpd it uses l2tp-secrets.

http://codereview.chromium.org/6765030/diff/27002/server/site_tests/network_V...
File server/site_tests/network_VPN/050StrongSwanGenesis (right):

http://codereview.chromium.org/6765030/diff/27002/server/site_tests/network_V...
server/site_tests/network_VPN/050StrongSwanGenesis:5: # An example of how to set
up a StrongSwan VPN from the Client (DUT),
Strongswan does IPsec.  OpenS/WAN, FreeS/WAN, Racoon and some other packages all
can do IPsec and are alternatives (Android uses Racoon).  We may some day want
to change to one of them or another.  So that's one reason not to use strongswan
in file names and comments.  Another is that IPsec itself can be set up in
tunnel mode, in which it alone is a VPN.  We may end up supporting that kind of
VPN (IKEv2 tunnel mode is becoming a more popular VPN alternative these days). 
In either of those cases, naming these files "strongswan" as an equivalence with
L2TP/IPsec will be confusing.

[thutt, 2011-04-07 15:47:40]

I've renamed the test control files as suggested by Ken, and removed an unused
config file from site_linux_server.py.

All tests still succeed in the VPN test suite.

[kmixter1, 2011-04-07 23:59:58]

LGTM