tun-based VPNs using the "subnet" topology are wrongly sending ICMP redirects

Bug #907828 reported by Simon Déziel
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
openvpn (Debian)
Fix Released
Unknown
openvpn (Ubuntu)
Fix Released
Medium
Simon Déziel
Oneiric
Won't Fix
Undecided
Unassigned
Precise
Fix Released
Medium
Simon Déziel

Bug Description

[Impact]
<fill me in with explanation of severity and frequency of bug on users and justification for backporting the fix to the stable release>

[Development Fix]
<fill me in with an explanation of how the bug has been addressed in the development branch, including the relevant version numbers of packages modified in order to implement the fix. >

[Stable Fix]
<fill me in by pointing out a minimal patch applicable to the stable version of the package.>

[Text Case]
<fill me in with detailed *instructions* on how to reproduce the bug. This will be used by people later on to verify the updated package fixes the problem.>
1.
2.
3.
Broken Behavior:
Fixed Behavior:

[Regression Potential]
<fill me in with a discussion of likelihood and potential severity of regressions and how users could get inadvertently affected.

[Original Report]
When a tun-based VPN is using the subnet topology, the communication between clients can confuse the routing code that will wrongly emit ICMP redirects. This problem is very well described here http://backreference.org/2010/05/02/controlling-client-to-client-connections-in-openvpn/. The same link also provides the workaround (disable ICMP redirect on the TUN device).

This problem affects Lucid to Precise (Hardy's version does not support the subnet mode).

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: openvpn 2.1.3-2ubuntu3
ProcVersionSignature: Ubuntu 2.6.38-13.53-generic 2.6.38.8
Uname: Linux 2.6.38-13-generic x86_64
Architecture: amd64
Date: Thu Dec 22 11:34:08 2011
ProcEnviron:
 LANGUAGE=en_US:en
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: openvpn
UpgradeStatus: No upgrade log present (probably fresh install)

Related branches

Revision history for this message
Simon Déziel (sdeziel) wrote :
Changed in openvpn (Ubuntu):
assignee: nobody → Simon Déziel (sdeziel)
Revision history for this message
Dave Walker (davewalker) wrote :

@simon, Thanks for the bug report and the associated branch. I'd quite like to get this resolved in Debian first, then merge it into Precise (current development version), then SRU it back to Oneiric.

Are you able to submit this to Debian, or would you like some support?

Thanks.

Changed in openvpn (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Stéphane Graber (stgraber) wrote :

Targetted the bug to both Oneiric and Precise.

Commented in the merge proposal that the branch looks good for an SRU but we first need this fixed in Precise and ideally also in Debian.

I'm now directly subscribed to this bug so please let us know if you need any help.

Thanks

Revision history for this message
Simon Déziel (sdeziel) wrote :

The bug was reported in Debian (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656241). The patch was also attached to the Debian bug. Let me know if I need to do something else, thanks.

Revision history for this message
Stéphane Graber (stgraber) wrote :

Thanks, I'll monitor this bug and once LP detects the bug has been fixed in Debian, sync/merge the package from Debian, then we can continue with the SRU.

Changed in openvpn (Debian):
status: Unknown → New
Bryce Harrington (bryce)
description: updated
Revision history for this message
Simon Déziel (sdeziel) wrote :

A reworked patch is now available in OpenVPN 2.2.1-5 in Debian. Is it too late to sync/merge into Precise ?

Revision history for this message
Stéphane Graber (stgraber) wrote :

As it's on the same upstream release, it should still be fine to merge from Debian. I can try and have a look at it over the weekend.

Changed in openvpn (Debian):
status: New → Fix Released
Revision history for this message
Stéphane Graber (stgraber) wrote :

A test package of the Debian merge has been uploaded to https://launchpad.net/~stgraber/+archive/experimental/+packages

Revision history for this message
Simon Déziel (sdeziel) wrote :

@Stéphane, your test package works well on a freshly installed Precise VM. Thanks

Revision history for this message
Stéphane Graber (stgraber) wrote :

Perfect, will upload on Friday then

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package openvpn - 2.2.1-5ubuntu1

---------------
openvpn (2.2.1-5ubuntu1) precise; urgency=low

  * Merge from Debian unstable. Remaining changes: (LP: #907828)
    + debian/openvpn.init.d:
      - Do not use start-stop-daemon and </dev/null to avoid blocking boot.
      - Show per-VPN result messages.
      - Add "--script-security 2" by default for backwards compatabliity.
    + debian/control: Add lsb-base >= 3.2-14 to allow status_of_proc()

openvpn (2.2.1-5) unstable; urgency=low

  * Avoid sending ICMP redirects when using tun devices and "subnet"
    topology. Thanks Simon Deziel for testing and the patch.
    (Closes: #656241)
    The init.d script will set all.send_redirects=0 when using "dev tun"
    and "topology subnet". More info in README.Debian.
  * Several manpage fixes

openvpn (2.2.1-4) unstable; urgency=low

  * Use dpkg-buildflags to fill CFLAGS in ./configure. (Closes: #655130)
  * debian/rules: Moved to dh.
  * debian/rules: Changed DEB_BUILD_ARCH_OS with DEB_HOST_ARCH_OS.
  * Removed quilt Build-Depends.
  * debian/openvpn.default: Clarify what "vpn name" refers to.
    (Closes: #657610)
 -- Stephane Graber <email address hidden> Sat, 25 Feb 2012 21:08:48 -0500

Changed in openvpn (Ubuntu Precise):
status: New → Fix Released
Revision history for this message
Rolf Leggewie (r0lf) wrote :

oneiric has seen the end of its life and is no longer receiving any updates. Marking the oneiric task for this ticket as "Won't Fix".

Changed in openvpn (Ubuntu Oneiric):
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.