Date: Sat, 7 Nov 2015 21:36:28 +0100 From: =?UTF-8?Q?Mi=C5=82osz_Kaniewski?= <milosz.kaniewski@gmail.com> To: freebsd-pf@freebsd.org Subject: Re: Creating span interface using 'dup-to' option Message-ID: <CAC4mxp77FrDvT%2B1J%2BdQqrgc_ji3vmbMZOkYnXae%2BD2L1PanK1g@mail.gmail.com> In-Reply-To: <SN1PR08MB18210835207E194932EBB485BA310@SN1PR08MB1821.namprd08.prod.outlook.com> References: <CAC4mxp5ar-Kvp5238VRfKEL6FiVOg7XXzmv8fE-zdEFYRk7cAw@mail.gmail.com> <SN1PR08MB18210835207E194932EBB485BA310@SN1PR08MB1821.namprd08.prod.outlook.com>
next in thread | previous in thread | raw e-mail | index | archive | help
2015-10-12 16:28 GMT+02:00 David DeSimone <ddesimone@verio.net>:
> The man page makes it clear that "dup-to" acts just like "route-to",
> except that the original packet still routes the way it would have. The
> implication being that "dup-to" needs to determine where to route the new
> packet.
>
> This means that the more useful form of this is likely to be:
>
> pass out on em0 dup-to ( em2 X.X.X.X ) no state
>
> Where "X.X.X.X" is the IP of the host connected via em2 that will be
> receiving the duplicated packet.
>
> The difference between using a bridge to accomplish this, vs. pf, is that
> pf operates at layer 3 and will not preserve the layer 2 mac headers,
> whereas bridge will preserve these.
>
> Hopefully this will fit your requirements.
>
>
Hi,
inspired by answer from David DeSimone I've decided to make some
deeper research. And I found out that dup-to option is not broken, as
I previously thought. It just works different than I initially expected.
Its
behaviour may be described in such way:
1. Original packet is caught by pf rule with dup-to option.
2. Original packet is send as it would normally be (through interface that
is
determined by looking into system routing table).
3. Duplicated packet is created. It is identical with original packet and it
differ only by output interface that it should use to send packet. For
duplicated packet this interface is specified in 'dup-to' rule (no system
routing table is looked).
4. Now system know which interface use to send duplicated packet but doesn't
know what destination MAC address it should use. So now two things can
happen:
A.) Lets say that our rule don't have next-hop parameter specified, e.g.
pass out on em0 dup-to em2
Operating system will now send ARP request on dup-to interface (in this
example it will be em2). IP address that ARP will ask about will be the
destination IP address of duplicated packet. So in 99% cases there will
be
no ARP response for this ARP request on that interface. Why? Because any
response would only came if this IP would by directly accessible through
this interface. And in most situations duplicated packets will have
destination IP addresses that is not directly accessible through
'dup-to'
interface. If they would be directly accessible through this interface
then
using 'dup-to' wouldn't have any sense in my opinion.
B.) Now lets say that our rule have next-hop IP specified, e.g.
pass out on em0 dup-to (em2 10.0.0.1)
This time operating system will try to find out MAC address of exactly
this
IP (10.0.0.1). So it will send ARP request for this IP address on
'dup-to'
interface. And if this IP address will be accessible directly through
this
interface then ARP response would be received and finally 'dup-to' would
start to properly duplicate packets.
So my original post described situation A, and as I explained above it
couldn't
work. Using 'dup-to' with next-hop (as in example B) is the only way to
make it
works. But it has one disadvantage as it can only be used in situation when
there is a computer with configured IP address directly accessible through
'dup-to' interface ('directly' mean that both computers are in the same
subnetwork). However in some situations computer waiting for packets won't
have
any IP address configured. This is how many IDS/IPS systems works as they
interfaces are set in promiscuous mode and no IP address is set on them.
I think that bug 203715 I submitted before, can be now closed. 'dup-to'
option
works, only different than I expected. But I am not the only one who
misunderstood how 'dup-to' works - I found several other posts on FreeBSD
and
OpenBSD mail lists where people have problem similar to mine. Maybe adding
some more info to pf.conf(5) would be a good idea.
########
But unfortunately I still have a problem with 'dup-to' option. I hope you
don't
mind if I will describe it here, as it is still connected with network
scheme I
used in my first post.
As I explained 'dup-to' option is useful only when it is used with next-hop
parameter. So in my configuration from first post I made these changes:
pass out on em0 dup-to (em2 10.0.0.1) no state
pass out on em1 dup-to (em2 10.0.0.1) no state
IP address 10.0.0.1 is accessible through em2 interface. And with that
configuration everything works fine and duplicated packets are send through
em2
interface without any problems. But I tried to make a little change and used
one stateful rule:
pass out on em1 dup-to (em2 10.0.0.1)
And with that configuration something strange is happening. Packets are
still
duplicated and correctly sent through em2 interface but there are too much
of
them. It looks like some of the packets are duplicated to many times. Lets
say
I send ICMP ping that goes through em1. On em2 i should see two packets:
ICMP
request and ICMP reply. But I see two identical ICMP requests and one ICMP
reply. So there are 3 packets instead of two.
I don't want to fill bug report yet. First I would like to hear your opinion
about this behaviour. And it would be great if someone would check similar
situation and confirm that this problem really exists.
Thanks for your help.
Best regards.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAC4mxp77FrDvT%2B1J%2BdQqrgc_ji3vmbMZOkYnXae%2BD2L1PanK1g>