netdev
[Top] [All Lists]

Re: Problem with IPSEC tunnel mode

To: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Subject: Re: Problem with IPSEC tunnel mode
From: Wolfgang Walter <wolfgang.walter@xxxxxxxxxxxxxxxxxxxx>
Date: Fri, 22 Apr 2005 11:37:38 +0200
Cc: netdev@xxxxxxxxxxx
In-reply-to: <20050422010445.GA10918@xxxxxxxxxxxxxxxxxxx>
Organization: Studentenwerk München
References: <E1DObFc-0000je-00@xxxxxxxxxxxxxxxxxxxxxxxx> <200504220240.31280.wolfgang.walter@xxxxxxxxxxxxxxxxxxxx> <20050422010445.GA10918@xxxxxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: KMail/1.7.2
Am Freitag, 22. April 2005 03:04 schrieben Sie:
> On Fri, Apr 22, 2005 at 02:40:31AM +0200, Wolfgang Walter wrote:
> > > Although you probably have rp_filter turned, but please check
> > >
> > > cat /proc/sys/net/ipv4/conf/eth3/rp_filter
> > >
> > > anway.
>
> Please do this check.
>
> > > > src 10.148.0.0/23 dst 10.0.25.210/32
> > > >  dir fwd priority 0
> > >
> > > There you go.  This policy trumps your other policy.  This one
> > > says that forwarded traffic matching it must carry no tunnel
> > > IPsec transforms.  Therefore all IPsec packets matching it will
> > > be dropped.
> >
> > I don't understand that. 10.148.0.0/23 is 10.148.0.0-10.148.1.255, isn't
> > it? But 10.148.4.0/28 (is 10.148.4.0-10.148.4.15) is not within it.
>
> Sorry, I misread the netmask.  I was right about the problem though :)
> Further down it says
>
> src 0.0.0.0/0 dst 10.0.25.210/32
>  dir fwd priority 0
>
> which still trumps your IPsec policy.
>
> Cheers,

Oh yes, me stupid.

They are needed (these hosts are allowed to communicate with outside world 
unencrypted), but priority is wrong.

Our rules are generated from a description of the network. And if we connect 
10.0.25.210 directly to C and change netmask to 30 instead of 32 our 
generator assumes that this system is not allowed to communicate with outside 
world and does not generate this rule.

Thanks a lot, sorry for bothering you. I should have seen this difference. But 
probably I would not have recognized that as a problemebecause I assumed that 
in and fwd allow-rules only applies to non-ipsec packets which of course is 
not logical :-).

-- 
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
Leopoldstraße 15
80802 München


<Prev in Thread] Current Thread [Next in Thread>