PF Diffrences between $ext_if and ($ext_if)

Hey,

I know this is such stupid question but I can't find description and differences between $ext_if and ($ext_if). I'm trying to make a PF firewall. I would be grateful for some explanation.
Thanks !
 
Code:
           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.
From pf.conf(5).
 
I'm trying to make a PF firewall. I would be grateful for some explanation.
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 the 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).
Thank you.

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 the man command in mind, it can be an invaluable solution!

Hey,
You said to me "PF (nice choice btw). How should i understand ? IPFW is worse then PF ? I just need to share internet for few users on some ports. Mean shell users. I was reading about IPFW and IPFW has option which allow use bandwidth per user using uid. I checked this and it works.
For example:
Code:
ipfw pipe 1 config bw 1Mbit/s
ipfw add pipe 1 ip from any to any uid bryn1u
I don't know about PF much. Im just asking, can i do this the same with PF ?
 
You said to me "PF (nice choice btw). How should i understand ?
Simple: pf is a personal favorite of mine, that's all. Nothing else between the lines.

I was reading about IPFW and IPFW has option which allow use bandwidth per user using uid. I checked this and it works.
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.
 
I am not well versed on firewalls but IPFW seems to be a better firewall than PF but its super bothing syntax leave people far from it ( me included ).
 
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.

Thanks, i will try then.
 
If you're using PF, which I highly suggest, I would encourage you to check out "The Book of PF" by Peter N. M. Hansteen. It offers a great description of the various configurations you can use with it. You can also find some very useful things by searching for a PF tutorial on a search engine. You should also check out https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-pf.html from the FreeBSD handbook. A firewall can be made with just a few lines.
 
I would also like to recommend the 'The Book of PF'.
I bought an older copy because I had heard FreeBSD uses an older version of pf than OpenBSD.
So I assumed an older book was better suited.

I was happily surprised when I found the book gives instructions for both OpenBSD and FreeBSD.
If I had know that I would have bought the newest edition.
Either way any edition is better than nothing. Well written.
 
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.

Hey,
You mean 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 }
Such many people don't use traffic shapping per user that i can find nothing in google about this ?
 
Such many people don't use traffic shaping per user that I can find nothing in google about this ?
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.
 
Back
Top