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 ipsecx
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 2331-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+lenny2OpenLDAP 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:
