On 01/09/17 17:17, Marek Zarychta wrote:
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).
Are you saying that your network looks approximately like this and there
is no route to the client network where X resides on your server:
iface-A--<default route>--GW1
iface-B--_local network_--GW2--_client X_
Client X originates a UDP "connection" to B and that return traffic to X
leaves interface A despite your reply-to rule.
I would be very interested to know:
1. whether the reply-to rule actually matches on the inbound traffic.
You can make the rule log and tcpdump on the pflog0 interface. I
believe the -e option to tcpdump will show the rule that matched.
2. the output of "pfctl -s sta |grep IP_of_X"
3. what software you're using for your UDP server. I can try to
reproduce your issue.
Ian
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
--
Cape Augusta Digital Properties, LLC a Cape Augusta Company
*Breach of confidentiality & accidental breach of confidentiality *
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the system manager.
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and
delete this e-mail from your system. If you are not the intended recipient
you are notified that disclosing, copying, distributing or taking any
action in reliance on the contents of this information is strictly
prohibited.
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[email protected]"
