On 2015-10-11 13:16:08 (+0200), Miłosz Kaniewski
wrote:
> I have FreeBSD machine which forwards packets between host1 and host2. This
> machine has also an additional interface (em2) which act as span interface
> - all traffic between host1 and host2 is copied into it.
> To achieve this scenario
2015-10-11 23:19 GMT+02:00 Kristof Provost :
>
> From a quick test, yes, it looks like something's broken, or we're both
> misunderstanding something.
>
> My system complains 'arpresolve: can't allocate llinfo for 8.8.8.8 on
> vtnet1'.
> I think the issue is that we still try to resolve the destin
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
2015-10-12 16:28 GMT+02:00 David DeSimone :
> 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 th
On 2015-11-07 21:36:28 (+0100), Miłosz Kaniewski
wrote:
> 2015-10-12 16:28 GMT+02:00 David DeSimone :
> 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.
>
On 2015-11-08 01:03:15 (+0100), Kristof Provost wrote:
> It certainly looks wrong. I can also reproduce your observation that
> this doesn't happen when 'no state' is added to the rule.
>
I've been looking at this for a bit, and I think I understand what's
happening now.
With this rule for examp
2015-11-08 20:29 GMT+01:00 Kristof Provost :
> On 2015-11-08 01:03:15 (+0100), Kristof Provost wrote:
> > It certainly looks wrong. I can also reproduce your observation that
> > this doesn't happen when 'no state' is added to the rule.
> >
> I've been looking at this for a bit, and I think I und
On 2015-11-15 13:04:27 (+0100), Miłosz Kaniewski
wrote:
> > I suppose we could mark packets in pf_route() as M_SKIP_FIREWALL, but
> > that might have other consequences.
> >
> >
> I looked into old pf code to look for some tips. First commit worth
> mentioning is 1.215
> (I took commit numbers fr
On 2015-11-15 18:33:49 (+0100), Kristof Provost wrote:
> On the other hand, perhaps there's something we can do about the state
> matching. The problems all start because we match state on the
> duplicated packet. That's not correct, because the rule is set on e.g.
> em0, but the duplicated packet
2015-11-22 20:14 GMT+01:00 Kristof Provost :
> On 2015-11-15 18:33:49 (+0100), Kristof Provost wrote:
> > On the other hand, perhaps there's something we can do about the state
> > matching. The problems all start because we match state on the
> > duplicated packet. That's not correct, because th
10 matches
Mail list logo
