Date: Sun, 25 Mar 2007 22:04:08 +0200 From: Volker <volker@vwsoft.com> To: Andrew Thompson <thompsa@freebsd.org> Cc: Andre Albsmeier <Andre.Albsmeier@siemens.com>, freebsd-pf@freebsd.org Subject: Re: 6.2-STABLE: enc0 sees only outgoing packets in pf Message-ID: <4606D5B8.5000000@vwsoft.com> In-Reply-To: <20070324185928.GC45070@heff.fud.org.nz> References: <20070323115043.GA6991@curry.mchp.siemens.de> <46052572.9070402@vwsoft.com> <20070324185928.GC45070@heff.fud.org.nz>
next in thread | previous in thread | raw e-mail | index | archive | help
On 03/24/07 19:59, Andrew Thompson wrote:
> On Sat, Mar 24, 2007 at 02:19:46PM +0100, Volker wrote:
>> Andre,
>>
>> On 12/23/-58 20:59, Andre Albsmeier wrote:
>>> [Retrying on -pf...]
>>>
>>> (This is FreeBSD 6.2-STABLE as of yesterday using pf and FAST_IPSEC.)
>>>
>>> Just to make things clear: IPSEC works (as it did for years), I'm
>>> just not able to control the incoming packets with enc0 in pf.
>> On the other side, I've played with device enc a few weeks ago and
>> was asking for clarification on net@ but didn't get any reply.
>>
>> What's really strange is packets coming through an IPSec tunnel can
>> be seen by pf on device enc but packets are still passing through
>> even if device enc0 is down.
>
> The code does check if the interface is running but if its not then just
> passes the packet through unhindered. Do you think it should behave like
> you describe where the packets are dropped?
>
> See line 204, change the check to this
> if ((encif->if_drv_flags & IFF_DRV_RUNNING) == 0) {
> m_freem(*mp);
> return (-1);
> }
>
>> So from my experience device enc currently is a bit strange in
>> behavior (at least on -STABLE). Also AFAIR I haven't been able to
>> block packets on device enc0 using pf. I suspect device enc is
>> currently a bit of a hack and currently probably only useful for
>> packet / connection logging but not for real firewalling. You might
>> check out if you're able to block anything on enc0 (my memories
>> might be wrong) and play with it a bit.
>
> This should work as you say and if its not then thats a bug. Can you log
> the packets with pflog to check they are being blocked.
>
>
> Andrew
Andrew & Andre,
Ok, I've checked it and am able to confirm Andre's experience.
I've added the following rule to block ICMP traffic on the enc0
interface:
if_ipsec="enc0"
block quick log on $if_ipsec proto icmp from any to any
Then tried to create outgoing ICMP traffic and tcpdump showed it's
being blocked:
# tcpdump -netvli pflog0
tcpdump: WARNING: pflog0: no IPv4 address assigned
tcpdump: listening on pflog0, link-type PFLOG (OpenBSD pflog file),
capture size 96 bytes
rule 42/0(match): block out on enc0: (tos 0x0, ttl 64, id 49563,
offset 0, flags [none], proto: ICMP (1), length: 84) 10.1.1.1 >
10.2.1.1: ICMP echo request, id 35622, seq 0, length 64
But incoming traffic still passes:
rule 29/0(match): pass in on enc0: (tos 0x0, ttl 64, id 58618,
offset 0, flags [none], proto: ICMP (1), length: 84) 194.180.156.137
> 10.1.1.1: ICMP echo request, id 26909, seq 0, length 64
This example has been created on two peers acting as tunnel
endpoints. The ICMP traffic has been generated _AT_ the tunnel
endpoint machines (this traffic doesn't involve any other machine
except the tunnel endpoints).
What's really looking ugly, is another test...
In another scenario I blocked ICMP traffic at one tunnel endpoint
(on the enc0 interface), tried to create traffic from another
machine in the LAN to the remote tunnel endpoint.
This time it gives:
rule 40/0(match): block out on enc0: (tos 0x0, ttl 64, id 13524,
offset 0, flags [none], proto: ICMP (1), length: 84) 10.2.1.3 >
10.1.1.1: ICMP echo request, id 1811, seq 5, length 64
rule 40/0(match): block in on enc0: (tos 0x0, ttl 64, id 33495,
offset 0, flags [none], proto: ICMP (1), length: 84) 10.1.1.1 >
10.2.1.1: ICMP echo request, id 60966, seq 0, length 64
So there is a difference if the machine is receiving traffic through
the IPSec tunnel and being the destination for that traffic or just
a router. When acting as a router, traffic in both directions (in
and out) may be blocked using enc0.
If the tunnel endpoint is the final destination for the traffic, the
packets don't get blocked. This is looking like a bug.
Greetings,
Volker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4606D5B8.5000000>