Reyk talked about network interface aggregation using the virtual
trunk(4) interface. I think there is a conceptually similar feature that permits the creation of interface groups via
ifconfig. What cool things can we do with it?
Henning Brauer: Well, while trunk groups interfaces to aggregate bandwidth, interface groups provide an administrative grouping. Interfaces can join and leave named groups any time, via
# ifconfig sk0 group somegroup # ifconfig sk0 -group somegroup
Interfaces can be in more than one group, and of course a group can contain more than one interface. Now, pf can filter based on the group names. You could, for example, have your external interface on a typical firewall join a group
ext, and have pf filter on the group ext instead of the interface. That way, your ruleset is hardware independent--the group assignment goes to the hostname.if files, which are machine dependent anyway. If you do the same for your internal interface it makes even more sense; if you add a second internal one, say, a wireless card, you just make it join the group--no need to modify the ruleset.
We do maintain some groups by default. Cloneable interfaces--or, rather, the cloned ones--are part of a group named by the driver. For example, all loopback interfaces are a member of the
lo group, all tun interfaces are part of the
tun group, and so on. And there is a group called
egress that follows the IPv4 and IPv6 default routes--it contains all interfaces that default routes point to, which in the typical case is your "external" interface. But it is also very handy for notebooks with mixed wireless/wired usage.
ifstated daemon runs commands in response to network state changes. For example, it can ensure that CARP interfaces stay in sync. If I remember correctly, this tool has been part of the source tree for a couple of releases, but it was not linked to the build process. Why? Did you need any particular feature that is only available since 3.8?
Marco Pfatschbacher: No, we didn't add any new
ifstated features in 3.8. The reason it wasn't included till 3.8 was some discussion about the config file syntax and the actual practical use of it. The initial version was only for the purpose to trigger commands in response to CARP state changes. Later a complete state engine was added, and the ability to run external test commands. The idea was that a host having more than one CARP interface can monitor its surrounding network and give up its master state in case of an error. You can find details on Ryan's web site.
Since support for CARP to monitor its physical interfaces link state was added, there was a simpler and much nicer solution to this problem.
However, we still found it's a quite useful program and so we kept it. Just to give you some examples:
- Being able to run any kind of program in response to CARP (or physical interfaces link) state changes. This can be a simple report mail or a daemon startup.
- Build some higher-level tests to ensure that everything around your CARP host works as expected. Still, a ping test can tell you more reliably that everything is OK than watching only the physical link state.
- Build a simple failover setup over multiple internet connections; e.g., monitor your DSL line, and if it goes bad, trigger a dial-up link.
Currently I'm extending
ifstated to react on address changes on interfaces. This is especially useful for the new in-kernel-pppoe device, where you can trigger some commands after you received a new IP address due to a disconnect to your ISP.
The upcoming 3.8 will include
sasyncd, an IPSec SA synchronization daemon for failover gateways. How does it interact with PF, CARP, and isakmpd to provide failover capabilities?
sasyncd currently relies on a specified CARP interface for master and backup state; i.e., when the interface changes state, so does
sasyncd process synchronizes IPSec SA data to other
sasyncd peers (SA creation, deletion, etc.). Then, in the kernel,
pfsync(4) has been extended to also send replay-counter updates for these SAs to the other peers. Without this, the remote VPN peer would not accept any IPsec packets from the "new host" in case of a failover.
isakmpd(8) needs to be configured to only respond to negotiations in a failover scenario, i.e., it should not initiate them. This requirement should go away soon.
The new tool called
ipsecctl sounds like an
isakmpd replacement with an easier configuration. What type of features does it provide? How does it interact with
ipsecctl(8) is an IPsec management tool for both static and automatic keying and acts as a front end to
isamkpd(8). It is still in development, but 3.8 ships a version already usable for simple setups.
Up to now, we had the
ipsecadm(8) utility for static keying. All parameters are passed as command-line options. Thus one had to write a shell script to set up
ipsec(4). See /usr/share/ipsec/rc.vpn. For
isakmpd(8), we have two configuration files,
isakmpd.policy(5). Even for simple setups, those get quickly complex.
To simplify this, we came up with
ipsecctl(8). It is intended to provide a uniform way of configuring
ipsec(4) and to completely obsolete
We decided to use a language derived from
ipsec.conf(5)): Rules define which packets will go through
ipsec(4), which security services will be applied, and how keys are established. Care is taken that only a minimal set of parameters needs to be specified, and reasonable default values are used otherwise.
esp from 192.168.3.14 to 192.168.3.12 spi 0xdeadbeef:0xbeefdead \ authkey file "auth14:auth12" enckey file "enc14:enc12"
This rule creates an IPsec tunnel between the hosts 192.168.3.4 and 192.168.3.12 using ESP with static keys read from some files. No authentication and encryption algorithms are specified; thus
ipsecctl(8) will use HMAC-SHA2-256 and AES countermode as strong default algorithms.
For automatic keying,
ipsecctl(8) generates proper configurations and feeds them to
isakmpd(8) using its FIFO interface. Thus it is not necessary anymore to use
isakmpd.conf(5). For example, to set up a VPN between the networks 10.1.1.0/24 and 10.1.2.0/24, one can use this rule:
ike esp from 10.1.1.0/24 to 10.1.2.0/24 peer 192.168.3.2
ipsecctl(8) will choose good default values for authentication and encryption (3DES-SHA1 for phase 1 and AES-128 and HMAC-SHA2-256 for phase 2), SA lifetimes, and so on.
Current development focuses mainly on improving interaction with