[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Fwd: Bug#616482: strongswan-ikev1: virtual ips not released if xauth name does not match id



Am 2011-05-15 13:30, schrieb Philipp Kern:
> On Fri, Apr 22, 2011 at 12:00:41AM +1000, Julien Cristau wrote:
>> On Sat, Apr 16, 2011 at 22:19:43 +0200, René Mayrhofer wrote:
>>> Would you prefer that I upload a new package with the fix to debian/rules network-manager handling with a new version or just again with the same one?
>> I think we'd prefer to just have a fix for #616482.
> This "I use debian/source/format v3 but in reality I don't" is a tad annoying.
> You should mark #616482 as fixed in unstable, too.  So NACK on the configure
> stuff.  ACK for the fix itself (a sane diff to the previous version in
> stable appreciated) 
Attached is only the patch to be applied to fix #616482. Additionally,
debian/rules needs this fix:

----------------------------------------------------------------
diff --git a/debian/rules b/debian/rules
index 65cade0..b88b838 100755
--- a/debian/rules
+++ b/debian/rules
@@ -53,7 +53,7 @@ endif
 # to do backports where the network-manager libs can not be installed, and
 # thus to just ignore build-deps).
 ifeq ($(shell test -d /usr/include/libnm-glib/ && echo yes),yes)
-  CONFIGUREARS += --enable-nm
+  CONFIGUREARGS += --enable-nm
 endif
 
 build: build-stamp
----------------------------------------------------------------

> and the NAT-T stuff could be done with a very good reason.
> ("Don't do it, it's insecure" vs. "hey, it's now common to do insecure stuff,
> so let's allow it" isn't exactly that convincing, yet.)
Well, unfortunately that's the practical use-case right now.
Without--enable-nat-transport, no smart phone will be able to connect
when it's behind a NAT, because most of them (including iPhone and
Android) use L2TP-over-IPsec by default and therefore rely on transport
connections. We know that there are some security weaknesses of NAT-T
for transport connections, which are (hopefully) alleviated by the L2TP
server (which should be the only allowed traffic through that IPsec
transport connection).

I would therefore prefer to have it enabled at this time, because you
otherwise prevent a lot of potential clients from connection to a
strongswan IPsec gateway. And yes, most commercial IPsec gateways (e.g.
included in Linux-based firewalls) enable this right now.

best regards,
Rene 


Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: