Re: Start 2 instances of ftp-proxy one for ftp one for reverse proxy
Le 17/01/2018 à 22:24, Mik J a écrit : Hello, I'd like my firewall to start two instances one for ftp proxy and one for ftp proxy.So far I have in rc.confftpproxy_flags="-D7 -v -p 8021" I can run manually/usr/sbin/ftp-proxy -D7 -v -R 10.1.1.1 -p21 -b 3and the reverse proxy works But I would like these to instance to start automatically I tried this but it didn't workhttp://misc.openbsd.narkive.com/Highrohk/multiple-instances-of-ftp-proxy Thank you Hello, # ls -l /etc/rc.d/ftpproxy_ [...] /etc/rc.d/ftpproxy_ -> /etc/rc.d/ftpproxy # ls -l /etc/rc.d/ftpproxy_ [...] /etc/rc.d/ftpproxy_ -> /etc/rc.d/ftpproxy # grep ftp /etc/rc.conf.local ftpproxy__flags=-R 172.16.129.10 -p 8035 ftpproxy__flags=-R 172.16.129.24 -p 8036 (or whatever options you need) I was pretty sure i read this in man pages but i don't find where at the moment.
Re: Start 2 instances of ftp-proxy one for ftp one for reverse proxy
Le 18/01/2018 à 10:37, Mathieu BLANC a écrit : Le 17/01/2018 à 22:24, Mik J a écrit : Hello, I'd like my firewall to start two instances one for ftp proxy and one for ftp proxy.So far I have in rc.confftpproxy_flags="-D7 -v -p 8021" I can run manually/usr/sbin/ftp-proxy -D7 -v -R 10.1.1.1 -p21 -b 3and the reverse proxy works But I would like these to instance to start automatically I tried this but it didn't workhttp://misc.openbsd.narkive.com/Highrohk/multiple-instances-of-ftp-proxy Thank you Hello, # ls -l /etc/rc.d/ftpproxy_ [...] /etc/rc.d/ftpproxy_ -> /etc/rc.d/ftpproxy # ls -l /etc/rc.d/ftpproxy_ [...] /etc/rc.d/ftpproxy_ -> /etc/rc.d/ftpproxy # grep ftp /etc/rc.conf.local ftpproxy__flags=-R 172.16.129.10 -p 8035 ftpproxy__flags=-R 172.16.129.24 -p 8036 (or whatever options you need) I was pretty sure i read this in man pages but i don't find where at the moment. man rcctl : The recommended way to run a second copy of a given daemon for a different purpose is to create a symbolic link to its rc.d(8) control script: # ln -s /etc/rc.d/snmpd /etc/rc.d/snmpd6 # rcctl set snmpd6 status on # rcctl set snmpd6 flags -D addr=2001:db8::1234 # rcctl start snmpd6
Re: 6.1-stable: kernel panic on pf_state_key_unref()
Le 07/09/2017 à 05:59, Maxim Bourmistrov a écrit : Hey, Got kernel panic on 6.1-stable during ’rcctl restart relayd’. Sorry for PNG below. Hi, It has been fixed with this diff : http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf.c.diff?r1=1.1034=1.1035
Re: Kernel panic on Dell R210 with OpenBSD 6.0 (relayd related ?)
On Tue, May 02, 2017 at 05:03:20PM +, Stuart Henderson wrote: > Probably the best thing to do at this point is to write a mail to bugs@: > > 1. describe what the machine is doing in detail. carp? ipsec? pfsync? > what sort of relays? include config (sanitized if necessary, but do that > consistently). > > 2. copy in the panic message and stack trace as text (re-type it, > don't attach a picture or send a link to a picture). > > 3. make it a self-contained report with description etc all in the one > message, don't rely on people having message history. > > 4. include dmesg. Hi Stuart, Thx for your answer ! I didn't have the time to work on this since early may. But from time to time, I check the commit on pf.c and I saw this one which seemed to perfectly match my bug : http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf.c?rev=1.1035=text/x-cvsweb-markup I tried the diff, and it seems to be OK ! I can't trigger the bug right now (it was 100% before). So, thx you again, and special thx to bluhm@ who made the patch ! -- Mathieu
Re: Kernel panic on Dell R210 with OpenBSD 6.0 (relayd related ?)
On Tue, May 02, 2017 at 03:44:43PM +0200, Andre Ruppert wrote: > Hi, > > Im running 6.0 amd64 on a pair of R210 with relayd, but these are R210 (II). > > No kernel panics at all, and these systems are working in a live > environment... > > Regards > Andre Hi, Yes, i have also several OpenBSD on R210 + 6.0 (or 6.1) + relayd and it works like a charm. The only problem appeared when an admin did a REJECT (iptables) on one on the host checked by relayd with check tcp (i tried to put all the details i could in the previous mails). The next step is to try with current (until now i've waited for the 6.1 release which was very close to be released). -- Mathieu
Re: Kernel panic on Dell R210 with OpenBSD 6.0 (relayd related ?)
On Wed, Mar 29, 2017 at 02:06:23PM +0200, Mathieu BLANC wrote:
> It also kernel panics with just this pf rules :
> # cat pf_minimal.conf
> set limit { states 10 }
> set skip on lo
> anchor "relayd/*"
> pass
>
I upgraded the system to 6.1 release last week, the kernel panic is still here
(with the same logs).
--
Mathieu
Re: Kernel panic on Dell R210 with OpenBSD 6.0 (relayd related ?)
On Wed, Mar 29, 2017 at 10:40:08AM +0200, Mathieu BLANC wrote:
> On Tue, Mar 28, 2017 at 05:58:02PM +0200, Hiltjo Posthuma wrote:
> > On Tue, Mar 28, 2017 at 02:39:44PM +0200, Mathieu BLANC wrote:
> > > On Tue, Mar 28, 2017 at 02:22:28PM +0200, Mathieu BLANC wrote:
> > > > I can reproduce the bug (on the slave firewall) as many times as I want.
> > > >
> > >
> > > I've just read https://www.openbsd.org/ddb.html and saw that you need a
> > > trace
> > > for all cpu.
> > >
> > > http://www.hostingpics.net/viewer.php?id=238876panic9.jpg
> > > http://www.hostingpics.net/viewer.php?id=275943panic10.jpg
> > > http://www.hostingpics.net/viewer.php?id=375143panic11.jpg
> > > http://www.hostingpics.net/viewer.php?id=220012panic12.jpg
> > >
> > > (it's a different crash from the last screenshots i've made, if it's not
> > > good i
> > > can provide a full new set of pics)
> > >
> > > --
> > > Mathieu
> > >
> >
> > Hey,
> >
> > Can you also provide your pf.conf ?
> >
> > Can you test if it also happens on -current?
> >
> > --
> > Kind regards,
> > Hiltjo
>
> Hello,
>
> Unfortunately, i can't provide pf.conf as is (too many references to
> customers,
> ips, etc...). But i think i can work on a minimal file which triggers the bug.
> I'll see that.
>
It also kernel panics with just this pf rules :
# cat pf_minimal.conf
set limit { states 10 }
set skip on lo
anchor "relayd/*"
pass
--
Mathieu
Re: Kernel panic on Dell R210 with OpenBSD 6.0 (relayd related ?)
On Tue, Mar 28, 2017 at 05:58:02PM +0200, Hiltjo Posthuma wrote: > On Tue, Mar 28, 2017 at 02:39:44PM +0200, Mathieu BLANC wrote: > > On Tue, Mar 28, 2017 at 02:22:28PM +0200, Mathieu BLANC wrote: > > > I can reproduce the bug (on the slave firewall) as many times as I want. > > > > > > > I've just read https://www.openbsd.org/ddb.html and saw that you need a > > trace > > for all cpu. > > > > http://www.hostingpics.net/viewer.php?id=238876panic9.jpg > > http://www.hostingpics.net/viewer.php?id=275943panic10.jpg > > http://www.hostingpics.net/viewer.php?id=375143panic11.jpg > > http://www.hostingpics.net/viewer.php?id=220012panic12.jpg > > > > (it's a different crash from the last screenshots i've made, if it's not > > good i > > can provide a full new set of pics) > > > > -- > > Mathieu > > > > Hey, > > Can you also provide your pf.conf ? > > Can you test if it also happens on -current? > > -- > Kind regards, > Hiltjo Hello, Unfortunately, i can't provide pf.conf as is (too many references to customers, ips, etc...). But i think i can work on a minimal file which triggers the bug. I'll see that. Fur -current, my idea was to try if i didn't get any response on the list for -stable. But for now, we don't have any -current in production so i'm not sure :) I know there are plenty of people who have -current, i'm pretty confident with it, but it's more a question of procedure, for example how to follow -current efficiently over time. With -release and -stable it's pretty simple, upgrade every 6 months + a few patch and it's ok :) -- Mathieu
Re: Kernel panic on Dell R210 with OpenBSD 6.0 (relayd related ?)
On Tue, Mar 28, 2017 at 02:22:28PM +0200, Mathieu BLANC wrote: > I can reproduce the bug (on the slave firewall) as many times as I want. > I've just read https://www.openbsd.org/ddb.html and saw that you need a trace for all cpu. http://www.hostingpics.net/viewer.php?id=238876panic9.jpg http://www.hostingpics.net/viewer.php?id=275943panic10.jpg http://www.hostingpics.net/viewer.php?id=375143panic11.jpg http://www.hostingpics.net/viewer.php?id=220012panic12.jpg (it's a different crash from the last screenshots i've made, if it's not good i can provide a full new set of pics) -- Mathieu
Re: Kernel panic on Dell R210 with OpenBSD 6.0 (relayd related ?)
On Tue, Mar 28, 2017 at 12:05:56PM +0300, Mihai Popescu wrote:
> Isn't there a CAPSLOOK written message at panic time on the screen?
> If not, look here:
> http://www.openbsd.org/report.html
>
I can reproduce the bug (on the slave firewall) as many times as I want.
I made some screenshots. Sorry, I didn't manage to provide text logs (i'm in
DRAC).
In http://man.openbsd.org/OpenBSD-6.0/crash i saw that i might be able to have
the ddb logs in dmesg after a warm reboot but it didn't work for me.
I don't know if you prefer http links or attached files. I have uploaded the
jpg here :
http://www.hostingpics.net/viewer.php?id=835545panic1.jpg
http://www.hostingpics.net/viewer.php?id=149061panic2.jpg
http://www.hostingpics.net/viewer.php?id=328015panic3.jpg
http://www.hostingpics.net/viewer.php?id=730910panic4.jpg
http://www.hostingpics.net/viewer.php?id=607164panic5.jpg
http://www.hostingpics.net/viewer.php?id=272177panic6.jpg
http://www.hostingpics.net/viewer.php?id=689399panic7.jpg
http://www.hostingpics.net/viewer.php?id=499214panic8.jpg
I can attach the files if you want.
Here is my relayd conf :
_front_vip="A.B.C.D"
_front1="E.F.G.H"
_front2="I.J.K.L"
table { $_front1 $_front2 }
redirect _http_vip {
listen on $_front_vip port http
forward to mode source-hash check tcp
pftag RELAYD_VIP_NAT
}
On front1, if i made this command, my openbsd system crash. With DROP instead
of REJECT it's OK (tested 5-6 times) :
iptables -I INPUT -j REJECT -p tcp --dport 80 -s
--
Mathieu
Re: Kernel panic on Dell R210 with OpenBSD 6.0 (relayd related ?)
On Mon, Mar 27, 2017 at 02:42:23PM +0200, Mathieu BLANC wrote: > Hello all, > > I have a pair of firewalls running 6.0 (patched with openup in october, no > patch > applied since then). > > Since the upgrade, this pair has some problem with kernel > panics (4 times since the upgrade in october). > > The last one was this morning. The two firewall crashed at the same time with > these logs : > > /bsd: panic: kernel diagnostic assertion "(sk->inp == NULL) || > (sk->inp->inp_pf_sk == NULL)" failed: file "../../../../net/pf.c", line 6891 > /bsd: Starting stack trace... > /bsd: panic() at panic+0x10b > /bsd: __assert() at __assert+0x25 > /bsd: pf_state_key_unref() at pf_state_key_unref+0xc6 > /bsd: pf_pkt_unlink_state_key() at pf_pkt_unlink_state_key+0x15 > /bsd: m_free() at m_free+0xa0 > /bsd: sbdroprecord() at sbdroprecord+0x61 > /bsd: soreceive() at soreceive+0xb4f > /bsd: recvit() at recvit+0x139 > /bsd: sys_recvfrom() at sys_recvfrom+0x9d > /bsd: syscall() at syscall+0x27b > /bsd: --- syscall (number 29) --- > /bsd: end of kernel > /bsd: end trace frame: 0x7f7dc870, count: 247 > /bsd: 0x18ccb3b21ada: > /bsd: End of stack trace. > Hello, This morning, another crash. I found in daemon.log something very interesting. At the same second the firewall crashed, i had the same resource checked by relayd which was gone down : Yesterday : Mar 27 11:51:48 fw5 relayd[94179]: host W.X.Y.Z, check tcp (16010ms,tcp connect timeout), state up -> down, availability 99.94% Mar 27 11:51:48 fw5 relayd[89662]: table _http_vip: 0 added, 1 deleted, 0 changed, 0 killed This morning : Mar 28 09:08:54 fw5 relayd[46733]: host W.X.Y.Z, check tcp (16010ms,tcp connect timeout), state up -> down, availability 99.95% Mar 28 09:08:54 fw5 relayd[29633]: table _http_vip: 0 added, 1 deleted, 0 changed, 0 killed I called the admin in charge of host W.X.Y.Z. What he did on W.X.Y.Z was an iptables REJECT command on the host (to remove it from relayd). We have tested with DROP and it seems to not trigger the bug (i'll try to make more tests).
Kernel panic on Dell R210 with OpenBSD 6.0
Hello all, I have a pair of firewalls running 6.0 (patched with openup in october, no patch applied since then). Since the upgrade, this pair has some problem with kernel panics (4 times since the upgrade in october). The last one was this morning. The two firewall crashed at the same time with these logs : /bsd: panic: kernel diagnostic assertion "(sk->inp == NULL) || (sk->inp->inp_pf_sk == NULL)" failed: file "../../../../net/pf.c", line 6891 /bsd: Starting stack trace... /bsd: panic() at panic+0x10b /bsd: __assert() at __assert+0x25 /bsd: pf_state_key_unref() at pf_state_key_unref+0xc6 /bsd: pf_pkt_unlink_state_key() at pf_pkt_unlink_state_key+0x15 /bsd: m_free() at m_free+0xa0 /bsd: sbdroprecord() at sbdroprecord+0x61 /bsd: soreceive() at soreceive+0xb4f /bsd: recvit() at recvit+0x139 /bsd: sys_recvfrom() at sys_recvfrom+0x9d /bsd: syscall() at syscall+0x27b /bsd: --- syscall (number 29) --- /bsd: end of kernel /bsd: end trace frame: 0x7f7dc870, count: 247 /bsd: 0x18ccb3b21ada: /bsd: End of stack trace. I have another pair of firewalls with the same hardware (Dell R210) which is running without problem. After the crash this morning, i applied the last patches with openup. But after reading the errata page, i'm not sure it will help... Or maybe this one could be related : https://ftp.openbsd.org/pub/OpenBSD/patches/6.0/common/019_pf.patch.sig ? Thank you very much ! -- Mathieu OpenBSD 6.0 (GENERIC.MP) #2: Mon Oct 17 10:22:47 CEST 2016 r...@stable-60-amd64.mtier.org:/binpatchng/work-binpatch60-amd64/src/sys/arch/amd64/compile/GENERIC.MP real mem = 1047105536 (998MB) avail mem = 1010954240 (964MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x3f79c000 (63 entries) bios0: vendor Dell Inc. version "1.10.0" date 09/10/2013 bios0: Dell Inc. PowerEdge R210 acpi0 at bios0: rev 2 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP APIC SPCR HPET DM__ MCFG WD__ SLIC ERST HEST BERT EINJ TCPA SSDT acpi0: wakeup devices PCI0(S5) USBA(S0) USBB(S0) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU L3406 @ 2.27GHz, 2261.27 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 132MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE cpu1 at mainbus0: apid 4 (application processor) cpu1: Intel(R) Xeon(R) CPU L3406 @ 2.27GHz, 2260.99 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 2, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Xeon(R) CPU L3406 @ 2.27GHz, 2260.99 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 5 (application processor) cpu3: Intel(R) Xeon(R) CPU L3406 @ 2.27GHz, 2260.99 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 2, package 0 ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins acpihpet0 at acpi0: 14318179 Hz acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (LYD0) acpiprt2 at acpi0: bus -1 (LYD2) acpiprt3 at acpi0: bus 1 (HVD0) acpiprt4 at acpi0: bus -1 (HVD2) acpiprt5 at acpi0: bus 5 (PEX0) acpiprt6 at acpi0: bus -1 (PEX4) acpiprt7 at acpi0: bus -1 (PEX5) acpiprt8 at acpi0: bus 6 (COMP) acpicpu0 at acpi0: C3(350@96 mwait.1@0x20), C1(1000@1 mwait.1) acpicpu1 at acpi0: C3(350@96 mwait.1@0x20), C1(1000@1 mwait.1) acpicpu2 at acpi0: C3(350@96 mwait.1@0x20), C1(1000@1 mwait.1) acpicpu3 at acpi0: C3(350@96 mwait.1@0x20), C1(1000@1 mwait.1) "PNP0C33" at acpi0 not configured "ACPI000D" at acpi0 not configured "PNP0501" at acpi0 not configured "PNP0501" at acpi0 not configured "IPI0001" at acpi0 not configured "PNP0C14" at acpi0 not configured ipmi at mainbus0 not configured pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core Host" rev 0x18 ppb0 at pci0 dev 1
Re: Relayd and stateful tracking options
On Tue, Aug 09, 2016 at 04:33:33PM +0200, Sebastian Benoit wrote:
> Mathieu BLANC(mathieu.bl...@smile.fr) on 2016.08.09 11:18:57 +0200:
> > Hello,
> >
> > I'm using relayd with Redirections (OpenBSD 5.9)
> > Relayd creates these rdr-to rules :
> > anchor "_http" all {
> > pass in quick on rdomain 0 inet proto tcp from any to A.B.C.D port = 80
> > flags S/SA keep state (tcp.established 600) rdr-to port 80
> > round-robin
> > }
> >
> > Is there a way to modify the Stateful Tracking Options after keep state ?
> > (I'd
> > want to add a max state on a specific redirection)
> >
> > Thanks !
>
> Use the "pftag name" option.
>
> That will change the inserted rule to not have the quick keyword. Also it
> gets a "tagged name" added.
>
> Then, in pf.conf add another rule
>
> pass in tagged name keep state (max 3)
>
Just tried your solution, it's perfect ;)
I've used "match pftag name".
Thank you !
(in the man :
[match] pftag name
Automatically tag packets passing through the pf(4) rdr-to rule
with the name supplied. This allows simpler filter rules. The
optional match keyword will change the default rule action from
`pass in quick' to `match in' to allow further evaluation in the
pf ruleset using the tagged name rule option.
)
--
Mathieu
Relayd and stateful tracking options
Hello,
I'm using relayd with Redirections (OpenBSD 5.9)
Relayd creates these rdr-to rules :
anchor "_http" all {
pass in quick on rdomain 0 inet proto tcp from any to A.B.C.D port = 80 flags
S/SA keep state (tcp.established 600) rdr-to port 80 round-robin
}
Is there a way to modify the Stateful Tracking Options after keep state ? (I'd
want to add a max state on a specific redirection)
Thanks !
--
Mathieu
Re: ipsec.conf parsing
On Wed, Mar 19, 2014 at 10:22:43AM +, Zé Loff wrote: As far as I can tell, if a commented line on ipsec.conf ends with \ then the following line will also be considered a comment (if the next line also ends with \ the commenting is propagated). For example #ike esp from A.A.A.A to C.C.C.C \ ike esp from A.A.A.A to B.B.B.B \ srcid foo.example.com dstid bar.example.com is treated as a commented block, instead of setting up a tunnel from A.A.A.A to B.B.B.B. I find this a bit surprising... What should be fixed: the parser, ipsec.conf.5 or my expectations? Don't know what should be fixed, but it's exactly the same thing in pf.conf -- mabla
Relayd redirect from LAN
Hello misc,
With redirects in relayd, I thought that access the VIP from inside was
impossible.
With a classic conf (found in man relayd.conf) like this :
redirect www {
listen on www.example.com port 80
forward to service check http / code 200
}
Relayd will create this type of rule :
pass in quick on rdomain 0 inet proto tcp from any to XX.XX.XX.XX port =
80 flags S/SA keep state (tcp.established 600) rdr-to www port 80
round-robin
And servers in www can't wget http://www.example.com;.
This is a typical problem of reflection which is well documented here
with several solutions : http://openbsd.org/faq/pf/rdr.html#reflect
For a classic rdr-to, I used to apply the solution RDR-TO and NAT-TO
Combination, but with relayd i thought this was not possible (don't
know why...).
The solution is actually pretty simple, and you can nearly follow
blindly the FAQ.
The only thing is that I used the tag keyword in relayd.conf.
For example :
In relayd.conf :
redirect www {
listen on www.example.com port 80
forward to service check http / code 200
tag RELAYD_WWW
}
In pf.conf :
pass out on $int_if tagged RELAYD_WWW received-on $int_if nat-to $int_if
Servers in www (or others servers in the same LAN) can now access to
www.example.com (vip) and will be load-balanced by the firewall. The web
servers will see the IP of $int_if as the source IP.
I write this just in case someone is interested :-)
I once saw someone in misc@ who asked why he couldn't access to the VIP
from inside the LAN, and he resolved his problem by switching to relay
instead of redirect, which is maybe not what he really wanted to.
--
Mathieu
Re: Relayd crash on reload
Le 16/07/2013 15:53, Mathieu BLANC a écrit : Hi ! I have read several mails/bug in the mailing list about reloading relayd. But i didn't understand if all the bugs were fixed or not ? [...] If i launch the daemon with relayd -d -vvv, and relayctl reload, i have this error : parent_sig_handler: reload requested with SIGHUP parent_reload: level 0 config file /etc/relayd.conf relayd in free(): error: chunk is already free 0x139b3e2e6400 init_filter: filter init done init_tables: created 0 tables flush_table: flushed table std_https1 kill_tables: deleted 1 tables flush_rulesets: flushed rules pfe exiting, pid 1270 lost child: hce terminated; signal 6 relay exiting, pid 18390 relay exiting, pid 17435 relay exiting, pid 579 relay exiting, pid 7823 relay exiting, pid 25910 parent terminating, pid 23068 I know that relayd can't be reloaded if we have relays with SSL, but i've just a redirect (with check https...). I've tested with check tcp (and not check https /), and it seems that reload is OK with this ! Am I missing something ? Thanks in advance ! Sebastian (benoit-li...@fb12.de) asked me to test this patch : http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/relayd/ssl.c.diff?r1=1.18;r2=1.19;sortby=date I've tried this morning, and relayctl reload doesn't crash anymore. Thanks to him ;) -- Mathieu
Relayd crash on reload
Hi !
I have read several mails/bug in the mailing list about reloading
relayd. But i didn't understand if all the bugs were fixed or not ?
Here is my relayd.conf (OpenBSD 5.3, amd64) :
# Global Options
interval 10
timeout 2000
log updates
std_vip_ssl1=X.X.X.X
std_proxy=172.17.1.4
table std_proxy_hosts { $std_proxy }
table std_proxy_fallback { 172.17.1.5 }
redirect std_https1 {
listen on $std_vip_ssl1 port https
# Tag every packet that goes thru the rdr rule with RELAYD
tag STDPRODSSL1
forward to std_proxy_hosts check https / host
www..com code 200
forward to std_proxy_fallback check tcp
}
Everything is fine with this config (redirect and tables active, hosts
active), but relayd crashes if i reload (/etc/rc.d/relayd reload,
without error in the log)
If i launch the daemon with relayd -d -vvv, and relayctl reload, i
have this error :
parent_sig_handler: reload requested with SIGHUP
parent_reload: level 0 config file /etc/relayd.conf
relayd in free(): error: chunk is already free 0x139b3e2e6400
init_filter: filter init done
init_tables: created 0 tables
flush_table: flushed table std_https1
kill_tables: deleted 1 tables
flush_rulesets: flushed rules
pfe exiting, pid 1270
lost child: hce terminated; signal 6
relay exiting, pid 18390
relay exiting, pid 17435
relay exiting, pid 579
relay exiting, pid 7823
relay exiting, pid 25910
parent terminating, pid 23068
I know that relayd can't be reloaded if we have relays with SSL, but
i've just a redirect (with check https...). I've tested with check tcp
(and not check https /), and it seems that reload is OK with this !
Am I missing something ?
Thanks in advance !
Dmesg :
OpenBSD 5.3 (GENERIC.MP) #62: Tue Mar 12 18:21:20 MDT 2013
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2136576000 (2037MB)
avail mem = 2057265152 (1961MB)
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0x7f79c000 (63 entries)
bios0: vendor Dell Inc. version 1.5.2 date 10/18/2010
bios0: Dell Inc. PowerEdge R210
acpi0 at bios0: rev 2
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC SPCR HPET DM__ MCFG WD__ SLIC ERST HEST
BERT EINJ TCPA SSDT
acpi0: wakeup devices PCI0(S5) USBA(S0) USBB(S0)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Pentium(R) CPU G6950 @ 2.80GHz, 2793.34 MHz
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,POPCNT,NXE,LONG,LAHF,PERF,ITSC
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: apic clock running at 132MHz
cpu1 at mainbus0: apid 4 (application processor)
cpu1: Intel(R) Pentium(R) CPU G6950 @ 2.80GHz, 2792.99 MHz
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,POPCNT,NXE,LONG,LAHF,PERF,ITSC
cpu1: 256KB 64b/line 8-way L2 cache
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins
acpihpet0 at acpi0: 14318179 Hz
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (LYD0)
acpiprt2 at acpi0: bus -1 (LYD2)
acpiprt3 at acpi0: bus 1 (HVD0)
acpiprt4 at acpi0: bus -1 (HVD2)
acpiprt5 at acpi0: bus 2 (PEX0)
acpiprt6 at acpi0: bus -1 (PEX4)
acpiprt7 at acpi0: bus -1 (PEX5)
acpiprt8 at acpi0: bus 3 (COMP)
acpicpu0 at acpi0: C3, C1
acpicpu1 at acpi0: C3, C1
ipmi at mainbus0 not configured
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 vendor Intel, unknown product 0x0048
rev 0x12
ppb0 at pci0 dev 1 function 0 vendor Intel, unknown product 0x0049 rev
0x12: msi
pci1 at ppb0 bus 1
em0 at pci1 dev 0 function 0 Intel PRO/1000 (82576) rev 0x01: msi,
address 00:1b:21:86:40:20
em1 at pci1 dev 0 function 1 Intel PRO/1000 (82576) rev 0x01: msi,
address 00:1b:21:86:40:21
ehci0 at pci0 dev 26 function 0 Intel 3400 USB rev 0x05: apic 0 int 22
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1
ppb1 at pci0 dev 28 function 0 Intel 3400 PCIE rev 0x05
pci2 at ppb1 bus 2
bnx0 at pci2 dev 0 function 0 Broadcom BCM5716 rev 0x20: apic 0 int 16
bnx1 at pci2 dev 0 function 1 Broadcom BCM5716 rev 0x20: apic 0 int 17
ehci1 at pci0 dev 29 function 0 Intel 3400 USB rev 0x05: apic 0 int 22
usb1 at ehci1: USB revision 2.0
uhub1 at usb1 Intel EHCI root hub rev 2.00/1.00 addr 1
ppb2 at pci0 dev 30 function 0 Intel 82801BA Hub-to-PCI rev 0xa5
pci3 at ppb2 bus 3
vga1 at pci3 dev 3 function 0 Matrox MGA G200eW rev 0x0a
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcib0 at pci0 dev 31 function 0 Intel 3420 LPC rev 0x05
ahci0 at pci0 dev 31 function 2 Intel 3400 AHCI rev 0x05: msi, AHCI 1.3
scsibus0 at ahci0: 32 targets
sd0 at scsibus0 targ 0 lun 0: ATA, WDC
Re: pfsync/carp causing large number of network errors
On 06/12/2012 06:38 PM, Peter N. M. Hansteen wrote: Myles Merrellgutter...@yahoo.com writes: Recently, we noticed all of our network traffic inside the firewall slowed down to the point where it was difficult to access anything. After some nosing around we noticed that f2, the em2 interface which is using CARP pfsync, was causing an extremely large amounts of errors, essentially choking out the rest of the network traffic. possibly dumb question but better eliminate the obvious: you did set up a separate network for the pfsync traffic? my next thought is that large numbers of errors on a specific interface tends to point to a hardware problem, either the card itself, the cables involved or the switch port. - P Hi, I'm using OpenBSD 5.1 on 2 Dell R210 (with em interfaces) and i ran into the same problem two weeks ago. We tried to upgrade all the firmware cards with the Dell utility (F10 in Bios) and for the moment, the problem has gone away (but we're not sure this is not a coincidence). -- Mathieu
Ospfd : choose between 2 default routes
Hello ! I have an OSPF setup with 4 routers : INTERNET || C1 C2 || O1 O2 || NE1 NE2 C1 and C2 are Cisco Routers, O1 and O2 OpenBSD. OSPF is used between C1/C2/O1/O2 NE1 is the network managed by O1, NE2 the network managed by O2. C1 and C2 distribute a default route to O1/O2 (same metric) Is there a way, in ospfd, to say to O1 : C1 is your prefered default route and to O2 : C2 is your prefered default route ? The link between O1---C2 (and O2---C1) is a very slow line and should be used just as backup. If i use different metric on C1/C2, i think O1 and O2 will use the same router (and by the way one of them will use the slow link). Maybe i have missed something ? Thank you in advance ! -- Mathieu
Re: PF and label for traffic Accounting
Le 19/09/2011 02:33, Simon Chang a icrit : Hello, Hi, Instead of driving yourself crazy with labelling traffic, one very simple way is to use pfstat. The package will even generate good-looking graphs for you and you can post them anywhere you wish. When I looked to pfstat, I didn't see the feature i want : bandwith per IP (webserverA = 1.2 Mbps, webserverB = 11 Mbps...). But maybe i have missed something :) Nevermind, I put the label in my pf.conf and it looks to work very well (munin is used to grab the pfctl -sl output and the Mbps of the webservers are coherent) But i wasn't sure to understand why my first rule doesn't match and the second does. -- Mathieu
PF and label for traffic Accounting
Hello, I try to do some traffic accounting with my OpenBSD 4.9. The goal : know how much traffic a web server sent behind the firewall. Here is an example : ClientA - FW OpenBSD WebServerA (192.168.1.10) I tried to do this in my very simple pf.conf (not in production :] ) pass match proto tcp from 192.168.1.10 port 80 to any label www (I was trying to match all traffic sent by 192.168.1.10 and with source port 80) And : ClientA:~$ wget http://192.168.1.10/1GB_file But the counters in pfctl -sl didn't change (stuck to 0) I managed to have a good counter (1GB in total bytes) with this rule : match proto tcp from any to 192.168.1.10 port 80 label www But I don't get the point and i'd like to understand :) Why the first rule doesn't match ? I was thinking the second rule will just match the traffic sent by ClientA (just a little GET request). I think I'm missing something :) Thanks in advance for your help ! -- Mathieu
Re: OpenOSPF + CARP
Le 05/09/2011 19:30, Stuart Henderson a icrit :
On 2011-09-05, Mathieu Blancmathieu.bl...@smile.fr wrote:
So the ingoing traffic goes into bsd1, and the servers now use bsd2 to
go out.
Is it not a problem ? In terms of firewalling for example (keep state ?
will bsd2 authorize the trafic which is initiated by bsd1 ? maybe with
the help of pfsync ??)
pfsync(4) can handle this if you use 'defer', see the pfsync manpage,
but this is normally only desirable for load-balancing.
I read the manpage, and it seems to match exactly with what i want to do :
Where more than one firewall might actively handle packets, e.g. with
certain ospfd(8), bgpd(8) or carp(4) configurations, it is beneficial to
defer transmission of the initial packet of a connection. The pfsync
state insert message is sent immediately; the packet is queued until
either this message is acknowledged by another system, or a timeout has
expired.
This is for load-sharing between 2 firewalls, you don't want it for a
typical setup with 1 active and 1 passive firewall as it delays things
If I take my previous example :
Network A [interconnection with others routers] = 192.168.1.0/24
(configured on em0, and carp0)
presumably you are announcing the networks behind bsd1/bsd2 over
ospf to your other routers; so I don't think carp0 is useful.
Network B [network with servers] = 172.16.1.0/24 (configured on em1, and
carp1, used by servers for default gateway)
em2 is for pfsync.
The ospfd.conf is very simple.
bsd1# ifconfig -A
em0: flags=8b43UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST
inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255
em1: flags=8b43UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST
inet 172.16.1.1 netmask 0xff00 broadcast 172.16.1.255
em2: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
inet 172.16.99.1 netmask 0xfffc broadcast 172.16.99.3
pfsync0: flags=41UP,RUNNING mtu 1500
pfsync: syncdev: em2 syncpeer: 172.16.99.2 maxupd: 128 defer: off
carp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
carp: MASTER carpdev em0 vhid 170 advbase 1 advskew 80
inet 192.168.1.100 netmask 0xff00 broadcast 192.168.1.255
carp1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
carp: MASTER carpdev em1 vhid 171 advbase 1 advskew 120
inet 172.16.1.100 netmask 0xff00 broadcast 172.16.1.255
bsd1# cat /etc/ospfd.conf
area 0.0.0.0 {
interface em0
interface em1
interface carp0 { passive }
interface carp1 { passive }
}
I would:-
remove interface carp0 { passive } from ospfd.conf
remove interface em1 from ospfd.conf
ospfctl reload
ifconfig carp0 destroy
rm /etc/hostname.carp0
Wow !
It works like a charm ;)
I now have just *one* route to Network B on my routers (routers in
Network A) : the IP of bsd1 (192.168.1.1 in my example), which is
currently master.
If I do a carp demote on bsd1, the route change to bsd2 (192.168.1.1).
So there is no problem like I mentionned last time (ingoing traffic goes
to bsd1 and outgoing traffic by bsd2).
Thank you very much for your help ! It's exactly what I tried to do :)
Mathieu
Re: OpenOSPF + CARP
Le 03/09/2011 12:35, Stuart Henderson a icrit :
On 2011-09-02, Mathieu BLANCmathieu.bl...@smile.fr wrote:
I setup this, *and it seems to work well.*
Routers in network A see 2 routes to Network B : bsd1 and bsd2.
For example :
First route : bsd1
Second route : bsd2
bsd1 is the master carp on network B.
So the ingoing traffic goest to bsd1, and the servers in B use their
gateway - bsd1.
But if i do (manually) a carpdemote on bsd1, the the carp master will
switch to bsd2, but on the ospf side, the route will remain the same on
the routers in A.
So the ingoing traffic goes into bsd1, and the servers now use bsd2 to
go out.
Is it not a problem ? In terms of firewalling for example (keep state ?
will bsd2 authorize the trafic which is initiated by bsd1 ? maybe with
the help of pfsync ??)
pfsync(4) can handle this if you use 'defer', see the pfsync manpage,
but this is normally only desirable for load-balancing.
I read the manpage, and it seems to match exactly with what i want to do :
Where more than one firewall might actively handle packets, e.g. with
certain ospfd(8), bgpd(8) or carp(4) configurations, it is beneficial to
defer transmission of the initial packet of a connection. The pfsync
state insert message is sent immediately; the packet is queued until
either this message is acknowledged by another system, or a timeout has
expired.
In the situation you describe, the network A should send all of
network B's traffic to whichever machine is currently carp master.
For this setup you need to:-
1. have the subnet (not a /32) configured on the carpXX interface
2. use 'interface carpXX { passive }' in ospfd.conf
If this doesn't help, please show ospfd.conf files and 'ifconfig -A'
output.
I'm not sure to understand, sorry.
Here is my test conf (exactly the same than in prod, but with private
network).
If I take my previous example :
Network A [interconnection with others routers] = 192.168.1.0/24
(configured on em0, and carp0)
Network B [network with servers] = 172.16.1.0/24 (configured on em1, and
carp1, used by servers for default gateway)
em2 is for pfsync.
The ospfd.conf is very simple.
bsd1# ifconfig -A
em0: flags=8b43UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST
mtu 1500
lladdr 00:1b:21:b3:c7:18
priority: 0
groups: egress
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 192.168.1.1 netmask 0xff00 broadcast 192.168.1.255
em1: flags=8b43UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST
mtu 1500
lladdr 00:1b:21:b3:c7:19
priority: 0
media: Ethernet autoselect (1000baseT full-duplex)
status: active
inet 172.16.1.1 netmask 0xff00 broadcast 172.16.1.255
em2: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
lladdr 00:1b:21:b3:c7:1c
priority: 0
media: Ethernet autoselect (1000baseT full-duplex,rxpause,txpause)
status: active
inet 172.16.99.1 netmask 0xfffc broadcast 172.16.99.3
pfsync0: flags=41UP,RUNNING mtu 1500
priority: 0
pfsync: syncdev: em2 syncpeer: 172.16.99.2 maxupd: 128 defer: off
groups: carp pfsync
carp0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
lladdr 00:00:5e:00:01:aa
priority: 0
carp: MASTER carpdev em0 vhid 170 advbase 1 advskew 80
groups: carp
status: master
inet 192.168.1.100 netmask 0xff00 broadcast 192.168.1.255
carp1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
lladdr 00:00:5e:00:01:ab
priority: 0
carp: MASTER carpdev em1 vhid 171 advbase 1 advskew 120
groups: carp
status: master
inet 172.16.1.100 netmask 0xff00 broadcast 172.16.1.255
bsd1# cat /etc/ospfd.conf
area 0.0.0.0 {
interface em0
interface em1
interface carp0 { passive }
interface carp1 { passive }
}
bsd2 is exactly the same (with different ip address on em0/em1/em2 and
backup carp).
This setup works quite well (i see 2 routes to 172.16.1.0/24 network in
my others routers : via bsd1 and bsd2). What i wanted to do is to have
just one route to 192.168.1.100. But I don't know if it's possible.
If not, i'll destroy the carp0 interface, and use defer in pfsync.
Thanks by advance :-)
Mathieu.
OpenOSPF + CARP
Hi, (i'm really sorry for my english, i'll do my best ! :) It seems it's a frequent question, but i want to be sure about the setup. I read all this thread, which was very interesting about CARP and OSPF : http://marc.info/?l=openbsd-miscm=125958449232344w=4 I have a similar setup : Two OpenBSD (4.9, let's say bsd1 and bsd2)) connected with : - Network A (interconnection with other routers) - Network B (Network behind the 2 openbsd). My OpenBSD boxes are also acting as firewall for the network B. On Network B side, i've a carp interface : the gateway for the servers on B. Now, i want, with OSPF, to say to other routers in the interconnection (Network A) : Access to Network B is here ! :) If i understood correctly the thread i found on marc.info, it seems that we don't have to setup a CARP on Network A, and let OSPF do the job for failover. I setup this, *and it seems to work well.* Routers in network A see 2 routes to Network B : bsd1 and bsd2. For example : First route : bsd1 Second route : bsd2 bsd1 is the master carp on network B. So the ingoing traffic goest to bsd1, and the servers in B use their gateway - bsd1. But if i do (manually) a carpdemote on bsd1, the the carp master will switch to bsd2, but on the ospf side, the route will remain the same on the routers in A. So the ingoing traffic goes into bsd1, and the servers now use bsd2 to go out. Is it not a problem ? In terms of firewalling for example (keep state ? will bsd2 authorize the trafic which is initiated by bsd1 ? maybe with the help of pfsync ??) Is it possible to have something like this : Carp on Network A, and bsd1/bsd2 announce : next hop for network B is ip_carp_on_networkA ? Thank you by advance, and again, sorry for the poor english i use :) -- Mathieu
Watchdog timeout on Marvell Yukon 88E8053 (driver msk, 4.9-release)
Hello everybody, I updated my openbsd firewalls (two carp-ed fw) last month (May 24th) to 4.9 release. I don't know if this is related, but i have a significant numbers of watchdog timeout errors in logs (the master becomes slave when the error appears). Before the update, i've just seen this error 2 times (May 17th and April 14th). xx-1 is normally the master and xx-2 the slave (dmesg are exactly the same). Watchdog timeout in logs appear when the firewall is master (bw ~ 20Mb/s). xx-1:~# zgrep watchdog /var/log/messages* /var/log/messages.0.gz:Jun 14 13:59:41 xx-1 /bsd: msk2: watchdog timeout /var/log/messages.0.gz:Jun 15 15:05:55 xx-1 /bsd: msk0: watchdog timeout /var/log/messages.0.gz:Jun 15 16:56:32 xx-1 /bsd: msk0: watchdog timeout /var/log/messages.0.gz:Jun 15 17:23:05 xx-1 /bsd: msk1: watchdog timeout /var/log/messages.1.gz:Jun 6 10:32:16 xx-1 /bsd: msk1: watchdog timeout /var/log/messages.1.gz:Jun 6 17:30:55 xx-1 /bsd: msk2: watchdog timeout /var/log/messages.1.gz:Jun 9 10:17:31 xx-1 /bsd: msk0: watchdog timeout /var/log/messages.2.gz:May 30 17:10:45 xx-1 /bsd: msk0: watchdog timeout /var/log/messages.2.gz:May 31 18:02:13 xx-1 /bsd: msk0: watchdog timeout /var/log/messages.4.gz:May 17 16:18:45 xx-1 /bsd: msk0: watchdog timeout /var/log/messages.9.gz:Apr 14 16:00:26 xx-1 /bsd: msk0: watchdog timeout xx-2:~# zgrep watchdog /var/log/messages* /var/log/messages:Jun 20 10:14:20 xx-2 /bsd: msk0: watchdog timeout /var/log/messages:Jun 21 15:48:32 xx-2 /bsd: msk2: watchdog timeout /var/log/messages.0.gz:Jun 17 10:16:12 xx-2 /bsd: msk0: watchdog timeout The 4.9 upgrade and the increase of watchdog timeout logs seem to coincide but there are no pieces of evidence. Does anybody has the same type of network card and the same problem ? I found some old mails (2007) but i don't see if it could help me : http://gnats.netbsd.org/36454 http://kerneltrap.org/mailarchive/openbsd-misc/2007/5/11/149534/thread Some mails/forums are not so old (2010) but concern freebsd : http://www.freebsd.org/cgi/query-pr.cgi?pr=116853 http://forums.freebsd.org/showthread.php?t=10183 Thank you in advance ! Here is the dmesg of one of the firewall (they are strictly the same). OpenBSD 4.9 (GENERIC.MP) #794: Wed Mar 2 07:19:02 MST 2011 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP cpu0: Intel(R) Pentium(R) 4 CPU 3.40GHz (GenuineIntel 686-class) 3.41 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,EST,TM2,CNXT-ID,CX16,xTPR,PDCM real mem = 2145939456 (2046MB) avail mem = 2100670464 (2003MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 08/29/05, BIOS32 rev. 0 @ 0xf9680, SMBIOS rev. 2.2 @ 0xf0800 (39 entries) bios0: vendor Phoenix Technologies, LTD version 6.00 PG date 08/29/2005 acpi0 at bios0: rev 0 acpi0: sleep states S0 S1 acpi0: tables DSDT FACP MCFG APIC acpi0: wakeup devices PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) HUB0(S5) UAR1(S5) UAR2(S5) USB0(S1) USB1(S1) USB2(S1) USBE(S1) AC97(S5) AZAL(S5) PCI0(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimcfg0 at acpi0 addr 0xe000, bus 0-0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: apic clock running at 200MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Pentium(R) 4 CPU 3.40GHz (GenuineIntel 686-class) 3.41 GHz cpu1: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,EST,TM2,CNXT-ID,CX16,xTPR,PDCM ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 2 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (PEX0) acpiprt2 at acpi0: bus 2 (PEX1) acpiprt3 at acpi0: bus 3 (PEX2) acpiprt4 at acpi0: bus 4 (PEX3) acpiprt5 at acpi0: bus 5 (HUB0) acpicpu0 at acpi0 acpicpu1 at acpi0 acpitz0 at acpi0: critical temperature 75 degC acpibtn0 at acpi0: PWRB bios0: ROM list: 0xc/0xa800! 0xcc000/0x8000! 0xef000/0x1000! cpu0: Enhanced SpeedStep disabled by BIOS pci0 at mainbus0 bus 0: configuration mode 1 (bios) pchb0 at pci0 dev 0 function 0 Intel 82915G Host rev 0x0e vga1 at pci0 dev 2 function 0 Intel 82915G Video rev 0x0e wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) intagp0 at vga1 agp0 at intagp0: aperture at 0xc000, size 0x1000 inteldrm0 at vga1: apic 2 int 16 (irq 5) drm0 at inteldrm0 ppb0 at pci0 dev 28 function 0 Intel 82801FB PCIE rev 0x04: apic 2 int 16 (irq 5) pci1 at ppb0 bus 1 mskc0 at pci1 dev 0 function 0 Marvell Yukon 88E8053 rev 0x15, Yukon-2 EC rev. A3 (0x2): apic 2 int 16 (irq 5) msk0 at mskc0 port A: address 00:10:f3:13:c6:98 eephy0 at msk0 phy 0: 88E Gigabit PHY, rev. 2 ppb1 at pci0 dev 28 function 1 Intel 82801FB PCIE rev 0x04: apic 2 int 17 (irq 10) pci2 at ppb1 bus 2 mskc1 at pci2 dev 0 function 0 Marvell
