Update on altq and interface groups
Hi list,
I know this question has been asked before, but I'm after an up-to-date
answer, or at least a confirmation.
Has support for interface groups been implemented for altq? By that, I mean
the
possibility to use an interface group name with b altq on GROUPb to set up
similar queues for each of the interfaces of the group. This could be used to
not have to explicitly name the interfaces but rather refer to their current
role. The outgoing traffic for all the interfaces could also be classified
with
only one ruleset of b pass out on GROUPb s.
Unfortunately, the changelogs and my small experiments (see below) seem to
hint that
it's not supported. But maybe I'm (doing it) wrong?
opera...@mudrublic:~$ /sbin/ifconfig
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 33200
(...)
ath0: flags=8963UP,BROADCAST,NOTRAILERS,RUNNING,PROMISC,SIMPLEX,MULTICAST
mtu 1500
(...)
groups: wlan internal
(...)
sis0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
(...)
groups: egress
(...)
Relevant beginning of pfctl.conf:
UPLINK_BANDWIDTH = 90Mb
set skip on lo
set loginterface public
altq on egress priq bandwidth $UPLINK_BANDWIDTH queue {std_out,
interactive_out, dns_out, tcp_ack_out}
queue std_out priq(default)
queue interactive_out priority 4 prirq(red)
queue dns_out priority 5
queue tcp_ack_out priority 6
(...)
pass out on egress proto tcp to any flags S/SA keep state queue(std_out,
tcp_ack_out)
pass out on egress proto { tcp udp } to any port domain keep state queue
dns_out
pass out on egress proto tcp to any port ssh flags S/SA keep state
queue(std_out, interactive_out)
$ sudo pfctl -vf /etc/pf.conf
set skip on { lo }
set loginterface public
UPLINK_BANDWIDTH = 90Mb
pfctl: SIOCGIFMTU: Device not configured
This error doesn't happen if I replace egress with sis0 in the b altq onb
line
(pretty bad omen, I guess...).
$ uname -a
OpenBSD mudrublic.narf.ssji.net 4.6 GENERIC#58 i386
Thanks.
--
Olivier Mehani sht...@ssji.net
PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655
[demime 1.01d removed an attachment of type application/pgp-signature]
Re: Update on altq and interface groups
On Mon, Jul 5, 2010 at 8:50 AM, Olivier Mehani sht...@ssji.net wrote: I know this question has been asked before, but I'm after an up-to-date answer, or at least a confirmation. Has support for interface groups been implemented for altq? No. http://marc.info/?l=openbsd-miscm=127453585925685w=2
Re: pf, altq and interface groups
* Daniel Melameth dan...@melameth.com [2010-05-22 03:58]: I've considered migrating my macro-based interface names to interface groups, but, it appears, altq does not grok interface groups--and pfctl spits back a pfctl: SIOCGIFMTU: Device not configured when I try. Am I missing something here? pf.conf's BNF, it appears, says I'm not... no ifgroup support for altq - and it is not easy to add either. the BNF is simplified, otherwise it would explode. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
pf, altq and interface groups
I've considered migrating my macro-based interface names to interface groups, but, it appears, altq does not grok interface groups--and pfctl spits back a pfctl: SIOCGIFMTU: Device not configured when I try. Am I missing something here? pf.conf's BNF, it appears, says I'm not...
altq and interface groups
Hi, setup: 4.2 with tun0 being a pppoe(8) int and tun1 being a ssh-vpn over tun0. altq is running on tun0. I know that altq doesn't support interface groups (and that support is not planned (see http://marc.info/?l=openbsd-miscm=112431574118264w=2)) but is there a way around this? Currently altq sees all traffic on tun1 on tun0 as default instead of ssh, which it is. Best Martin
Interface groups configuration
Hello, Is there a native way to configure interface groups in hostname.if instead of doing manually ifconfig if ... group mygroup or calling ifconfig from the hostname.if file like this ... !ifconfig if group mygroup ? This is not documented in hostname.if(5). thanks
Re: Interface groups configuration
On Nov 2, 2006, at 6:43 AM, Luca Corti wrote: Hello, Is there a native way to configure interface groups in hostname.if instead of doing manually ifconfig if ... group mygroup or calling ifconfig from the hostname.if file like this ... !ifconfig if group mygroup ? This is not documented in hostname.if(5). Sure it is. It tells you that options come last. Example: # cat /etc/hostname.em1 inet 192.168.0.1 255.255.255.0 192.168.0.255 description LAN group internal -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net
Re: Interface groups configuration
On Thu, Nov 02, 2006 at 12:43:22PM +0100, Luca Corti wrote: Hello, Is there a native way to configure interface groups in hostname.if instead of doing manually ifconfig if ... group mygroup or calling ifconfig from the hostname.if file like this ... !ifconfig if group mygroup ? This is not documented in hostname.if(5). it is documented...the options part of hostname.if(5) are ifconfig(8) options, as noted in the man page. so you could do: inet 10.0.0.1 255.255.255.0 10.0.0.255 group bob jmc
Interface groups PF route-to
Hi all, I've been trying to get interface groups going on a machine and have met with a possibly interesting problem. I have declared an interface to be part of a group, and that group shows up correctly if I `ifconfig foogroup` or `pfctl -s Interfaces` I have a setup where I have one VPN come in over one ISP link, and another over a second (from different remote IPs to different local IPs). I have the following macros defined, [NB: Yes I changed the IPs] link2_if = em0 #link2_if = MyIFGroup link2_gw = 1.1.1.1 link2_ip1 = 1.1.1.20 remote_link0_ip1 = 200.200.200.200 To test, I comment out the 'em0' line and uncomment the IFGroup line. I also have the following rules in place to correctly handle my VPN on that link pass in log quick on $link2_if reply-to ($link2_if $link2_gw)\ proto esp from $remote_link0_ip1 to $link2_ip1 keep state pass out log quick on $link2_if route-to ($link2_if $link2_gw)\ proto esp from $link2_ip1 to $remote_link0_ip1 keep state pass in log on $link2_if reply-to ($link2_if $link2_gw)\ proto udp from $remote_link0_ip1 port = isakmp to $link2_if\ port = isakmp keep state pass out log quick on $link2_if route-to ($link2_if $link2_gw)\ proto udp from $link2_if port = isakmp to $remote_link0_ip1\ port = isakmp keep state What I find is that when I go over to using the MyIFGroup declaration, my rules stop matching and the VPN doesn't get established on the group'd interface (the other VPN comes up fine). Is there something I'm missing ?? From reading the posts and 'man ifconfig' about interface groups I'm pretty sure I just have to assign an interface to the group and nothing more. Is that correct ?? Any help appreciated, Cheers Dave
Re: trunk in interface groups?
* Per-Olov Sj?holm [EMAIL PROTECTED] [2006-02-23 22:08]: Hi misc Saw a post from june 2005 by Henning regarding the work he and Ryan did on code cleanup and the addition code of interface groups. I think I am on my way to abuse these groups as simple alias to make PF totaly independant from the hardware and put all my interface stuff in the hostname.if files only. The question: Is it possible to add a trunk interface as well to an interface group and then refer to that group as an interface in PF? the type of an interface should (I'm inclined to say: must) not matter for interface groups. -- BS Web Services, http://www.bsws.de/ OpenBSD-based Webhosting, Mail Services, Managed Servers, ... Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: pf and interface groups in 3.8
after some private mails...
* Peter Fraser [EMAIL PROTECTED] [2005-11-20 21:30]:
I was trying out the interface groups of pf 3.8, I was surprised to
get a syntax error with:
pass out quick proto { tcp udp }
from egress to any port domain flags S/SA keep state
as said before, I initially forgot the code for static expansion. this
is in -current for some time now tho.
which seems to use self in these case as an undefined interface
group, I would have expected that self would have been implemented
a interface group of all the interfaces on the computer.
it is, and happens to work just fine :)
pf is very unhappy if you use:
set loginterface egress
After this statement I could not get pf to work again unless I rebooted.
this has been confirmed to be an operator error. while you cannot set
loginterface to a group (yet, at least), it does _not_ leave pf in a
non-working state or the like.
also it is not obvious to me what happens when you use:
antispoof quick for Inside
where Inside is an interface group containing several interfaces. I
expect
that antispoof only works as a group, rather than on each interface
individually
as said - see for yourself. need -current due to above mentioned
missing static expansion, then see with
echo antispoof for Inside | pfctl -nvf -
--
BS Web Services, http://www.bsws.de/
OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
Unix is very simple, but it takes a genius to understand the simplicity.
(Dennis Ritchie)
pf and interface groups in 3.8
I was trying out the interface groups of pf 3.8, I was surprised to
get a syntax error with:
pass out quick proto { tcp udp }
from egress to any port domain flags S/SA keep state
you do not get an error message for
pass out quick proto { tcp udp }
from (egress) to any port domain flags S/SA keep state
Also as a result of this experimentation. I discover that syntactically
you
can say:
antispoof $dbg quick for self
or
pass out quick on self proto { tcp udp }
from (egress) to any port domain flags S/SA keep state
which seems to use self in these case as an undefined interface
group, I would have expected that self would have been implemented
a interface group of all the interfaces on the computer.
pf is very unhappy if you use:
set loginterface egress
After this statement I could not get pf to work again unless I rebooted.
also it is not obvious to me what happens when you use:
antispoof quick for Inside
where Inside is an interface group containing several interfaces. I
expect
that antispoof only works as a group, rather than on each interface
individually
Re: pf tables and interface groups
* Henning Brauer [EMAIL PROTECTED] [2005-10-12 17:17]:
no, I managed to miss implementing the static expansion, the way more
complicated dynamic expansion for interface groups works fine. I'll add
the static one asap.
so here's the diff for that.
disclaimer: I hacked that at a conference, beeing dead tired, careful
reading testing appreciated.
Index: pfctl_parser.c
===
RCS file: /cvs/src/sbin/pfctl/pfctl_parser.c,v
retrieving revision 1.220
diff -u -p -r1.220 pfctl_parser.c
--- pfctl_parser.c 13 Oct 2005 13:27:06 - 1.220
+++ pfctl_parser.c 13 Oct 2005 14:36:35 -
@@ -66,6 +66,7 @@ void print_fromto(struct pf_rule_addr
struct pf_rule_addr *, u_int8_t, u_int8_t, int);
int ifa_skip_if(const char *filter, struct node_host *p);
+struct node_host *ifa_grouplookup(const char *, int);
struct node_host *host_if(const char *, int);
struct node_host *host_v4(const char *, int);
struct node_host *host_v6(const char *, int);
@@ -1165,10 +1166,28 @@ struct node_host *
ifa_exists(const char *ifa_name)
{
struct node_host*n;
+ struct ifgroupreq ifgr;
+ int s;
if (iftab == NULL)
ifa_load();
+ /* check wether this is a group */
+ if ((s = socket(AF_INET, SOCK_DGRAM, 0)) == -1)
+ err(1, socket);
+ bzero(ifgr, sizeof(ifgr));
+ strlcpy(ifgr.ifgr_name, ifa_name, sizeof(ifgr.ifgr_name));
+ if (ioctl(s, SIOCGIFGMEMB, (caddr_t)ifgr) == 0) {
+ /* fake a node_host */
+ if ((n = calloc(1, sizeof(*n))) == NULL)
+ err(1, calloc);
+ if ((n-ifname = strdup(ifa_name)) == NULL)
+ err(1, strdup);
+ close(s);
+ return (n);
+ }
+ close(s);
+
for (n = iftab; n; n = n-next) {
if (n-af == AF_LINK !strncmp(n-ifname, ifa_name, IFNAMSIZ))
return (n);
@@ -1178,11 +1197,56 @@ ifa_exists(const char *ifa_name)
}
struct node_host *
+ifa_grouplookup(const char *ifa_name, int flags)
+{
+ struct ifg_req *ifg;
+ struct ifgroupreqifgr;
+ int s, len;
+ struct node_host*n, *h = NULL, *hn;
+
+ if ((s = socket(AF_INET, SOCK_DGRAM, 0)) == -1)
+ err(1, socket);
+ bzero(ifgr, sizeof(ifgr));
+ strlcpy(ifgr.ifgr_name, ifa_name, sizeof(ifgr.ifgr_name));
+ if (ioctl(s, SIOCGIFGMEMB, (caddr_t)ifgr) == -1) {
+ close(s);
+ return (NULL);
+ }
+
+ len = ifgr.ifgr_len;
+ if ((ifgr.ifgr_groups = calloc(1, len)) == NULL)
+ err(1, calloc);
+ if (ioctl(s, SIOCGIFGMEMB, (caddr_t)ifgr) == -1)
+ err(1, SIOCGIFGMEMB);
+
+ for (ifg = ifgr.ifgr_groups; ifg len = sizeof(struct ifg_req);
+ ifg++) {
+ len -= sizeof(struct ifg_req);
+ n = ifa_lookup(ifg-ifgrq_member, flags);
+ if (h == NULL)
+ h = n;
+ else {
+ for (hn = h; hn-next != NULL; hn = hn-next)
+ ; /* nothing */
+ hn-next = n;
+ n-tail = hn;
+ }
+ }
+ free(ifgr.ifgr_groups);
+ close(s);
+
+ return (h);
+}
+
+struct node_host *
ifa_lookup(const char *ifa_name, int flags)
{
struct node_host*p = NULL, *h = NULL, *n = NULL;
int got4 = 0, got6 = 0;
const char *last_if = NULL;
+
+ if ((h = ifa_grouplookup(ifa_name, flags)) != NULL)
+ return (h);
if (!strncmp(ifa_name, self, IFNAMSIZ))
ifa_name = NULL;
Re: pf tables and interface groups
* Ryan Puckett [EMAIL PROTECTED] [2005-10-07 22:36]:
Under the Tables section in the pf.conf(5) man page, it is indicated
that tables can be created with a valid interface group. I'm taking
this to mean I can do the following:
table all-of-my-vlans { vlan }
or better yet:
table outside { egress }
but when loading up the ruleset or even trying to manually add the table
via command line pfctl -t outside -T add egress I receive:
no IP address found for egress
I have no problems when specifying the exact interface such as vlan0.
So my question is: did I misread this?
no, I managed to miss implementing the static expansion, the way more
complicated dynamic expansion for interface groups works fine. I'll add
the static one asap.
however, you probably don't want that anyway. extending your example
slightly.
table all-of-my-vlans { vlan }
pass to all-of-my-vlans
is equal to
pass to (vlan)
except that the latter saves some tiny amounts of memory, and, more
important, gets dynamically updated when vlan interfaces get added or
removed or IPs change on any vlan interface.
--
BS Web Services, http://www.bsws.de/
OpenBSD-based Webhosting, Mail Services, Managed Servers, ...
Unix is very simple, but it takes a genius to understand the simplicity.
(Dennis Ritchie)
pf tables and interface groups
Under the Tables section in the pf.conf(5) man page, it is indicated
that tables can be created with a valid interface group. I'm taking
this to mean I can do the following:
table all-of-my-vlans { vlan }
or better yet:
table outside { egress }
but when loading up the ruleset or even trying to manually add the table
via command line pfctl -t outside -T add egress I receive:
no IP address found for egress
I have no problems when specifying the exact interface such as vlan0.
So my question is: did I misread this?
Thanks
-Ryan
Re: pf tables and interface groups
Sorry, should have indicated I'm using OpenBSD version 3.8
dmesg:
OpenBSD 3.8-current (GENERIC) #169: Sun Oct 2 15:06:50 MDT 2005
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium III (GenuineIntel 686-class, 512KB L2 cache) 549
MHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
real mem = 670658560 (654940K)
avail mem = 604418048 (590252K)
using 4278 buffers containing 33636352 bytes (32848K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(1e) BIOS, date 02/23/00, BIOS32 rev. 0 @
0xfd7a0
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
apm0: flags 30102 dobusy 0 doidle 1
pcibios0 at bios0: rev 2.1 @ 0xfd7a0/0x860
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdf30/176 (9 entries)
pcibios0: PCI Interrupt Router at 000:07:0 (Intel 82371FB ISA rev
0x00)
pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc/0x8000 0xc8000/0x6600 0xce800/0x800
0xcf000/0x800 0xe/0x4000! 0xe4000/0xc000
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 Intel 82443BX AGP rev 0x03
ppb0 at pci0 dev 1 function 0 Intel 82443BX AGP rev 0x03
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 ATI Rage Magnum rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcib0 at pci0 dev 7 function 0 Intel 82371AB PIIX4 ISA rev 0x02
pciide0 at pci0 dev 7 function 1 Intel 82371AB IDE rev 0x01: DMA,
channel 0 wired to compatibility, channel 1 wired to compatibility
pciide0: channel 0 ignored (disabled)
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: TOSHIBA, DVD-ROM SD-M1222, 1004 SCSI0
5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
uhci0 at pci0 dev 7 function 2 Intel 82371AB USB rev 0x01: irq 9
usb0 at uhci0: USB revision 1.0
uhub0 at usb0
uhub0: Intel UHCI root hub, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
Intel 82371AB Power rev 0x02 at pci0 dev 7 function 3 not configured
yds0 at pci0 dev 12 function 0 Yamaha 740C rev 0x03: irq 10
xl0 at pci0 dev 13 function 0 3Com 3c905B 100Base-TX rev 0x30: irq 11,
address 00:50:da:22:7c:7e
exphy0 at xl0 phy 24: 3Com internal media interface
ahc1 at pci0 dev 14 function 0 Adaptec AHA-29160 U160 rev 0x02: irq 5
scsibus1 at ahc1: 16 targets
sd0 at scsibus1 targ 0 lun 0: SEAGATE, ST39236LW, 0004 SCSI3 0/direct
fixed
sd0: 8761MB, 14384 cyl, 3 head, 415 sec, 512 bytes/sec, 17942584 sec
total
xl1 at pci0 dev 15 function 0 3Com 3c905C 100Base-TX rev 0x74: irq 10,
address 00:01:02:46:25:77
bmtphy0 at xl1 phy 24: Broadcom 3C905C internal PHY, rev. 6
xl2 at pci0 dev 16 function 0 3Com 3c905C 100Base-TX rev 0x74: irq 9,
address 00:01:02:73:ec:be
bmtphy1 at xl2 phy 24: Broadcom 3C905C internal PHY, rev. 6
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
midi0 at pcppi0: PC speaker
spkr0 at pcppi0
sysbeep0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
npx0 at isa0 port 0xf0/16: using exception 16
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pccom0: console
pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
biomask f365 netmask ff65 ttymask ffe7
pctr: 686-class user-level performance counters enabled
mtrr: Pentium Pro MTRR support
ahc1: target 0 using 16bit transfers
ahc1: target 0 synchronous at 20.0MHz, offset = 0x1f
dkcsum: sd0 matches BIOS drive 0x80
root on sd0a
rootdev=0x400 rrootdev=0xd00 rawdev=0xd02
ac97: codec id 0x41445303 (Analog Devices AD1819)
ac97: codec features Analog Devices Phat Stereo
audio0 at yds0
opl0 at yds0: model OPL3
midi1 at opl0: DS-1 integrated Yamaha OPL3
mpu at yds0 not configured
mpu at yds0 not configured
mpu at yds0 not configured
mpu at yds0 not configured
On Fri, 2005-10-07 at 14:30 -0600, Ryan Puckett wrote:
Under the Tables section in the pf.conf(5) man page, it is indicated
that tables can be created with a valid interface group. I'm taking
this to mean I can do the following:
table all-of-my-vlans { vlan }
or better yet:
table outside { egress }
but when loading up the ruleset or even trying to manually add the table
via command line pfctl -t outside -T add egress I receive:
no IP address found for egress
I have no problems when specifying the exact interface such as vlan0.
So my question is: did I misread this?
Thanks
-Ryan
interface groups and altq
Do interface groups support altq? It would appear that they do not,
but I might have a borked kernel/pfctl utility, so wanted to ask the
list to make sure. When I try to put altq on an interface group, i get
the following when parsing my pf.conf:
$ sudo pfctl -f /etc/pf.conf -n
pfctl: SIOCGIFDATA: Device not configured
$
However if I change the altq line to use the actual interface, it works:
$ sudo pfctl -f /etc/pf.conf -n
$
here is my pf.conf and dmesg, although the simple answer will probably
be either, yes or no.
### MACROS ###
ext_if=egress
int_if=intnet
ext_ip=( $ext_if )
int_ip=( $int_if )
kyle=172.17.101.7/32
terrance=172.17.101.1/32
kenny=192.168.17.5/32
tweak=192.168.17.62/32
craig=192.168.17.61/32
wendy=192.168.17.60/32
table high_hosts { $kyle, $kenny }
table low_hosts { $tweak, $craig, $wendy }
ext_net=$ext_if:network
int_net=$int_if:network
unpriv== 1024
### OPTIONS ###
set limit states 2
set optimization aggressive
set block-policy drop
set skip on lo0
### TRAFFIC NORMALIZATION ###
scrub in all no-df random-id fragment reassemble
### QUEUEING ###
# external interface queue list
#altq on $ext_if priq queue { std_ext, high_ext, low_ext }
#queue std_ext on $ext_if priq( default, red )
#queue high_ext on $ext_if priority 10 priq( red )
#queue low_ext on $ext_if priority 0 priq( red )
# internal interface queue list
altq on le2 priq queue { std_int, high_int, low_int }
queue std_int on le2 priq( default, red )
queue high_int on le2 priority 10 priq( red )
queue low_int on le2 priority 0 priq( red )
### TRANSLATION ###
### PACKET FILTERING ###
block in log all
block out log all
pass in quick on $ext_if inet proto tcp from high_hosts port $unpriv
to $ext_ip port ssh flags S/FSRPA modulate state queue high_ext
pass in quick on $ext_if inet proto tcp from low_hosts port $unpriv
to $ext_ip port ssh flags S/FSRPA modulate state queue low_ext
pass in quick on $ext_if inet proto tcp from any port $unpriv to
$ext_ip port ssh flags S/FSRPA modulate state queue std_ext
pass in quick on $int_if inet proto tcp from high_hosts port $unpriv
to $int_ip port ssh flags S/FSRPA modulate state queue high_int
pass in quick on $int_if inet proto tcp from low_hosts port $unpriv
to $int_ip port ssh flags S/FSRPA modulate state queue low_int
pass out quick on $ext_if inet proto udp from $ext_ip to $kyle port
ntp modulate state queue high_ext
pass out quick on $ext_if inet proto udp from $ext_ip to $terrance
port domain modulate state queue high_ext
pass out quick on $ext_if inet proto tcp from $ext_ip port $unpriv to
anoncvs_hosts port 5999 flags S/FSRPA modulate state queue high_ext
pass out quick on $ext_if inet proto tcp from $ext_ip port $unpriv to
any port www flags S/FSRPA modulate state queue std_ext
OpenBSD 3.8-beta (GENERIC) #85: Sun Aug 14 13:55:19 MDT 2005
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Pentium(R) 4 CPU 3.20GHz (GenuineIntel 686-class) 3.20 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,PNI
real mem = 133734400 (130600K)
avail mem = 115433472 (112728K)
using 1658 buffers containing 6791168 bytes (6632K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(77) BIOS, date 04/21/04, BIOS32 rev. 0 @ 0xfd880
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
apm0: flags 30102 dobusy 0 doidle 1
pcibios0 at bios0: rev 2.1 @ 0xfd880/0x780
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdf30/176 (9 entries)
pcibios0: PCI Interrupt Router at 000:07:0 (Intel 82371FB ISA rev 0x00)
pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc/0x8000 0xc8000/0x1a00! 0xca000/0x1000
0xcb000/0x1000 0xdc000/0x4000! 0xe4000/0x4000!
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 Intel 82443BX AGP rev 0x01
ppb0 at pci0 dev 1 function 0 Intel 82443BX AGP rev 0x01
pci1 at ppb0 bus 1
pcib0 at pci0 dev 7 function 0 Intel 82371AB PIIX4 ISA rev 0x08
pciide0 at pci0 dev 7 function 1 Intel 82371AB IDE rev 0x01: DMA,
channel 0 configured to compatibility, channel 1 configured to
compatibility
pciide0: channel 0 ignored (disabled)
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: NECVMWar, VMware IDE CDR10, 1.00 SCSI0
5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2
Intel 82371AB Power rev 0x08 at pci0 dev 7 function 3 not configured
vga1 at pci0 dev 15 function 0 VMware Virtual SVGA II rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
bha3 at pci0 dev 16 function 0 BusLogic MultiMaster rev 0x01: irq
11, BusLogic 9xxC SCSI
bha3: model BT-958, firmware 5.07B
bha3: sync, parity
scsibus1 at bha3: 8 targets
sd0 at scsibus1 targ 0 lun 0: VMware,, VMware Virtual S, 1.0 SCSI2
0/direct fixed
sd0: 2048MB, 261 cyl, 255 head, 63 sec, 512 bytes/sec, 4194304 sec total
sd1 at scsibus1 targ
Re: interface groups and altq
* Jason Crawford [EMAIL PROTECTED] [2005-08-17 18:47]: Do interface groups support altq? in the sense of queuing on interface groups, no, not really. -- BS Web Services, http://www.bsws.de/ OpenBSD-based Webhosting, Mail Services, Managed Servers, ... Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: interface groups and altq
On 8/17/05, Henning Brauer [EMAIL PROTECTED] wrote: * Jason Crawford [EMAIL PROTECTED] [2005-08-17 18:47]: Do interface groups support altq? in the sense of queuing on interface groups, no, not really. Is this a work in progress? Planned but after 3.8? Or is this not possible? Thanks, Jason
Re: interface groups and altq
* Jason Crawford [EMAIL PROTECTED] [2005-08-17 21:55]: On 8/17/05, Henning Brauer [EMAIL PROTECTED] wrote: * Jason Crawford [EMAIL PROTECTED] [2005-08-17 18:47]: Do interface groups support altq? in the sense of queuing on interface groups, no, not really. Is this a work in progress? Planned but after 3.8? Or is this not possible? in theory it should be possible, but it is everything but trivial. I have no plans in that direction myself currently. -- BS Web Services, http://www.bsws.de/ OpenBSD-based Webhosting, Mail Services, Managed Servers, ... Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: PF, Interface-groups and nat
* Erik Wikstrvm [EMAIL PROTECTED] [2005-07-06 22:54]: set loginterface if_ext All seems fine, running pfctl -n on it produces nothing, but when trying to load the rules I get DIOSETSTATUSIF, and no rules are loaded. What am I doing wrong? oh hmm loginterface does not support groups. -- BS Web Services, http://www.bsws.de/ OpenBSD-based Webhosting, Mail Services, Managed Servers, ... Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: PF, Interface-groups and nat
Try running pfctl -nf; use both switches. This should give you an error (syntax error) to which it refers you to a line where something went wrong.
Re: PF, Interface-groups and nat
On 2005-07-07 18:47, Vivek Ayer wrote: Try running pfctl -nf; use both switches. This should give you an error (syntax error) to which it refers you to a line where something went wrong. Sorry, I was being unclear, I did use -nf. However I did get rid of that problem by setting a real interface as the loginterface instead of the group. Unfortunately that did not make things much better. Computers on the local network were able to ping the OpenBSD-box but not the other way around, I just got Sendto: No route to host. Nor could any of the computers on the network get through to the internet, or rather, I suspect that they could send out their requests but the router didn't manage to send any data back. Strange though that the echo-replys got through. -- Erik Wikstrvm
Re: PF, Interface-groups and nat
--On 07 July 2005 20:22 +0200, Erik WikstrC6m wrote: Computers on the local network were able to ping the OpenBSD-box but not the other way around, I just got Sendto: No route to host. Carefully verify your rules - easiest way is to make sure you 'log' on all your block rules then monitor the pflog0 interface with tcpdump as described in the manual. Assuming you have a default route (if connecting outside the subnet), or the host is responding to ARP requests (if it's within the subnet), this error usually indicates that you don't have a PF rule permitting the packet's transmission.
PF, Interface-groups and nat
Hi
I'm trying to set up a small home-network with both wired and wireless
access, so I've put the following NICs in a box:
ath0: internal wireless 192.168.1.1
rl0: internal wired 192.168.0.1
rl1: external wired DHCP
I've used the following pf.conf (a slight adaption from the example in
the pf-FAQ):
# macros
tcp_services = { 22, 113 }
icmp_types = echoreq
# options
set block-policy return
set loginterface rl1
# scrub
scrub in all
# nat/rdr
nat on rl1 from ath0:network to any - (rl1)
nat on rl1 from rl0:network to any - (rl1)
# filter rules
block all
pass quick on lo0 all
pass in on rl1 inet proto tcp from any to (rl1) \
port $tcp_services flags S/SA keep state
pass in inet proto icmp all icmp-type $icmp_types keep state
pass in on ath0 from ath0:network to any keep state
pass out on ath0 from any to ath0:network keep state
pass in on rl0 from rl0:network to any keep state
pass out on rl0 from any to rl0:network keep state
pass out on rl1 proto tcp all modulate state flags S/SA
pass out on rl1 proto { udp, icmp } all keep state
Then I tried to use interface-groups (cool feature, and it seems like
it might reduce the pf.conf-file and make it easier to maintain) and
put rl1 in group if_ext and the other two NICs in if_int and tried
to adapt pf.conf accordingly and got this:
# macros
tcp_services = { 22, 113 }
icmp_types = echoreq
# options
set block-policy return
set loginterface if_ext
# scrub
scrub in all
# nat/rdr
nat on if_ext from (if_int:network) to any - (if_ext)
# filter rules
block all
pass quick on lo0 all
pass in on if_ext inet proto tcp from any to (if_ext) \
port $tcp_services flags S/SA keep state
pass in inet proto icmp all icmp-type $icmp_types keep state
pass in on if_int from (if_int:network) to any keep state
pass out on if_int from any to (if_int:network) keep state
pass out on if_ext proto tcp all modulate state flags S/SA
pass out on if_ext proto { udp, icmp } all keep state
All seems fine, running pfctl -n on it produces nothing, but when
trying to load the rules I get DIOSETSTATUSIF, and no rules are
loaded. What am I doing wrong?
--
Erik Wikstrvm
pf and interface groups
Hi
I'm trying to set up a box as a router for my home network, I
have 3 NICs, one external, one wireless, and one internal. I've
put the external in group if_ext and the wireless and the
internal in group if_int, the reason for this is that it gives
me a little more generic pf.conf (and it's fun).
However I've got a problem, on some places I use the :network-
modifier on the interface-groupnames, which of course does not
work. I've tried replacing if_int with the macro
if_int = { rl0, ath0 }
and use $if_int:network but that, ofcourse does not work either.
So I'm wondering what's the best approach that keeps the rules
fairly generic?
--
Erik Wikstrvm
Re: pf and interface groups
Gah, should have read more carfully, using (if_ext:network) works just fine. -- Erik Wikstrvm
Re: interface groups and pf
Hi all.
And is ALTQ will work on such groups? For example, I had
altq on $ext_if_1 priq bandwidth 10Mb queue { q_pri_1, q_def_1 }
queue q_pri_1 priority 7
queue q_def_1 priority 1 priq(default)
altq on $ext_if_2 priq bandwidth 10Mb queue { q_pri_2, q_def_2 }
queue q_pri_2 priority 7
queue q_def_2 priority 1 priq(default)
So, can I dispense just one altq?
altq on $grp priq bandwidth 10Mb queue { q_pri, q_def }
queue q_pri priority 7
queue q_def priority 1 priq(default)
--
engineer
Re: interface groups and pf
where do one get the the 1 litre stella bottle? /Isak tony sarendal wrote: pf is the best thing since the 1-litre stella bottle. It's good to see that it continues to improve. This is cool stuff. /Tony S
Re: interface groups and pf
Henning Brauer wrote: So, after cleaning up the interface abstraction code in pf with Ryan before the Hackathon, I worked on interface groups integration to pf. ... joining to others: great work. So for now isakmpd have not need to listen on the routing socket by itself to be truly dynamic with interfaces' changes. Instead of it, isakmpd should refer to interface groups just like refers to interface names and default route for now. It it correct understanding of the future of isakmpd in this area? Thanks.
interface groups and pf
So, after cleaning up the interface abstraction code in pf with Ryan before the Hackathon, I worked on interface groups integration to pf. An interface group, is, well, a group of interfaces (surprised, anyone?). Interfaces can join and leave interface groups any time, and can be member in an arbitary number of groups. The join and leave is done via ifconfig: ifconfig sk1 group dmz makes sk1 join the group dmz, and ifconfig sk1 -group dmz removes sk1 from that group again. A group is removed when it does not have any members any more and pf does not refer to it. So far, so good. Now, pf can use interface groups instead of interfaces basically everywhere now. Sounds simple, but is quite powerful. For example, you can (ab-)use interface groups as a kind of aliasing. Just a group with one member, and refer to that. For example, hang your dmz of an interface group called dmz - if you do this in a consistent manner, your ruleset is entirely independent from the underlying hardware, you make interfaces join the groups in their respective hostname.if files which are machine dependent anyway. now, if you add a second dmz interface for whatever reasons with the same policy, you don't even have to modify (usually not even reload) your ruleset - just make the 2nd dmz interface join the group :) that of course makes much more sense for your external interface, where you might get a second internet connection, or customer-facing interfaces which have the same policies. pf can refer to interfaces and interface groups which do not exist (yet) - once the interface / the group shows up, it will be atached to the construct pf uses and (without ruleset reloads!) things Just Work. Moreover, you can use the brace notation for a dynamic interface name to ip address translation, as in, pass in on tun0 proto tcp to (tun0) port ssh keep state and the like. Internally, pf uses a table named after the interface inside the _pf anchor, and updates the table whenever there are address changes on that interface. That works for interface groups too, now - including correct handling of interfaces joining and leaving the group in question, of course. so, if you put all your customer-facing interfaces (vlans or physical, or any combination... as long as it is interfaces :) ) in a group customers, (customers) correctly expands to all ip addresses on your customer-facing interfaces - and (customer:network) to all networks on them. And suddenly nice things like block in on egress from (customer:network) work. For clonable interfaces (almost all virtual ones are, tun, ppp, lo, vlan, etc), the clones are all member of an interface class group, for example, all loopback interfaces are part of the lo interface group, all vlan interfaces are part of the vlan group, etc. this is especially useful in cases where interfaces get created by a daemon on a next free basis, like tun with userland ppp. now, we had a sick idea for a while, and since we finally had all the parts together now I could implement it - there is an egress interface group now which follows the default routes. This interface group contains all interfaces which IPv4 and IPv6 default routes point to - usually, that is one. It even understands multipath routes already, despite them not being useful yet. The group is updated (actually, rebuilt) every time there is changes/additions/deletions of an IPv4 or IPv6 default route. So, imagine that on your notebook, where you are sometimes on wireless and sometimes on wired network connections - just write your pf.conf so that it refers to the egress group instead of wi0 and em0, and it will Just Work :)
Re: interface groups and pf
Cool how's your new notebook?
Re: interface groups and pf
Marvelous work. Thank you. :)
Re: interface groups and pf
Truely amazing work Henning. OpenBSD already leads the way (at least in my opinion) for a packet filter, whether it's commercial or open source, and these latest additions will make my life so much easier. If there is any more testing that needs to be done, I have many spare computers, almost completely unused T1 (only by me and two other co-workers), a /28 of IP addresses (6 currently used, but I could trim that down a few), and a cabinet drawer full of spare nics at work and I'm in charge of it all, so I could do some testing when I have some spare time. Again, thanks so much for this amazing work. Jason On 6/16/05, Henning Brauer [EMAIL PROTECTED] wrote: So, after cleaning up the interface abstraction code in pf with Ryan before the Hackathon, I worked on interface groups integration to pf. An interface group, is, well, a group of interfaces (surprised, anyone?). Interfaces can join and leave interface groups any time, and can be member in an arbitary number of groups. The join and leave is done via ifconfig: ifconfig sk1 group dmz makes sk1 join the group dmz, and ifconfig sk1 -group dmz removes sk1 from that group again. A group is removed when it does not have any members any more and pf does not refer to it. So far, so good. Now, pf can use interface groups instead of interfaces basically everywhere now. Sounds simple, but is quite powerful. For example, you can (ab-)use interface groups as a kind of aliasing. Just a group with one member, and refer to that. For example, hang your dmz of an interface group called dmz - if you do this in a consistent manner, your ruleset is entirely independent from the underlying hardware, you make interfaces join the groups in their respective hostname.if files which are machine dependent anyway. now, if you add a second dmz interface for whatever reasons with the same policy, you don't even have to modify (usually not even reload) your ruleset - just make the 2nd dmz interface join the group :) that of course makes much more sense for your external interface, where you might get a second internet connection, or customer-facing interfaces which have the same policies. pf can refer to interfaces and interface groups which do not exist (yet) - once the interface / the group shows up, it will be atached to the construct pf uses and (without ruleset reloads!) things Just Work. Moreover, you can use the brace notation for a dynamic interface name to ip address translation, as in, pass in on tun0 proto tcp to (tun0) port ssh keep state and the like. Internally, pf uses a table named after the interface inside the _pf anchor, and updates the table whenever there are address changes on that interface. That works for interface groups too, now - including correct handling of interfaces joining and leaving the group in question, of course. so, if you put all your customer-facing interfaces (vlans or physical, or any combination... as long as it is interfaces :) ) in a group customers, (customers) correctly expands to all ip addresses on your customer-facing interfaces - and (customer:network) to all networks on them. And suddenly nice things like block in on egress from (customer:network) work. For clonable interfaces (almost all virtual ones are, tun, ppp, lo, vlan, etc), the clones are all member of an interface class group, for example, all loopback interfaces are part of the lo interface group, all vlan interfaces are part of the vlan group, etc. this is especially useful in cases where interfaces get created by a daemon on a next free basis, like tun with userland ppp. now, we had a sick idea for a while, and since we finally had all the parts together now I could implement it - there is an egress interface group now which follows the default routes. This interface group contains all interfaces which IPv4 and IPv6 default routes point to - usually, that is one. It even understands multipath routes already, despite them not being useful yet. The group is updated (actually, rebuilt) every time there is changes/additions/deletions of an IPv4 or IPv6 default route. So, imagine that on your notebook, where you are sometimes on wireless and sometimes on wired network connections - just write your pf.conf so that it refers to the egress group instead of wi0 and em0, and it will Just Work :)
Re: interface groups and pf
On Thu, 16 Jun 2005 20:55:48 +0200, Henning Brauer [EMAIL PROTECTED] wrote: So, after cleaning up the interface abstraction code in pf with Ryan before the Hackathon, I worked on interface groups integration to pf. Henning, Ryan and all involved -Very Amazing Work. Thank You! JCR
Re: Interface groups
* Frank Denis (Jedi/Sector One) [EMAIL PROTECTED] [2005-06-05 22:22]: Since -current changed a bit the way interface groups are working, is there a simple way to emulate the old behavior? Specifically, I have a pptp server using poptop that creates a lot of tun interfaces. But these interfaces are not automatically assigned to an interface group. So is there still a way to match tun* in pf rules? not currently. I plan to bring back the interface class groups for cloned interfaces, tho there is a bit prerequisite work to do (there is no easy way to detect cloned interfaces yet) -- BS Web Services, http://www.bsws.de/ OpenBSD-based Webhosting, Mail Services, Managed Servers, ... Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
