https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268717
--- Comment #19 from d...@rabson.org ---
Testing with ipfirewall's ipnat module shows the exact same pattern where the
rule matches the initial connection attempt and translates the destination
address and port but the reply does not reverse
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268717
--- Comment #18 from d...@rabson.org ---
(In reply to Kristof Provost from comment #17)
> Sort of. I find it more useful to think about when the packets pass through
> which parts of the stack. That does imply a direction (i.e. PF_IN/PF_OU
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268717
--- Comment #17 from Kristof Provost ---
(In reply to dfr from comment #16)
> As far as I understand the code (which is not very well TBH), both nat and
> rdr rules rely on both PF_IN and PF_OUT events but differ on which event
> triggers
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268717
--- Comment #16 from d...@rabson.org ---
As far as I understand the code (which is not very well TBH), both nat and rdr
rules rely on both PF_IN and PF_OUT events but differ on which event triggers
state creation: PF_IN for rdr and PF_OUT fo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268717
--- Comment #15 from Kristof Provost ---
(In reply to dfr from comment #14)
Right, but rdr very much expects to be used on inbound traffic only.
I believe the relevant code to be in pf_get_translation(), where we only look
at the RDR rulese
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268717
--- Comment #14 from d...@rabson.org ---
For my use-case, I need to be able to change both destination address and port
and currently the nat rule only allows changing the address. Also, I'm not sure
that nat will work here since it re-write
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268717
--- Comment #13 from Kristof Provost ---
Oh. Wait.
The setup in comment #1 tries to use 'rdr' to redirect an outbound packet. But
the pf.conf man page says: "Then either the rdr rules are evaluated on an
inbound
packet or the nat rules on
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268717
--- Comment #12 from Kristof Provost ---
(In reply to dfr from comment #11)
I've poked at it for a little bit more, but I think I've mostly succeeded in
confusing myself more. I think part of the issue is that we only create the
state on th
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268717
--- Comment #11 from d...@rabson.org ---
I was testing this again today with a back-port of my patch to stable/13 and it
seems to work fairly well so far. It doesn't work if the source address is
127.0.0.1 since the redirected packet still h
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268717
--- Comment #10 from d...@rabson.org ---
You are right - in this case, r->rt will be NULL. I'm not particularly
advocating for my attempted fix but I do think this feature is useful - I
originally wanted this to work for 'publishing' ports i
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268717
--- Comment #9 from Kristof Provost ---
(In reply to dfr from comment #8)
We don't hit pf_route() in this scenario, so I don't think that'd help.
I'm going to have to find a bit of time to sit down and concentrate on this
before I can say
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268717
--- Comment #8 from d...@rabson.org ---
I was also wary of adding complexity to pf_test although there is some
precedent here - pf_route does recurse back to pf_test. The other idea I had
was to add a second packet filter call from ip_input
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268717
Kristof Provost changed:
What|Removed |Added
CC||k...@freebsd.org
--- Comment #7
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268717
--- Comment #6 from d...@rabson.org ---
Created attachment 239274
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=239274&action=edit
possible fix for redirects initiated by localhost
Redirect rules are triggered on PF_IN events to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268717
--- Comment #5 from d...@rabson.org ---
Turns out I was missing 'sysctl net.link.bridge.pfil_member=1' for the two
jails redirecting via a bridge scenario so ignore that part. Adding this
doesn't affect the original scenario with the host or
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268717
--- Comment #4 from d...@rabson.org ---
The second scenario with two vnet jails on the same bridge is possibly the
bridge 'helping' by delivering the SYN+ACK reply directly, without allowing PF
to re-write. Adding debug printfs to pf seems t
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268717
--- Comment #3 from d...@rabson.org ---
Further testing show more strangeness. If I add a second vnet jail on the same
bridge and attempt the telnet that should redirect, it also fails. The rule
matches when the host receives the SYN and is
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268717
--- Comment #2 from d...@rabson.org ---
Created attachment 239234
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=239234&action=edit
second test scenario showing redirect failing if both ends are on the same
bridge
--
You are rec
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268717
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|pf@FreeBSD.org
--
You are receivin
19 matches
Mail list logo