On Mon, Jan 09, 2017 at 09:58:38PM +0100, Kristof Provost wrote: > On 9 Jan 2017, at 18:25, Marek Zarychta wrote: > > On Sun, Jan 08, 2017 at 07:08:10PM +0100, Kristof Provost wrote: > >> On 8 Jan 2017, at 15:55, Marek Zarychta wrote: > >> The problem description doesn’t ring any bells with me, but I’m > >> also > >> not sure > >> I’ve fully understood it. Can you document a minimal > >> reproduction > >> scenario, > >> with a pf.conf and perhaps network captures documenting the problem? > >> > >> There’s certainly not been a conscious decision to break UDP > >> reply-to. > >> > > > > Let me apologize, the problem wasn't previously properly identified. > > It > > seems to be more problem of UDP protocol implementation than PF issue. > > UDP sockets are opened and bound to address of the outgoing interface > > (interface which has a route to the client). Because the socket is not > > bound to the incoming interface, the PF reply-to rules couldn't be > > evaluated. By the way, TCP sockets are bound to the interface where > > the > > traffic arrives and everything works fine. > > This machine is i386 running 11.0-STABLE r311772 > > > > The problem remains unresolved. Are there any corresponding sysctls > > correcting this behavior and enabling the opportunity to use PF > > assisted > > symmetric routing scenario again? > > > How are your UDP listen sockets set up? > Are they bound to a specific interface, or are they listening on > 0.0.0.0?
Yes, socket is listening on 0.0.0.0, the client from outside network is initiating connection and initiating packet arrives on interface B, which is supposed only to communicate with devices on its own network (no additional routes go via this interface), so normally the reply would be passed via interface A having default gateway in scope and communication would fail. With the assistance of PF reply-to rule, TCP services are able to pass reply from interface B via other, second gateway: reply-to (B GW2). This functionality is currently broken for any UDP service, because UDP sockets are always opened on supposed_to_be_outgoing interface A and bound to the address of this interface, which is considered good from routing table perspective, but silently breaks PF reply-to for UDP. When the machine was running 9-STABLE reply-to had successfully been used to assist both TCP and UDP driven services. Is anyone reading this list still using reply-to rule for routing UDP traffic back via incoming interface? Maybe currently, the better place to discuss this questions would be freebsd-net, but the thread was initiated here. > > I’m afraid I’m still struggling to understand what your setup is, > what you’re > expecting to see and what you’re seeing instead. > > Regards, > Kristof -- Marek Zarychta
signature.asc
Description: PGP signature
