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