Host name resolution and interface to address translation are done
at ruleset load-time. When the address of an interface (or host
name) changes (under DHCP or PPP, for instance), the ruleset must
be reloaded for the change to be reflected in the kernel.
Surrounding the interface name (and optional modifiers) in
parentheses changes this behaviour. When the interface name is
surrounded by parentheses, the rule is automatically updated
whenever the interface changes its address. The ruleset does not
need to be reloaded. This is especially useful with nat.
You must be new... SirDice already hinted at this, but at the risk of being a bit too obvious: manualpages are a thing on FreeBSD. Note: I'm not trying to be sarcastic, but I honestly think that you'll find the differences between manualpages on FreeBSD and Linux to be quite extensive. On Linux most people use manualpages as brief references, often followed up to look into Info pages.I'm trying to make a PF firewall. I would be grateful for some explanation.
man pf
. It will point you to pf(4) which might not be interesting for you if you're not a programmer, however.. it will also point you to net.pf.states_hashsize and net.pf.source_nodes_hashsize (both sysctl(8) values) as well as point you to other relevant manualpages (see 'SEE ALSO' section). man
command in mind, it can be an invaluable solution!Ohh. Great answer ! I have static ip so in this case i don't need $(ext_if).
You must be new... SirDice already hinted at this, but at the risk of being a bit too obvious: manualpages are a thing on FreeBSD. Note: I'm not trying to be sarcastic, but I honestly think that you'll find the differences between manualpages on FreeBSD and Linux to be quite extensive. On Linux most people use manualpages as brief references, often followed up to look into Info pages.
On FreeBSD a manualpage is actually what its name implies: a manual page. This goes double for the base system, of which pf is part off.
So... trying to set up pf (nice choice btw!). Start with the command:man pf
. It will point you to pf(4) which might not be interesting for you if you're not a programmer, however.. it will also point you to net.pf.states_hashsize and net.pf.source_nodes_hashsize (both sysctl(8) values) as well as point you to other relevant manualpages (see 'SEE ALSO' section).
Then you'll know about pfctl(8) and pf.conf(5) and the other (less interesting at first pf.os(5) file.
But yeah, when you're messing about with something on the FreeBSD base system always keep theman
command in mind, it can be an invaluable solution!
ipfw pipe 1 config bw 1Mbit/s
ipfw add pipe 1 ip from any to any uid bryn1u
Simple: pf is a personal favorite of mine, that's all. Nothing else between the lines.You said to me "PF (nice choice btw). How should i understand ?
Then maybe IPFW is a better choice for your situationI was reading about IPFW and IPFW has option which allow use bandwidth per user using uid. I checked this and it works.
Simple: pf is a personal favorite of mine, that's all. Nothing else between the lines.
Then maybe IPFW is a better choice for your situation
Even though to my knowledge pf is also capable of doing this by applying specific filtering rules to the queueing section. PF can apply filtering rules to specific users and or groups.
Simple: pf is a personal favorite of mine, that's all. Nothing else between the lines.
Then maybe IPFW is a better choice for your situation
Even though to my knowledge pf is also capable of doing this by applying specific filtering rules to the queueing section. PF can apply filtering rules to specific users and or groups.
Such many people don't use traffic shapping per user that i can find nothing in google about this ?group <group>
Similar to user, this rule only applies to packets of sockets owned
by the specified group.
user <user>
This rule only applies to packets of sockets owned by the specified
user. For outgoing connections initiated from the firewall, this
is the user that opened the connection. For incoming connections
to the firewall itself, this is the user that listens on the desti-
nation port. For forwarded connections, where the firewall is not
a connection endpoint, the user and group are unknown.
All packets, both outgoing and incoming, of one connection are
associated with the same user and group. Only TCP and UDP packets
can be associated with users; for other protocols these parameters
are ignored.
User and group refer to the effective (as opposed to the real) IDs,
in case the socket is created by a setuid/setgid process. User and
group IDs are stored when a socket is created; when a process cre-
ates a listening socket as root (for instance, by binding to a
privileged port) and subsequently changes to another user ID (to
drop privileges), the credentials will remain root.
User and group IDs can be specified as either numbers or names.
The syntax is similar to the one for ports. The value unknown
matches packets of forwarded connections. unknown can only be used
with the operators = and !=. Other constructs like user >= unknown
are invalid. Forwarded packets with unknown user and group ID
match only rules that explicitly compare against unknown with the
operators = or !=. For instance user >= 0 does not match forwarded
packets. The following example allows only selected users to open
outgoing connections:
block out proto { tcp, udp } all
pass out proto { tcp, udp } all user { < 1000, dhartmei }
Because this only works for local processes, running on the firewall itself. The user's UID and GID isn't sent over the network. So packets arriving at the firewall from remote systems don't have this information. From the firewall's point of view, you simply cannot tell the difference if a network packet was sent by UserA or UserB.Such many people don't use traffic shaping per user that I can find nothing in google about this ?