It provided an example of a static nat forwarding for incoming traffic.
Another common task is blocking certain outgoing traffic
block return out quick on egress from any to any port smtp
to block all outgoing email if your internal machines are all windows (to block spambots or whatever).
Or to block outgoing traffic from one device (perhaps your laser printer, or abandoned smart TV, or an "internet of powned things" device).
block return out quick on egress from 10.1.2.3
You can have huge fun with tables. So make a table of addresses to block from the internet (much like the martians table in the example), and a pile of crontab that pfctl add and pfctl delete the kids i-devices around bed time or homework time or whatever.
As a starter, its pretty good, but there should be commentary on troubleshooting tools. Here's the care and feeding of the log command to figure out what you're actually doing vs what you think you're doing. Here's how you see the current NAT table using pfctl, stuff like that. As with many security issues, its easier to enable uPNP than it is to correctly debate if you should enable uPNP, its easier to enable your whole lan to access the internet rather than blocking the laserprinter, so that's a fun topic in general.
Also it's been a tradition in linux and presumably bsd software firewalls since the mid 90s to add endless complication and logging that serves no useful purpose and is never examined or acted upon after installation until a hardware limit for hardware of that year is reached, then complain software firewalls are too slow and maybe a couple years of hardware advances will make them practical, repeat endlessly. You can shove a couple megs/sec using a 486, I certainly did in the 90s, although you can also clutter up a top of the line desktop today such that the CPU and disk IO will flood about a couple hundred K if you try hard enough by writing every packet to disk and having pages of firewall rules.
If you want hardware to run this on, I really like the PCEngines APU (http://www.pcengines.ch/apu1d4.htm), which is surprisingly powerful (dual AMD64 cores, 4GB RAM, multiple miniPCIe ports), and inexpensive given the capabilities.
Improvements over the first version: quad core, Intel Gigabit NICS, new CPU supports AES-NI and AVX (AMD-V), ECC memory, and a USB 3.0 bus. Still some issues being ironed out, but will make excellent router hardware. Note that WiFi is a relative weakness on BSD, and you'll need to carefully choose a chipset to support hostap mode. The Atheros abgn cards are generally the best.
I used to agree with you, while still running an openbsd router for home use, but the last upgrade went quite smoothly so I would say they've put a lot of work into that aspect.
Yes there were manual steps to perform but they worked so well and were so simple that I couldn't help but think about automating them in a simple script. And finishing up I just did a pkg_add -u to upgrade all packages.
The only thing missing from the example imo is dnsmasq, much easier and lighter to use.
What do you run now? I currently use FreeBSD because it has binary update/upgrade support, currently seems to have better smp than OpenBSD, and the network stack is fast. Also looking forward to some of the network performance improvements[1] coming in 11.
I have been hearing good things about DragonflyBSD lately though too.
Well, it's not obsolete - more incomplete. OpenBSD has supported ipv6 natively for a long, long time.
Additionally, with a "home/office" router, there's many ways that IPv6 may be implemented by their ISP (e.g. static configured prefix, DHCPv6, prefix delegation etc...) all which require specific configuration on the WAN and LAN side to make it work.
So, I agree, but splitting that particular part into a different FAQ/walkthrough is going to be a better approach.
It's too bad that DJB's full dnscurve (http://dnscurve.org) suite didn't take off like dnscrypt did, but that does require changing the DNS server names at the registrar to include the key in the domain name, and having support throughout the resolver chain.
That said, I've been running dnscurve for a few years on my authoritative internet-facing servers ( `dig ns artcs.net` to see what it looks like), and I generally see between 5-10% of requests coming in as wanting encryption. Most of these are requests from OpenDNS, which supports the protocol.
It's gaining more and more traction, and is a far stronger protection mechanism from actual threats than DNSSEC. </biased as the guy who sponsored DNSCrypt creation>
[+] [-] jrcii|10 years ago|reply
[+] [-] mulander|10 years ago|reply
[+] [-] VLM|10 years ago|reply
It provided an example of a static nat forwarding for incoming traffic.
Another common task is blocking certain outgoing traffic
block return out quick on egress from any to any port smtp
to block all outgoing email if your internal machines are all windows (to block spambots or whatever).
Or to block outgoing traffic from one device (perhaps your laser printer, or abandoned smart TV, or an "internet of powned things" device).
block return out quick on egress from 10.1.2.3
You can have huge fun with tables. So make a table of addresses to block from the internet (much like the martians table in the example), and a pile of crontab that pfctl add and pfctl delete the kids i-devices around bed time or homework time or whatever.
As a starter, its pretty good, but there should be commentary on troubleshooting tools. Here's the care and feeding of the log command to figure out what you're actually doing vs what you think you're doing. Here's how you see the current NAT table using pfctl, stuff like that. As with many security issues, its easier to enable uPNP than it is to correctly debate if you should enable uPNP, its easier to enable your whole lan to access the internet rather than blocking the laserprinter, so that's a fun topic in general.
Also it's been a tradition in linux and presumably bsd software firewalls since the mid 90s to add endless complication and logging that serves no useful purpose and is never examined or acted upon after installation until a hardware limit for hardware of that year is reached, then complain software firewalls are too slow and maybe a couple years of hardware advances will make them practical, repeat endlessly. You can shove a couple megs/sec using a 486, I certainly did in the 90s, although you can also clutter up a top of the line desktop today such that the CPU and disk IO will flood about a couple hundred K if you try hard enough by writing every packet to disk and having pages of firewall rules.
[+] [-] geggam|10 years ago|reply
It makes pftop so pretty :)
[+] [-] zdw|10 years ago|reply
[+] [-] scw|10 years ago|reply
Improvements over the first version: quad core, Intel Gigabit NICS, new CPU supports AES-NI and AVX (AMD-V), ECC memory, and a USB 3.0 bus. Still some issues being ironed out, but will make excellent router hardware. Note that WiFi is a relative weakness on BSD, and you'll need to carefully choose a chipset to support hostap mode. The Atheros abgn cards are generally the best.
[+] [-] Hydraulix989|10 years ago|reply
I'm also looking for a good wireless access point. Any suggestions?
[+] [-] ris|10 years ago|reply
(That said, I'm still quite fond of openbsd, but from afar)
[+] [-] INTPenis|10 years ago|reply
Yes there were manual steps to perform but they worked so well and were so simple that I couldn't help but think about automating them in a simple script. And finishing up I just did a pkg_add -u to upgrade all packages.
The only thing missing from the example imo is dnsmasq, much easier and lighter to use.
[+] [-] geggam|10 years ago|reply
https://stable.mtier.org/
[+] [-] stock_toaster|10 years ago|reply
I have been hearing good things about DragonflyBSD lately though too.
[1]: https://github.com/ocochard/netbenches/tree/master/Atom_C255...
[+] [-] Decade|10 years ago|reply
[+] [-] chrismsnz|10 years ago|reply
Additionally, with a "home/office" router, there's many ways that IPv6 may be implemented by their ISP (e.g. static configured prefix, DHCPv6, prefix delegation etc...) all which require specific configuration on the WAN and LAN side to make it work.
So, I agree, but splitting that particular part into a different FAQ/walkthrough is going to be a better approach.
[+] [-] nickpsecurity|10 years ago|reply
[+] [-] pyvpx|10 years ago|reply
[+] [-] zdw|10 years ago|reply
That said, I've been running dnscurve for a few years on my authoritative internet-facing servers ( `dig ns artcs.net` to see what it looks like), and I generally see between 5-10% of requests coming in as wanting encryption. Most of these are requests from OpenDNS, which supports the protocol.
[+] [-] davidu|10 years ago|reply
[+] [-] ksec|10 years ago|reply
[+] [-] jlgaddis|10 years ago|reply