On 04/07/2020 14:59, Brian Brombacher wrote:
On Jul 3, 2020, at 3:34 AM, Kapetanakis Giannis <bil...@edu.physics.uoc.gr>
wrote:
Hi,
My setup in relayd is like this:
redirect radius {
listen on $radius_addr udp port radius interface $ext_if
pftag RELAYD_radius
sticky-address
forward to <radius> mode least-states check icmp demote carp
}
redirect radacct {
listen on $radius_addr udp port radacct interface $ext_if
pftag RELAYD_radius
sticky-address
forward to <radius> mode least-states check icmp demote carp
}
I want to combine it in one redirect but the redirect forwards it to the first
port defined in listen for both radius and radacct ports.
redirect radius {
listen on $radius_addr udp port radius interface $ext_if
listen on $radius_addr udp port radacct interface $ext_if
pftag RELAYD_radius
sticky-address
forward to <radius> mode least-states check icmp demote carp
}
Is there another way to do this or do I have to stick with two redirects?
thanks,
Giannis
Hi Giannis,
I have not tested your config or my advice for your config; however, my
assumptions are sticky-address is needed per udp port conversation for radius.
By contrast, if sticky was needed for the combination of both radius/radacct on
same backend host per source address or address/port, you cannot achieve that
reliably with least-states. I don’t know the radius protocols enough to know
the requirements.
Here’s my question after all that dribbling:
Have you tried using either of the following config options?
forward to destination
forward to nat
IIRC, in the past I had multiple TCP relay ports going to their specified ports
on the backend. I only needed to split things by address family (v4/6) for my
own purposes. I cannot remember if the directives above took port into
consideration. It might not be a far stretch to make that feasible with code
changes but I haven’t seen the relayd code paths in question so that’s a
complete guess (but I’m on my way to check ;). Also since I concentrated on
TCP relays, I don’t know how effective these directives would be for redirects.
My end config has separate relays per TCP service except passive FTP relaying.
Also, make sure your pf.conf has the right anchor. Only mentioning it because
your original email skips this detail. I doubt this would be missing if you
have a working setup already, so ignore if so.
Cheers,
Brian
Thanks for the answer Brian,
You 're probabaly right and least-states might not be the best choice.
My setup is a working one, but it only has one server (for now) in the
backend table so this hasn't come up so far.
I guess the best one would be
mode source-hash [key]
least-states [sticky-address]
The least-states option selects the address with the least active
states from a given address pool and considers given weights
associated with address(es). Weights can be specified between 1
and 65535. Addresses with higher weights are selected more often.
sticky-address can be specified to ensure that multiple connections
from the same source are mapped to the same redirection address.
Associations are destroyed as soon as there are no longer states
which refer to them; in order to make the mappings last beyond the
lifetime of the states, increase the global options with set
timeout src.track.
source-hash [key] [sticky-address]
The source-hash option uses a hash of the source address to
determine the redirection address, ensuring that the redirection
address is always the same for a given source. An optional key can
be specified after this keyword either in hex or as a string; by
default pfctl(8) randomly generates a key for source-hash every
time the ruleset is reloaded. sticky-address is as described
above.
G
