New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 716674 link

Starred by 1 user
Status: Assigned
Owner:
aashuto...@chromium.org
Cc:
█ dskaram@chromium.org
█ cernekee@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Task



Sign in to add a comment

Add L2TP/IPsec VPN interop test

Project Member Reported by cernekee@chromium.org, Apr 29 2017 
In M57 we bumped the strongSwan version to 5.5.0.  This passed autotests and also passed manual tests using a cloud based VPN gateway based on Ubuntu 16.04 (also strongSwan).  However, in  bug 707139 , several customers reported a regression.  The gateways they use were mentioned in the comments:

OP: Cisco ASA 5505
OP, c#1: Sophos UTM
c#7: Draytek Vigor 2850 SMB router (discontinued model)
c#10: Draytek Vigor 2960 SMB router (available on Amazon)
c#11: Cisco Meraki
c#12: Astrill consumer VPN service
c#13: Witopia consumer VPN service
c#20: PureVPN consumer VPN service
c#22: Customer OpenSwan installation on Ubuntu

The easiest way for me to reproduce the bug and control both sides of the connection was to set up a trial version of Sophos UTM in a VM.  I did so, and found two less-than-obvious compatibility issues, which have been corrected.  I do not have a way to test the other configurations, so there may be additional problems lurking.

At the very minimum I would like to add tests that cover the two items that have been fixed, so that if they regress again, we will catch the problem.  It would also be nice to test some of the other combinations listed above.

The three consumer services can be tested by purchasing a subscription, then verifying:

a) M57 fails
b) ToT passes
c) Both fixes (not just one or the other) are required to pass.  This requires a little hacking.

Comment 1 by cernekee@chromium.org, May 1 2017 

Two other test holes:

1) If the IPsec SA is not set up correctly, the kernel may fall back to transmitting the L2TP traffic unencrypted.  i.e. instead of the L2TP traffic being encapsulated in ESP, it will be sent in the clear.

The IPsec autotests do not currently seem to catch this, although most "real" VPN providers do.  We may want to add appropriate iptables rules to block L2TP traffic that escapes the IPsec tunnel.  These are the rules that are used for that purpose on my test server:

$ipt -F INPUT
$ipt -A INPUT -p udp -m policy --dir in --pol ipsec -m udp --dport l2tp -j ACCEPT
$ipt -A INPUT -p udp -m udp --dport l2tp -j REJECT --reject-with icmp-port-unreachable
$ipt -F OUTPUT
$ipt -A OUTPUT -p udp -m policy --dir out --pol ipsec -m udp --sport l2tp -j ACCEPT
$ipt -A OUTPUT -p udp -m udp --sport l2tp -j REJECT --reject-with icmp-port-unreachable


2) Ideally, autotest should exercise every ciphersuite that requires kernel support, in order to verify that the correct options were built into the kernel.  If autotest only exercises a subset of ciphers, it is possible that end users will discover at runtime that their kernel is missing support for the ciphersuite that got negotiated.

Comment 2 by benhenry@chromium.org, Aug 1

Status: Assigned (was: Untriaged)
►

Sign in to add a comment