[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

On Thu, May 19, 2011 at 01:34:10PM +0200, René Mayrhofer wrote:
> Attached is only the patch to be applied to fix #616482.

There was no such attachment, I'm afraid.

> 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
> ----------------------------------------------------------------

No, it doesn't.  That code isn't in stable.

> > ("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.

I guess I'd prefer to have the other stuff sorted out first and have a
look at this later.  It's strictly new functionality and albeit I
sympathise with it, this might need more intense consideration.

Kind regards
Philipp Kern

Attachment: signature.asc
Description: Digital signature

Reply to: