On Wed, 14.04.2010 at 16:14:32 +0200, Markus Friedl
wrote:
> yes, just writing an appropriate isakmpd.policy file should work::
>
> Authorizer: "POLICY"
> Conditions: app_domain == "IPsec policy" &&
> ( remote_filter != "000.000.000.000-255.255.255.255" ) -> "true";
I had configured this
yes, just writing an appropriate isakmpd.policy file should work::
Authorizer: "POLICY"
Conditions: app_domain == "IPsec policy" &&
( remote_filter != "000.000.000.000-255.255.255.255" ) -> "true";
On Tue, Apr 13, 2010 at 12:10:27PM +1000, Damien Miller wrote:
> On Mon, 12 Apr 2010, Toni
Hi,
[ still appropriate for tech@ ? ]
[ Cc: list clipped - we are all on tech@, anyway, aren't we? ]
On Tue, 13.04.2010 at 11:10:00 +0100, Stuart Henderson
wrote:
> flow esp in from 0.0.0.0/0 to somenetwork/24 type bypass
> flow esp out from somenetwork/24 to 0.0.0.0/0 type bypass
> flow esp in
On 2010/04/13 10:24, Toni Mueller wrote:
> Working:
>
>
> flow esp in from 172.18.100.139 to 0.0.0.0/0 peer 87.186.99.179 srcid
> gatewayip/32 dstid uf...@example.com type use
> flow esp out from 0.0.0.0/0 to 172.18.100.139 peer 87.186.99.179 srcid
> gatewayip/32 dstid uf...@example.com
Hi Damien,
On Tue, 13.04.2010 at 12:10:27 +1000, Damien Miller wrote:
> On Mon, 12 Apr 2010, Toni Mueller wrote:
> > with your comments, I have produceds a second version of the patch,
> > which includes the following changes:
>
> IPsec isn't really my area, but some questions:
>
> 1) Why are t
On Mon, 12 Apr 2010, Toni Mueller wrote:
> Hi,
>
> with your comments, I have produceds a second version of the patch,
> which includes the following changes:
IPsec isn't really my area, but some questions:
1) Why are these flows "illegal"? 0/0 -> 0/0 seems like it might have a
use as a shortha
Hi,
On Mon, 12.04.2010 at 09:37:18 +0200, Toni Mueller
wrote:
> On Mon, 12.04.2010 at 06:54:31 +0200, Bret S. Lambert
> wrote:
> > $ man 9 inet_ntoa
> > man: no entry for inet_ntoa in section 9 of the manual.
>
> Patrick is right, though.
I have to retract this statement after seeing that in
Hi,
with your comments, I have produceds a second version of the patch,
which includes the following changes:
On Sun, 11.04.2010 at 20:47:38 +0200, Toni Mueller
wrote:
> * No IPv6 support (I have no clue).
* tried to add IPv6 support
* Logging is still not very useful, but at least it does no
Hi,
On Mon, 12.04.2010 at 06:54:31 +0200, Bret S. Lambert
wrote:
> On Sun, Apr 11, 2010 at 01:43:11PM -0700, patrick keshishian wrote:
> > On Sun, Apr 11, 2010 at 09:40:45PM +0200, Toni Mueller wrote:
> > > I already suspected something like this, but this behaviour is not
> > > documented in th
On Mon, Apr 12, 2010 at 06:54:31AM +0200, Bret S. Lambert wrote:
> On Sun, Apr 11, 2010 at 01:43:11PM -0700, patrick keshishian wrote:
> > On Sun, Apr 11, 2010 at 09:40:45PM +0200, Toni Mueller wrote:
> > > Hi Patrick,
> > >
> > > On Sun, 11.04.2010 at 11:58:54 -0700, patrick keshishian
> > > wr
On Sun, Apr 11, 2010 at 01:43:11PM -0700, patrick keshishian wrote:
> On Sun, Apr 11, 2010 at 09:40:45PM +0200, Toni Mueller wrote:
> > Hi Patrick,
> >
> > On Sun, 11.04.2010 at 11:58:54 -0700, patrick keshishian
> > wrote:
> > > inet_ntoa will return pointer to a static buffer. Each call
> > >
On Sun, Apr 11, 2010 at 09:40:45PM +0200, Toni Mueller wrote:
> Hi Patrick,
>
> On Sun, 11.04.2010 at 11:58:54 -0700, patrick keshishian
> wrote:
> > inet_ntoa will return pointer to a static buffer. Each call
> > TO IT Will override thsi buffer with the new IP info.
>
> I already suspected som
Hi Patrick,
On Sun, 11.04.2010 at 11:58:54 -0700, patrick keshishian
wrote:
> inet_ntoa will return pointer to a static buffer. Each call
> TO IT Will override thsi buffer with the new IP info.
I already suspected something like this, but this behaviour is not
documented in the man page.
:(
I
On Sun, Apr 11, 2010 at 08:47:38PM +0200, Toni Mueller wrote:
> Hi,
>
> I've created a rough patch that should fix the immediate problem, but
> is certainly far from perfect (yet). Things to note:
>
> * No IPv6 support (I have no clue).
> * No useful error messages - I want to log data about the
Hi,
I've created a rough patch that should fix the immediate problem, but
is certainly far from perfect (yet). Things to note:
* No IPv6 support (I have no clue).
* No useful error messages - I want to log data about the offending
site, so admins can go after them.
* For some reason I don't yet
On 2010/04/02 20:32, Toni Mueller wrote:
> I'm trying to prevent the two flows
>
> flow esp in from 0.0.0.0/0 to 0.0.0.0/0 peer 87.186.99.179 srcid gatewayip/32
> dstid uf...@example.com type use
> flow esp out from 0.0.0.0/0 to 0.0.0.0/0 peer 87.186.99.179 srcid
> gatewayip/32 dstid uf...@examp
Hello,
I'm currently hacking on /usr/src/sys/net/pfkey* because I urgently
need to prevent the kernel from installing SAs with the value "default"
for both sides. In case I got the terminology wrong, I need to prevent
this situation, as it brings down networking completely:
> 0/00
17 matches
Mail list logo
