OpenBSD 6.2 - 6.4 crash on ASRock Q1900 ITX boards
Hi,
I have a couple of Q1900DC-ITX boards:
http://www.asrock.com/MB/Intel/Q1900DC-ITX/index.de.asp I also have a couple of
Q1900M versions of the same board.
On the ITX version OpenBSD (tested from 6.2 - 6.4) crashes upon reboot, but not
upon a cold boot, with the following:
NMI ... going to debugger
Stopped atacpicpu_idle+0x22d: nop
ddb{0}>
Is there anything I can do to help possibly solve this problem?
I also get these "annoying" ehci_sync_hc: tsleep() = 35 messages, as seen in
dmesg, on all boards during boot, which makes the boot process halt for 35
seconds. What is causing this?
Thanks in advance.
Kindest regards
dmesg:
OpenBSD 6.4 (GENERIC.MP) #364: Thu Oct 11 13:30:23 MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 1818173440 (1733MB)
avail mem = 1753853952 (1672MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xebd40 (19 entries)
bios0: vendor American Megatrends Inc. version "P1.70" date 03/01/2018
bios0: ASRock Q1900DC-ITX
acpi0 at bios0: rev 2
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP APIC FPDT MCFG LPIT AAFT SSDT SSDT SSDT UEFI
acpi0: wakeup devices XHC1(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PWRB(S0)
BRCM(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) Celeron(R) CPU J1900 @ 1.99GHz, 2000.45 MHz, 06-37-08
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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu0: 1MB 64b/line 16-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 83MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz, 1999.99 MHz, 06-37-08
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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu1: 1MB 64b/line 16-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz, 1999.99 MHz, 06-37-08
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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu2: 1MB 64b/line 16-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 6 (application processor)
cpu3: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz, 1999.99 MHz, 06-37-08
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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,SMEP,ERMS,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN
cpu3: 1MB 64b/line 16-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 87 pins
acpimadt0: bogus nmi for apid 0
acpimadt0: bogus nmi for apid 2
acpimadt0: bogus nmi for apid 4
acpimadt0: bogus nmi for apid 6
acpimcfg0 at acpi0
acpimcfg0: addr 0xe000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (RP01)
acpiprt2 at acpi0: bus 2 (RP02)
acpiprt3 at acpi0: bus 3 (RP03)
acpiprt4 at acpi0: bus 4 (RP04)
acpiec0 at acpi0: not present
acpicpu0 at acpi0: C3(10@1500 mwait.1@0x52), C2(10@500 mwait.1@0x51), C1(1000@1
mwait.1), PSS
acpicpu1 at acpi0: C3(10@1500 mwait.1@0x52), C2(10@500 mwait.1@0x51), C1(1000@1
mwait.1), PSS
acpicpu2 at acpi0: C3(10@1500 mwait.1@0x52), C2(10@500 mwait.1@0x51), C1(1000@1
mwait.1), PSS
acpicpu3 at acpi0: C3(10@1500 mwait.1@0x52), C2(10@500 mwait.1@0x51), C1(1000@1
mwait.1), PSS
acpipwrres0 at acpi0: PLPE
acpipwrres1 at acpi0: PLPE
acpipwrres2 at acpi0: USBC, resource for EHC1, OTG1
acpipwrres3 at acpi0: CLK0, resource for CAM1
acpipwrres4 at acpi0: CLK1, resource for CAM0, CAM2
acpipwrres5 at acpi0: FN00, resource for FAN0
acpitz0 at acpi0: critical temperature is 90 degC
"INT3396" at acpi0 not configured
acpicmos0 at acpi0
"DMA0F28" at acpi0 not configured
acpibtn0 at acpi0: PWRB
acpibtn1 at acpi0: SLPB
"BCM2E1A" at acpi0 not configured
"BCM4752" at acpi0 not configured
"INTCF0B" at acpi0 not configured
"INTCF1A" at acpi0 not configured
"INTCF1C" at acpi0 not configured
"SMO91D0" at acpi0 not configured
Re: Problems with a quad Realtek NIC
> It is preferable to just include the whole dmesg directly in the mail > Better still, when it's a "sometimes works" problem, include a "diff -u" > between the two (the context to show where the lines are added/removed). I have pasted a "diff -u" on https://paste.debian.net/1047098/ > Very unlikely to be a problem with the NIC driver. From what I've > seen (and having seen other examples of the quality of Jetway's BIOSes) > my money would be on a BIOS bug. I originally suspected it to be a BIOS bug (and please excuse me if I make a wrong assumption here), but I have run a ton of tests booting the same hardware up on Arch Linux, but I haven't seen the problem once. I don't know if could still be a BIOS bug, but I would suspect that if it where that I would see similar problems with the card not showing up. > Can you identify any particular situations where it works or fails? For > example "works after a cold boot but not warm" or something? I have been looking for patterns in the different tests I have run, but haven't found anything. Sometimes it works during a cold boot, other times it doesn't, and the same goes for warm boots. I have also tried disabling and enabling the onboard NIC to see if it might affect the problem, but it doesn't. Just for information, I have another identical box (same motherboard), but with a 4-port Intel NIC (same cheap card-thing from China, but with Intel) that runs flawless, but not only that, it performs super well even with several NIC ports going full speed. It has been running for a couple of years as a firewall/gateway, managing multiple networks (each separated by the 4-port NIC). I have made these as cheap alternatives to the very expensive Soekris. By mistake I got two of the 4-port Realtek cards, but since I got them, I wanted to see if they could run as well. Kindest regards. PS.: Sorry for the crappy Yandex mail client problem.
Problems with a quad Realtek NIC
Hi,� I have one of these 4-port Realtek NIC cards: https://www.ebay.co.uk/itm/PCIe-PCI-Express-to-4x-Gigabit-Card-4-Port-Ethernet-Network-Adapter-10-100-1000M/252484240577?epid=505371101� I am running OpenBSD 6.3 stable.� During boot the card is seen, but it only works occasionally. When it works I can see all the 4 ports using "ifconfig" and I can assign IP addresses etc. When it doesn't work nothing is shown using "ifconfig".� As far as I understand from the "re" manpage RTL8168E/8111E is supported.� This is my dmesg:� http://paste.debian.net/1046756/� When the card isn't working I also get this:� +ppb1 at pci1 dev 0 function 0 vendor "ASMedia", unknown product 0x1184 rev 0x00 +pci2 at ppb1 bus 2 +ppb2 at pci2 dev 1 function 0 vendor "ASMedia", unknown product 0x1184 rev 0x00: not configured by system firmware +ppb3 at pci2 dev 3 function 0 vendor "ASMedia", unknown product 0x1184 rev 0x00: not configured by system firmware +ppb4 at pci2 dev 5 function 0 vendor "ASMedia", unknown product 0x1184 rev 0x00: not configured by system firmware +ppb5 at pci2 dev 7 function 0 vendor "ASMedia", unknown product 0x1184 rev 0x00: not configured by system firmware � Is this a driver issue or something else perhaps?� Kindest regards
PF redirect traffic to TUN/VPN
Hi,� I have an OpenBSD box setup as a firewall and gateway with DHCP.� I was thinking about adding VPN to the box.� Is it possible to install OpenVPN, establish a tunnel via a third partyVPN provider (like PIA), and then have PF redirect some traffic throughthat tunnel based upon IP addresses, but not all traffic?� So traffic coming from 192.168.1.2 goes through the VPN tunnelinterface on the OpenBSD gateway, but traffic from 192.168.1.3 does not?� I am asking because normally all traffic is forced through the VPNtunnel.� Maybe this isn't related to PF at all?� Kind regards� Martin
Sharing files between OpenBSD, Linux, and Windows boxes
How do you share files between OpenBSD, Linux, and Windows boxes? Currently I have a setup in which I mount Samba shares that are being served from Linux boxes and mounted on Linux boxes using cifs and on Windows boxes. This works very well and it's both easy to administer and it's very fast. I would like to use OpenBSD for more that just firewalling and I would like to replace several Linux desktops with OpenBSD. However, every time I try to set this up I run into some kind of trouble. NFS isn't a solution as file permissions is a mess between several different OS'es with different accounts. Samba works really great between Linux and Windows, but mounting Samba shares on OpenBSD? I remember sharity-light, but it isn't in the ports any longer and isn't maintained. How do you manage file sharing between these systems (if it all)? Also, is it possible to decrypt and mount a Linux harddrive that has been encrypted with LUKS? Many thanks in advance! Kind regards
Syn flood crashed my LAN
Hi, I have a home network that is segmented into 3 different zones using a NIC with 4 ports sitting on an OpenBSD firewall/dhcp server. One port is connected to the Internet (ISP router) and each of the three others has a D-Link DGS-1005D switch connected to each. So.. LAN1 = 192.168.1.0 LAN2 = 192.168.2.0 LAN3 = 192.168.3.0 Learning more about networking I wanted to test a SYN flood so I set up a couple of boxes on LAN1 and LAN3 to flood a box on LAN2. I used "hping3" with the "S" and "flood" options. Running a regular ping in a terminal I could see how the response time decreased and eventually the box began to loose packages. However after a while it seemed like the entire internal network went down. No box on any LAN could get an IP address from the DHCP server on the OpenBSD box. I eventually rebooted the OpenBSD box, but that didn't immediately help, and only after powering down the switches and powering the switches on again, everything worked again. I have been looking through the PF documentation to see if PF somehow blocks SYN flooding, but I am not using synproxy on any rules. What could cause such a "melt down" of the entire network because of a SYN flood to a box? I suspect that the D-Link switches are pretty bad and maybe are the cause of the problem? I eventually will try again to see if I can determine what's causing the "melt down", but I want to know if anyone perhaps has experienced similar results during some testing? Many thanks in advance. Kind regards, Martin
Re: Syn flood crashed my LAN
Why would I need a container like Docker?!
I have occasionally used virtualization (Qemu) for easy testing of some OS. I have also played around with "containers" using FreeBSD Jails and Linux LXC, but I have never ever thought of any of this as a security measurement or anything needed beyond testing. When I want isolation I run a single box (or boxes) and install OpenBSD on the bare metal. Then I run whatever services are needed on that box or boxes. I would then deploy a network with isolated segments. Now, everyone is telling me I should run Docker and a completely different setup. I read up about Docker and found this: "Containers are a solution to the problem of how to get software to run reliably when moved from one computing environment to another. This could be from a developer's laptop to a test environment, from a staging environment into production and perhaps from a physical machine in a data center to a virtual machine in a private or public cloud." "Problems arise when the supporting software environment is not identical, says Solomon Hykes, the creator of Docker, "You're going to test using Python 2.7, and then it's going to run on Python 3 in production and something weird will happen. Or you'll rely on the behavior of a certain version of an SSL library and another one will be installed. You'll run your tests on Debian and production is on Red Hat and all sorts of weird things happen." "And it's not just different software that can make a difference, he added, "The network topology might be different, or the security policies and storage might be different but the software has to run on it." What the fuck?! Why in the world would anyone setup Debian as a testing environment and then use Red Hat on production?! And different network topology? Are people really that stupid? If people really are that stupid they shouldn't be allowed near a computer in the first place and certainly Docker or any container technology isn't going to solve their problems! It seems like the OpenBSD project is about the only project left nowadays where people are still using their brains!
dnsmasq not working on OpenBSD 6.1
Hi I have successfully setup unbound on OpenBSD 6.1 and I can query it. In the same setup I have tested dnsmasq, but it almost seems broken on OpenBSD 6.1. I have disabled unbound and confirmed nothing is running on port 53 using netstat. Then I have installed dnsmasq from packages and set the dnsmasq.conf file as follows: listen-address=127.0.0.1 address=/foobar/10.0.0.1 server=8.8.8.8 This is just a dummy setup for testing. In /etc/resolv.conf I have (as with unbound): nameserver 127.0.0.1 I have then started dnsmasq with: /etc/rc.d/dnsmasq start And I have confirmed it's running on port 53 using netstat. No matter what I do dnsmasq doesn't respond to the query. # dig foobar ; <<>> DiG 9.4.2-P2 <<>> foobar ;; global options: printcmd ;; connection timed out; no servers could be reached What am I missing? Is dnsmasq broken on OpenBSD 6.1? Kind regards
Re: Non-free firmware without asking the user
On Sun, 8 Jan 2017, Stefan Sperling wrote: >> The above policy applies to the base system code. >> It does not apply to ports and packages of third party software, i.e. >> anything >> listed by pkg_info. > Perhaps the whole only a misunderstanding of the original poster that > could have been clarified with this few lines from the beginning? > > Rodrigo. Good point, and yes it would. However, the above statement that the policy only applies to the base code isn't mentioned anywhere in the policy. Stefan, from where do you get that conclusion?
Re: Non-free firmware without asking the user
08.01.2017, 02:53, "Peter Rippe" : > I think it absolutely is a language issue: > >> On policy page it clearly says: "OpenBSD strives to provide code that can > > be freely used, copied, modified, and distributed by anyone and for any > purpose." > > Operative word being **strives** - might want to look it up. > > It does not say 'guaranteed', 'only', nor 'strictly' - It says they make a > good > effort to provide such, and they certainly do - particularly compared to the > rest of the OS landscape. Alright, so lets look the word **strives** up: Cambridge dictionary: "to try hard to do something or make something happen, esp. for a long time or against difficulties" Macmillan dictionary: "to make a lot of effort to achieve something" Oxford dictionary: "Make great efforts to achieve or obtain something" Clearly it's NOT a language thing. OpenBSD does NOT **strive** "to provide code that can be freely used, copied, modified..". There is no striving being done here, except for the complete opposite, as Theo himself so plainly put it, they actually **strive** to provide the firmware blobs which cannot be modified in any way. The fact is that OpenBSD has a MISLEADING policy. > Nothing is going to change. Go try tugging on emotions elsewhere. Actually, Theo I'm quite sure you need to change *something*: http://www.competitionbureau.gc.ca/eic/site/cb-bc.nsf/eng/02776.html But hey.. who gives a shit right?!
Re: Non-free firmware without asking the user
08.01.2017, 01:29, "Mike Burns" : > On 2017-01-08 00.02.21 +0100, Martin Hanson wrote: >> The issue is a misguiding policy statement. > > It could be a language issue. I'm a native speaker and everything Theo, > et al., are saying matches perfectly with the policy statement, to me. > Perhaps you can suggest improved wording. Patches go to tech@. I don't believe it's a language issue. What Theo has explained acts as a "clarification" of the policy, which is fine in itself, but it needs to be added. The policy statement alone, as is, is misguiding and I even believe that it's a problem from a legal stand point, but that's beside the matter. Theo himself can correct his faulty policy.
Re: Non-free firmware without asking the user
ludovic coues said: > You are free to use OpenBSD code. > You are free to copy OpenBSD code. > You are free to modify OpenBSD code. > You are free to distribute you fork. > > So unless your dictionary is twisted, shipping non-free firmware isn't > an exception to these freedom. You're wrong. That's not what it says on the OpenBSD website. Please read on. Stefan Sperling said: > I agree with Theo. Don't buy hardware you don't like. Avoiding the hardware isn't the issue! The issue is MISGUIDANCE by OpenBSD! On the frontpage of openbsd.org it says "free" with big bold letters: "The OpenBSD project produces a FREE, multi-platform 4.4BSD-based UNIX-like operating system." And there is a link to the explanation of the "free" term used by OpenBSD: https://www.openbsd.org/policy.html The explanation is not as given by "ludovic coues" in the above. On policy page it clearly says: "OpenBSD strives to provide code that can be freely used, copied, modified, and distributed by anyone and for any purpose." This is MISGUIDING! OpenBSD ALSO provides software that cannot freely be modified in any way and it DOES THIS WITHOUT EVEN ASKING THE USER! Stop avoiding the issue by pointing to problems with "crappy" hardware and vendors. This is not the issue. The issue is a misguiding policy statement.
Re: Non-free firmware without asking the user
06.01.2017, 23:26, "Theo de Raadt" : > If you don't want such firmwares loaded onto the hardware, then don't > buy the hardware that needs it. > > There is your choice. > > I see no value in asking a user the question. I have misunderstood the purpose and use of the term "free" of OpenBSD then. "OpenBSD strives to provide code that can be freely used, copied, modified, and distributed by anyone and for any purpose", apparently there exists exceptions to this then. Of course it doesn't say anything like, "OpenBSD strives to ONLY provide.." Sorry, my mistake! > END OF CONVERSATION. > >> I know that we cannot trust the hardware vendors and that all the hardware >> is running firmware on ROMS, except some which are provided be the kernel. >> >> However, I fail to understand the reason for this patch: >> >> >> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib/miniroot/install.sub?f=h#rev1.654 >> >> It was really nice when OpenBSD asked during installation. >> >> Yes, it can be argued that since we cannot get any open hardware at all it >> doesn't matter whether the firmware is located on a ROM or if it's installed >> by the kernel, but if we use that logic we might as well just use whatever >> binary driver blob the vendors make for everything, right? >> >> If no, then why not, what's the difference between running closed source >> firmware and closed source drivers? >> >> During a Debian installation, or even a Linux Mint installation, the user >> gets the choice whether he wants to install these "non-free firmware blobs". >> >> What have I misunderstood? >> >> Kind regards, >> >> Martin
Non-free firmware without asking the user
Hi, I know that we cannot trust the hardware vendors and that all the hardware is running firmware on ROMS, except some which are provided be the kernel. However, I fail to understand the reason for this patch: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/distrib/miniroot/install.sub?f=h#rev1.654 It was really nice when OpenBSD asked during installation. Yes, it can be argued that since we cannot get any open hardware at all it doesn't matter whether the firmware is located on a ROM or if it's installed by the kernel, but if we use that logic we might as well just use whatever binary driver blob the vendors make for everything, right? If no, then why not, what's the difference between running closed source firmware and closed source drivers? During a Debian installation, or even a Linux Mint installation, the user gets the choice whether he wants to install these "non-free firmware blobs". What have I misunderstood? Kind regards, Martin
Re: Unbound and dnscrypt-proxy not playing nice
09.09.2016, 06:14, "Lists" : > Does unbound.conf have the following setting? > > do-not-query-localhost: no Yes, it has the setting.
Unbound and dnscrypt-proxy not playing nice
Hi, Since I upgraded to OBSD 6.0 I have had some problems with Unbound and dnscrypt-proxy. Normally I would troubleshoot by using "dig" to request directly to dnscrypt-proxy, but for some reason (I don't know) the "-p" option has been removed and it is impossible to use that now. Unbound seems unable to forward requests to dnscrypt-proxy which I have running on port 40 following the guide in the FAQ (http://www.openbsd.org/faq/pf/example1.html#dns). In my unbound.conf I have the following: forward-addr: 127.0.0.1@40 Then in my /etc/rc.conf.local I have: dnscrypt_proxy_flags=-l /var/log/dnscrypt-proxy -R fvz-rec-de-fra-01 -a 127.0.0.1:40 pkg_scripts="dnscrypt_proxy" When I do a "dig yahoo.com" I get the following: ;yahoo.com. IN A No IP. And a ping also returns: ping: unknown host: yahoo.com Of course I have tested other hosts as well, same result. I am getting no information in the logs. If I have unbound forward directly to an OpenNIC server all works well again so the trouble is between unbound and dnscrypt-proxy. This used to work flawlessly, but since the "-p" option has been removed from "dig" it's very difficult to debug dnscrypt-proxy without having PF doing redirects and what not. How to troubleshoot this problem better? Kind regards
Any experience running OpenBSD 5.6 or current on a Shuttle DS437?
Hi, If so, how well does the driver for the two NICs work? How does the box perform in general? Thanks!
Re: OpenBSD 5.6/current on Soekris 6501-70
I would like to be able to run ~100-120 MB/s from one NIC to the other on this box, if possible?
OpenBSD 5.6/current on Soekris 6501-70
Hi, Anyone running OpenBSD 5.6 or current on Soekris 6501-70 who wouldn't mind sharing some through-put data for gigabit performance. Regards, MH
Re: Confused about authpf real world usage
> theoretically this is possible, but only if the original machine holding > the ip was down. just as a nameserver converts to an ip, the ip is converted > to a MAC-address, which is associated with the NIC. if you want you can > permantly associate an ip with a mac, that way another machine cannot use > that ip address, even if the rightful holder is down. see arp(8). But wouldn't that be very easy to break? First I would scan the network for MACs and matching IPs, then I would spoof one at a time until I am out. How does one secure against MAC/IP spoofing? Is there a way to prevent this.
Re: Confused about authpf real world usage
> Here is a case where you trust the machines, but do not trust Joe. > > Commonly, trusted servers are deployed on network segments that are > separate from untrusted users - via Ethernet segments or VLANs. It > is also possible to use VPNs to provide functional separation of > servers from users, if separate Ethernet tiers is not possible. Sure, but in this case some users still needs access to these servers. But I was thinking about have those servers logging into the gateway/authpf via some boot script and then keeping that connection open. >> And what about other kinds of access? Now I get a brand new box in >> that needs a fresh installation of some Linux distribution that we >> install over HTTP. This new box doesn't come with a SSH console and >> the install disk doesn't provide a console with SSH during >> installation. > The provisioning if performed on the untrusted network, would require > the distribution server to be accessible. Simple enough with a pass > rule to your organization's deployment server. We don't run with a deployment server, but maybe this is one use case in which all the different OS'es we use could be deployed over network boot. However, we do a lot of testing on many different distributions etc., but maybe in this particular case a isolated segment can be created. Kind regards.
Confused about authpf real world usage
Hi So I am looking into authpf and I am wondering about some real world applications. I have a bunch of users, but I also have just a bunch of machines. The machines cannot login via SSH and should not try to do so (via some script or otherwise). However, these machines needs access 24/7. So I was thinking about fixing rules to those machines before any anchors for users, but I cannot see how this provides any security at all - and bear with me if I am overlooking something. If say machine 192.168.0.2 and 192.168.0.3 needs unrestricted access to the net, then wont it be as easy as "Joe" changing his machines IP address to 192.168.0.2 to gain access without authentication? And what about other kinds of access? Now I get a brand new box in that needs a fresh installation of some Linux distribution that we install over HTTP. This new box doesn't come with a SSH console and the install disk doesn't provide a console with SSH during installation. Then I am beginning to see signs of "network segmentation" in my head, but that kindda makes authpf more or less useless then - unless I need to grant different people different access on the same segment I can just segment the entire net. Anyway, I hope I make sense! :) How do you use authpf in real life? Kind regards.
Multiple NICs vs multiple physical firewalls
Hi all I have one gateway and several boxes serving some NFS, Samba and other stuff. Then I have a public server for some gaming. I am thinking about two different setups, but I am in serious doubt as to whether one actually has any real benefit over the other. The public server gets its own NIC on the firewall, whereas the other boxes share another NIC (through a switch) for local stuff. My worries is if the public server gets hacked. Is it better to physically segment the network using two different boxes as routers/firewalls, or is it better to simply use one router/firewall with 3 NICs? Setup 1: Gateway --> firewall --> NIC1 --> public server | --> NIC2 --> LAN Setup 2: Gateway --> firewall1 --> public server | --> firewall2 --> LAN I am wondering about which of the two situations are "most secure". Maybe it really depends on how the firewall is setup, but what I want to avoid is that if the public server gets hacked, that the attacker can gain access to stuff on the LAN. Any comments on these different setups? Of course the ideal would properly be to get two separate Internet connections, but that's really not an option in this case. Kind regards.
