Package: openswan
Version: 1:2.4.12+dfsg-1.3+lenny2
Severity: important
In trying to get an L2TP/IPSec tunnel up from my Android-based phone to
my server for use when on untrusted WiFi I've obviously been testing it
at home.
So I have a WiFi Access Point on 192.168.11.0/24, my server on .1, the
WAP on .2 and my phone on .4. When I start up the connection pluto
decides to call _uproute in order to add a host route for
192.168.11.4/32... to whatever device pluto is listening on connections
for. This of course is *not* the same device as the 192.168.11.0/24
network is on, so I end up with:
00:57:02 1$ ip -4 route
82.69.184.122 dev ethpriv scope link
82.69.184.123 dev ethpriv scope link
82.69.184.124 dev ethpriv scope link
192.168.11.4 dev ethpub scope link
82.69.184.125 dev ethpriv scope link
82.69.184.120/29 dev ethpub proto kernel scope link src 82.69.184.121
192.168.1.0/24 dev ethpriv proto kernel scope link src 192.168.1.162
192.168.11.0/24 dev ethwap proto kernel scope link src 192.168.11.1
default via 82.69.184.126 dev ethpub
82.69.184.120/29 is my ISP-provided network and route to the internet.
I had a similar thing happen when testing with my 192.168.1.0/24 local
network. I'd end up with a:
192.168.11.4 dev ethpriv scope link
route, blocking my server from talking back to the phone.
Given any device connecting to OpenSwan/pluto can be from some
arbitrary IP I think it can be assumed that my server will already have
a route back to it. So why bother even attempting to add this route at
all ? It seems to be a leftover from the other/prior IPSec
implementation where the connection would come in over an ipsec<x>
device rather than just staying on the normal device as it does now.
Anyway, I've worked around this for now by modifying
/usr/lib/ipsec/_uproute so that uproute() looks like:
# utility functions for route manipulation
# Meddling with this stuff should not be necessary and requires great care.
uproute() {
if [ "${PLUTO_INTERFACE}" == "${defaultroutephys}" ];
then
return
fi
doroute add
ip route flush cache
}
I'd guess the most common way to setup OpenSwan is listening on the
default route interface, but can also see setups where it might be on an
internal network (think of a secure internal network with a WAP
attached, firewalled off other than IPSec, and using tunnels to get WAP
clients onto that secure network). So, this isn't a perfect fix.
Really I think it needs the whole code reviewing to only even attempt
these routes if the IPSec connection has resulted in a special network
interface for the connection in question. This does not happen with my
setup using a 2.6.35.4 kernel and Debian lenny all up to date.
I did glance quickly over the squeeze/testing changelog for Openswan
and couldn't spot anything that might have fixed this (but I only
searched quickly on 'route'), so this bug may well still be in that
version too.
-- System Information:
Debian Release: 5.0.6
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.35.4amd64 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages openswan depends on:
ii bsdmainutils 6.1.10 collection of more utilities from
ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy
ii debianutils 2.30 Miscellaneous utilities specific t
ii host 20000331-9 utility for querying DNS servers
ii iproute 20080725-2 networking and traffic control too
ii ipsec-tools 1:0.7.1-1.3+lenny2 IPsec tools for Linux
ii libc6 2.7-18lenny4 GNU C Library: Shared libraries
ii libcurl3 7.18.2-8lenny4 Multi-protocol file transfer libra
ii libgmp3c2 2:4.2.2+dfsg-3 Multiprecision arithmetic library
ii libldap-2.4-2 2.4.11-1+lenny2 OpenLDAP libraries
ii libpam0g 1.0.1-5+lenny1 Pluggable Authentication Modules l
ii libssl0.9.8 0.9.8g-15+lenny8 SSL shared libraries
ii openssl 0.9.8g-15+lenny8 Secure Socket Layer (SSL) binary a
openswan recommends no packages.
Versions of packages openswan suggests:
ii curl 7.18.2-8lenny4 Get a file from an HTTP, HTTPS or
pn openswan-modules-source | <none> (no description available)
-- debconf information:
openswan/existing_x509_key_filename:
openswan/x509_state_name:
openswan/rsa_key_length: 2048
openswan/restart: true
openswan/start_level: earliest
* openswan/enable-oe: false
openswan/existing_x509_certificate: false
openswan/existing_x509_certificate_filename:
* openswan/create_rsa_key: false
openswan/x509_email_address:
openswan/x509_country_code: AT
openswan/x509_self_signed: true
openswan/x509_organizational_unit:
openswan/x509_locality_name:
openswan/x509_common_name:
openswan/rsa_key_type: x509
openswan/x509_organization_name:
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
