On Mon, Nov 10, 2008 at 4:13 AM, Harald Dunkel [EMAIL PROTECTED] wrote:
Hi Theo,
Theo de Raadt wrote:
This appears to be a fairly simple change. Does it sound reasonable to
people with more knowledge of OpenBSD networking?
No, it is not reasonble. You are inventing problems at a very high
Jussi Peltola wrote:
I see no problem in setting interface groups based on mac address.
You should be able to hack a suitable script to do that in a few
minutes.
AFAICS brconfig does not support group names.
Regards
Harri
Hi Theo,
Theo de Raadt wrote:
This appears to be a fairly simple change. Does it sound reasonable to
people with more knowledge of OpenBSD networking?
No, it is not reasonble. You are inventing problems at a very high
level just because some very low level pci-related bug is making some
What about VLANs? At least I wouldn't torture myself with ancient/cheap
switches that don't support them.
Of course, then you have to worry about the switch breaking or getting
its config reset...
On Fri, 7 Nov 2008, johan beisser wrote:
On Nov 7, 2008, at 9:44 AM, Dave Anderson wrote:
Perhaps most of these issues could be dealt with by changing the
network
configuration procedure to have a hierarchy of interface-configuration
files rather than just hostname.interface-name. If
On Fri, Nov 7, 2008 at 1:30 PM, Harald Dunkel [EMAIL PROTECTED] wrote:
In the bad configuration the NIC with 00:30:48:d2:9a:06 is
called em2, in the good one it is called em4. Maybe you
can imagine how PF screws up, if this NIC would have been
physically connected to the Internet.
Surely it
Denis Doroshenko [EMAIL PROTECTED] writes:
what keeps you from writing a script that would be called
from the end of /etc/netstart; the script would check whether the
initialized network interfaces match those described by a
predefined table? in case of failure it would react somehow...
Then
Peter N. M. Hansteen wrote:
Denis Doroshenko [EMAIL PROTECTED] writes:
what keeps you from writing a script that would be called
from the end of /etc/netstart; the script would check whether the
initialized network interfaces match those described by a
predefined table? in case of failure it
Rod Whitworth wrote:
...
Let's look at this a little more analytically:
My firewall is a Soekris 4801 with sis0, sis1 and sis2.
sis0 is the 0utside (ADSL)
sis1 is the 1nside (LAN)
sis2 is the 2erver LAN
heh. I gotta remember that naming/numbering convention, I like it!
If 0 fails the
Hi folks,
Harald Dunkel wrote:
Question: How can I make sure that em2 doesn't become em0
if my dual-port NIC dies? This would be fatal for my firewall
setup. At least the antispoof rules _must_ be bound to the
network devices.
Sorry to wake this thread up again, but this problem is a
Did you fill a bug report?
--
Aram Havarneanu
Peter N. M. Hansteen schrieb:
Harald Dunkel [EMAIL PROTECTED] writes:
maybe you can use something like this in your script:
int_if=xx:xx:xx:xx:xx:xx
ext_if=yy:yy:yy:yy:yy:yy
int_if=`ifconfig|grep -e $int_if|awk '{print $1}'`
ext_if=`ifconfig|grep -e $ext_if|awk '{print $1}'`
This will not
On 13:43:11 Nov 07, Guido Tschakert wrote:
Surely we assume that nobody fakes the mac.
I could be wrong but I don't think it possible to fake the MAC reported
in dmesg(8).
ifconfig can fake MAC address but this should be unique since it is reported by
the NIC whilst probing.
-Girish
Harald Dunkel [EMAIL PROTECTED] writes:
I can post 2 dmesg logs of the same machine with the NIC
names mixed up. Somehow 2 NICs disappeared on a reboot. On
the next reboot they were back. Attached is the diff.
Dodgy hardware does lead to problems, certainly.
The basic problem here is that
Peter N. M. Hansteen wrote:
Harald Dunkel [EMAIL PROTECTED] writes:
Sorry to wake this thread up again, but this problem is a severe
security risk. IMHO it is unacceptable that a hardware failure on
one NIC of a firewall can put the whole network at risk, just because
the mapping between
On Fri, Nov 07, 2008 at 01:22:08PM +0100, Peter N. M. Hansteen wrote:
Unless we make some other unique identifier part of the way PF
evaluates rules (the MAC address comes to mind, but that too can be
changed in any modern operating system), there is no quick fix, other
than rewriting your
On Fri, Nov 7, 2008 at 11:33 AM, Douglas A. Tutty [EMAIL PROTECTED] wrote:
On Fri, Nov 07, 2008 at 01:22:08PM +0100, Peter N. M. Hansteen wrote:
Unless we make some other unique identifier part of the way PF
evaluates rules (the MAC address comes to mind, but that too can be
changed in any
Harald Dunkel [EMAIL PROTECTED] writes:
Sorry to wake this thread up again, but this problem is a severe
security risk. IMHO it is unacceptable that a hardware failure on
one NIC of a firewall can put the whole network at risk, just because
the mapping between NICs and interface names gets
On 2008-11-07, Harald Dunkel [EMAIL PROTECTED] wrote:
Peter N. M. Hansteen wrote:
Harald Dunkel [EMAIL PROTECTED] writes:
Sorry to wake this thread up again, but this problem is a severe
security risk. IMHO it is unacceptable that a hardware failure on
one NIC of a firewall can put the
On Fri, 7 Nov 2008, Harald Dunkel wrote:
Peter N. M. Hansteen wrote:
Harald Dunkel [EMAIL PROTECTED] writes:
Sorry to wake this thread up again, but this problem is a severe
security risk. IMHO it is unacceptable that a hardware failure on
one NIC of a firewall can put the whole network at
Peter N. M. Hansteen wrote:
Harald Dunkel [EMAIL PROTECTED] writes:
Sorry to wake this thread up again, but this problem is a severe
security risk. IMHO it is unacceptable that a hardware failure on
one NIC of a firewall can put the whole network at risk, just because
the mapping
On Nov 7, 2008, at 9:44 AM, Dave Anderson wrote:
Network configuration has bugged me a bit ever since I started using
OpenBSD, not just the real security issue that Harald Dunkel points
out
but general ease of administration issues. For example, on a typical
single-NIC system one ought to
On Fri, Nov 7, 2008 at 3:51 AM, Harald Dunkel [EMAIL PROTECTED] wrote:
Question: How can I make sure that em2 doesn't become em0
if my dual-port NIC dies? This would be fatal for my firewall
setup. At least the antispoof rules _must_ be bound to the
network devices.
Sorry to wake this
On Fri, 07 Nov 2008 13:22:08 +0100, Peter N. M. Hansteen wrote:
Harald Dunkel [EMAIL PROTECTED] writes:
I can post 2 dmesg logs of the same machine with the NIC
names mixed up. Somehow 2 NICs disappeared on a reboot. On
the next reboot they were back. Attached is the diff.
Dodgy hardware
On Fri, Nov 7, 2008 at 12:44 PM, Dave Anderson [EMAIL PROTECTED] wrote:
Network configuration has bugged me a bit ever since I started using
OpenBSD, not just the real security issue that Harald Dunkel points out
but general ease of administration issues. For example, on a typical
single-NIC
On Fri, 7 Nov 2008, Ted Unangst wrote:
On Fri, Nov 7, 2008 at 12:44 PM, Dave Anderson [EMAIL PROTECTED] wrote:
Network configuration has bugged me a bit ever since I started using
OpenBSD, not just the real security issue that Harald Dunkel points out
but general ease of administration issues.
On Fri, 7 Nov 2008, Theo de Raadt wrote:
Peter N. M. Hansteen wrote:
Harald Dunkel [EMAIL PROTECTED] writes:
Sorry to wake this thread up again, but this problem is a severe
security risk. IMHO it is unacceptable that a hardware failure on
one NIC of a firewall can put the whole
On Fri, Nov 7, 2008 at 3:55 PM, Dave Anderson [EMAIL PROTECTED] wrote:
Maybe I'm just confused, but my recollection is that one needs to set up
the appropriate hostname.interface-name to enable the interface before
the egress interface group works.
...
haven't tried this, but maybe you can
One can always postulate a hardware (or other) failure which can't be
dealt with by whatever the current software may be; the question is
whether it happens often enough and is serious enough to be worth doing
something about. Or if it suggests a change which is worthwhile in
itself and also
I see no problem in setting interface groups based on mac address.
You should be able to hack a suitable script to do that in a few
minutes.
On Fri, 7 Nov 2008, Chris Kuethe wrote:
On Fri, Nov 7, 2008 at 3:55 PM, Dave Anderson [EMAIL PROTECTED] wrote:
Maybe I'm just confused, but my recollection is that one needs to set up
the appropriate hostname.interface-name to enable the interface before
the egress interface group works.
...
Hi Henning,
I had posted my startup script configuring network interfaces
according to their MAC address here. But it is still not a big
help, since brconfig doesn't accept the interface group names.
:-(
Regards
Harri
===
Hi Jared,
jared r r spiegel wrote:
On Fri, Aug 22, 2008 at 04:16:38PM +0200, Harald Dunkel wrote:
Hi folks,
Question: How can I make sure that em2 doesn't become em0
if my dual-port NIC dies? This would be fatal for my firewall
setup. At least the antispoof rules _must_ be bound to the
PS: Below is the code, if anybody is interested. Should be run
before /etc/netstart. To use it you should create a file
/etc/ifconfig.xx:xx:xx:xx:xx:xx
for each network device (xx:xx:xx:xx:xx:xx is the MAC
address). Each line is run with
ifconfig if $line
Here is a sample
* Harald Dunkel [EMAIL PROTECTED] [2008-08-22 16:33]:
Question: How can I make sure that em2 doesn't become em0
if my dual-port NIC dies?
[EMAIL PROTECTED] $ dmesg | grep '^em0'
em0 at pci5 dev 0 function 0 Intel PRO/1000 PT (80003ES2) rev 0x01:
apic 2 int 18 (irq 11), address
Hi folks,
Question: How can I make sure that em2 doesn't become em0
if my dual-port NIC dies? This would be fatal for my firewall
setup. At least the antispoof rules _must_ be bound to the
network devices.
Of course I could buy different hardware for the external and
internal network
On Fri, Aug 22, 2008 at 04:16:38PM +0200, Harald Dunkel wrote:
Hi folks,
Question: How can I make sure that em2 doesn't become em0
if my dual-port NIC dies? This would be fatal for my firewall
setup. At least the antispoof rules _must_ be bound to the
network devices.
first thing that
Question: How can I make sure that em2 doesn't become em0
if my dual-port NIC dies? This would be fatal for my firewall
setup. At least the antispoof rules _must_ be bound to the
network devices.
Yep, this is an ugly problem.
You could have a shellscript at boot scan ifconfig output and
38 matches
Mail list logo