Re: PF, Bridge, and IP on bridged interface [more]
[In a message on Wed, 02 Mar 2005 05:34:20 GMT, [EMAIL PROTECTED] wrote:] >In my case, I'm running a SS20 with le* interfaces, which means that >all interfaces use the same ethernet address. I'm curious, doesn't setting local-mac-address? to true doesn't work with LE's? Only HME's and newer? Actually, I guess only quad HME's and newer, according to: http://www.barbary.com/cookbooks/macaddress.html So, I guess that leaves the question, can one change the ethernet address of a NIC with ifconfig on OpenBSD? My 3.5 box doesn't seem to allow it. . . Sean
Re: pf vs ASIC firewalls
> Could Someone please tell me the advantages of PF against Firewalls > using the ASIC technology in terms of Security and perfomance?? Many (most? all?) vendors shipping what they call ASIC firewalls are actually running software on a network processor (NPU). The benefit is that most NPUs will process packets in real-time so if they claim to support X gigabit per second then they can probably sustain that even with minimum sized 64byte ethernet frames; a PF box doesn't stand a chance with that high of a pps rate. The down side to NPUs is that they have to service every packet in a fixed amount of time so they can't do much. They need to have fixed sized state and fragment reassembly tables. They also aren't allowed to do much work per packet. You will also be able to surf Moore's law better with a normal x86 processor than with an NPU. Technically, your intel processor is an asic too. .mike > I happened to hear the following > > "Netscreen is running in ASIC (they are boasting in their marketing) - > and thus probably only is checking the first (or first few) packages and > then handing all traffic control off to dumb packet shoveling hardware. > So probably no checks "later" in the protocol. Similar problem with > CheckPoint's "fastpath" option, btw." > > Thankyou so much > > kind regards > > Siju
Re: pf vs ASIC firewalls
On Mon, Mar 14, 2005 at 03:50:23PM +0530, Siju George wrote: > Could Someone please tell me the advantages of PF against Firewalls > using the ASIC technology in terms of Security and perfomance?? If there is a bug in pf, we'll tell you, and you can apply a patch. If there is a bug in your ASIC, and the vendor tells you at all, there are two options: go back to doing the packet processing in the underpowered CPU, or replace the hardware.
Re: pf vs ASIC firewalls
On Mon, Mar 14, 2005 at 03:50:23PM +0530, Siju George wrote: > So probably no checks "later" in the protocol. Similar problem with > CheckPoint's "fastpath" option, btw." 1) check point fw-1 is software, not hardware. 2) the "fastpath" option hasn't been around since 4.0 (and has always been deprecated). 3) in NG--all packets pass through the deep inspection filter engine (even if you enable the securexl acceleration feature). -j -- "Beer. Now there's a temporary solution." --The Simpsons
Support for tables in ALTQ
Hello, I've been looking for this issue on the archive and Google but
I didn't find anything useful. Anyone has done any work with tables
and altq?
I'm working on a wireless ISP and we are currently shaping our users
with FreeBSD ipfw and pipes. I would like to migrate the server to
OpenBSD with PF to make the rules easier to understand using tables
for common rules (quite common in my configuration) but the problem is
that altq doesn't support tables like filtering does.
I would like to setup something like this:
altq on $iface_inet cbq bandwidth 1Gb queue { default_up, clientes_up }
altq on $iface_radio cbq bandwidth 1Gb queue { default_down, clientes_down }
queue default_up cbq(default)
queue clientes_up bandwidth 8Mb cbq { upload, bronze_up, prata_up,
ouro_up, diamante_up }
queue default_down cbq(default)
queue clientes_down bandwidth 8Mb cbq { download, bronze_down,
prata_down, ouro_down, diamante_down }
queue upload cbq(default)
queue bronze_up bandwidth 64Kb cbq
queue prata_up bandwidth 128Kb cbq
queue ouro_up bandwidth 256Kb cbq
queue diamante_up bandwidth 256Kb cbq
queue download cbq(default)
queue bronze_down bandwidth 64Kb cbq
queue prata_down bandwidth 256Kb cbq
queue ouro_down bandwidth 512Kb cbq
queue diamante_down bandwidth 1Mb cbq
And then apply a rule like this:
pass out on $iface_inet inet from to any keep state
queue ouro_up
pass out on $iface_radio inet from any to keep state
queue ouro_down
Actually this configuration make every client in table
be inside the same queue "ouro_up" or "ouro_down", I would like to
have n queues based on "ouro_up" or "ouro_down" without having to
create every queue.
Is this possible with some modification in the actual code base or it
is a completly different approach? If it is possible without changing
too much code I would probably spend some time making this feature and
releasing it.
Thanks in advance.
Augusto
Please help: Setting up HA Firewall with carp and vlan Interfaces
Hello, I hope this is not too much a switch related problem (and therefore OT): I've got a problem with my ha-setup. Running two firewalls that are clustered (no loadbalancing). Both sides (in- and outgoing) are connected to one switch (Later there will be two switches). State table changes are pronounced over pfsync (em0)(crosslink). Problem is: both firewalls have serveral vlans defined on their outer Interface (fxp0). Of course both vlans are identical, only difference is the mac address. Because of that the firewalls allways complain about duplicate ip-addresses: "duplicate IP address 192.168.90.69 sent from ethernet address 00:10:dc:f1:22:70" How to solve this? Do I have to setup a carp interface for every vlan? But I guess this didn't solve the problem. At all its working, but this warning messages keep spoiling my logs and it's definitely not a clean solution. Some more informations: uname -a: OpenBSD bsd_node1.smc-d.de 3.6 GENERIC#0 i386 sysctl net.inet.carp: net.inet.carp.allow=1 net.inet.carp.preempt=1 net.inet.carp.log=0 net.inet.carp.arpbalance=0 ifconfig -a: rl0: flags=8943 mtu 1500 address: 00:0a:cd:05:18:e8 media: Ethernet 100baseTX full-duplex status: active inet 192.168.90.248 netmask 0xffe0 broadcast 192.168.90.255 em0: flags=8843 mtu 1500 address: 00:10:dc:f5:b2:0b media: Ethernet 1000baseT full-duplex status: active inet 10.10.10.1 netmask 0xfffc broadcast 10.10.10.3 fxp0: flags=8943 mtu 1500 address: 00:10:dc:f5:b2:0c media: Ethernet 100baseTX full-duplex status: active inet 5.5.5.5 netmask 0xfff8 broadcast 5.5.5.7 pflog0: flags=141 mtu 33224 pfsync0: flags=41 mtu 1348 pfsync: syncif: em0 maxupd: 128 vlan9: flags=8843 mtu 1500 address: 00:10:dc:f5:b2:0c vlan: 9 parent interface: fxp0 inet 82.210.20.190 netmask 0xfff8 broadcast 82.210.20.191 ---snip--- (here several more vlans) ---snip--- carp0: flags=41 mtu 1500 carp: MASTER vhid 1 advbase 1 advskew 0 inet 192.168.90.249 netmask 0xffe0 carp1: flags=41 mtu 1500 carp: MASTER vhid 2 advbase 1 advskew 0 inet 5.5.5.6 netmask 0xfff8 netstat -sp carp: carp: 18 packets received (IPv4) 0 packets received (IPv6) 0 packets discarded for bad interface 0 packets shorter than header 0 discarded for bad checksums 0 discarded packets with a bad version 0 discarded because packet too short 0 discarded for bad authentication 0 discarded for bad vhid 0 discarded because of a bad address list 159542 packets sent (IPv4) 0 packets sent (IPv6) Thank you for any hints/replies. Olaf Zenker Systemmanager SMC Düsseldorf T-Systems International GmbH Global Network Factory Systemmanagement Customer Solutions Sohnstr.45, 40237 Düsseldorf +49 211-9148-620 (tel) +49 211-9148-975 (fax) E-Mail: [EMAIL PROTECTED] Internetseite: http://www.t-systems.com
pf vs ASIC firewalls
Hi all, Could Someone please tell me the advantages of PF against Firewalls using the ASIC technology in terms of Security and perfomance?? I happened to hear the following "Netscreen is running in ASIC (they are boasting in their marketing) - and thus probably only is checking the first (or first few) packages and then handing all traffic control off to dumb packet shoveling hardware. So probably no checks "later" in the protocol. Similar problem with CheckPoint's "fastpath" option, btw." Thankyou so much kind regards Siju
