FireWall

tinywall
c:\windows\explorer.exe  block

leaf
I started using Linux in late 1998. I started using LEAF (as LRP) in about May 2000. I tracked down the original article I read, that was the inspiration for my project: "Linux Firewall On A 486: A Guard-Penguin For Your DSL Or Cable Modem Connection" By Eric House & Henry Kingman
 * https://bering-uclibc.zetam.org/wiki/Main_Page
 * http://leaf.sourceforge.net/
 * http://lea-linux.org/documentations/Accueil in french, use chrome browser inbuilt translation.
 * https://bering-uclibc.zetam.org/wiki/Bering-uClibc_6.x_-_User_Guide_-_Advanced_Topics_-_Setting_Up_a_Home_Automation_controller_with_heyu Taken from http://www.heyu.org introduction: "Heyu is a text-based console program for remotely controlling lights and appliances in the home or office.
 * http://leaf.sourceforge.net/doc/buci-network.html

http://web.archive.org/web/20000510042003/http://www.zdnet.com/zdhelp/stories/main/0,5594,2503199,00.html I recall building a Pentium I system with 12 or 24 MB of mem, one floppy drive, and two excellent identical DEC Tulip 10/100 NICs. (This is all used hardware with "new" dates ranging from 1995-1998.) No keyboard or monitor except temporarily for setup. No hard drive or other writable storage device. The hardware mostly came from Goodwill; we had a Goodwill computer outlet in our town at that time. The system has been up continuously for 11 years, except for rare power outages and upgrades. Software has been upgraded a few times, recently from LEAF Bering-uClibc 2.3.1 (2005) to 4.1.1 (2011). The inspiration for this latest software upgrade was the failure of the CD-ROM drive, and the troubleshooting I had to do to fix it. I realized my LEAF install was two major versions out of date. The hardware in my LEAF Firewall has all been upgraded: The chassis from AT to ATX, MB from Pentium I to Pentium II/III MB with a P2 333 CPU, mem to 384 MB (max for MB). Then dual floppies, then CD-ROM + floppy. Two identical Realtek Gigabit NICs are in use now. The interesting hardware upgrade was when my original P2 333 fan started buzzing, I went looking for a replacement fan for this slotted CPU. At the time, the cheapest, most expensive, and only, fan, at $10, came with a PIII 500 CPU attached to it. Nice and quiet, that P3 500 has been running at 450 MHz (max for MB) for many years, since the early 2000s. I thought I would be managing logs for this system forever, but the reality is I hardly ever look at the logs, I know the thing is doing its job, firewalling my broadband Internet connection. It just works. It has saved me great stress over the years by virtue of what I *haven't* had to do to stay secure on the Internet. Thank you, LEAF Project.

projects
https://fossies.org/diffs/ipfire/2.x-2.19-core103_vs_2.x-2.19-core104/lfs/htop-diff.html
 * http://www.ipfire.org/

Firewalling
Firewalling issue QUES: >I need to be able to plug-in a MeshAP (it will be the uplink node or  >gateway for the mesh) into an available CAT5 port on a switch or   >router that will be either static IP or hand out DHCP IP address >(needs to work for both methods) of a private business network to  >get its Internet access. BUT, this is the tricky part, the wireless >users using this MeshAP gateway must NOT be able to see or access >the private business network. See below- ANSw: Simple built in solution available: Total block on incoming wired: This locks down a wired LAN that is connected via the mesh, to  make a high security firewalled connection. http://live.locustworld.com/tracker/wiki?p=FireWalling Wireless connections can only connect to the gateway and out - they can't connect to devices on the LAN.

> there is a wiana setting radio button (yes or no option) for "same > node clients firewalled" - see the "firewalling" section, last entry > above "dialup settings" This is a bit too broad - I only want to remove the firewall for a single wireless client. IIRC, this setting is processed by iptables.. Qorvus have some info on the details on their website. I wonder if adding the client to the NoCat_Inbound chain will be enough?

SAME NODE CLIENTS FIREWALL
If you turn the SAME NODE CLIENTS FIREWALL NO this should open up the firewall and allow the printer to be seen. This also opens up your network so is not recommended. I have a mesh AP connected to a router at home. My desktop computers are networked via workgroup and I share a printer among them. How can I access my shared printer on the workgroup side of the LAN via my wirelless connected laptop that is going through the mesh ap. > laptop <--(wireless connection) ap<--router<--(cat5 > cable)<---desktop--shared printer. > > Can I get the ultra simplified version??

StormWarning
> 192.168.1.100 is connected wirelessly to the gateway radio.

> 192.168.2.100 is connected through a router and feeds the local mesh.

> meshbox kernel: STORMWARNING: IN=eth0 OUT= > MAC=00:40:63:d4:b6:a7:00:0e:2e:05:3e:be:08:00 SRC=192.168.1.100 > DST=192.168.2.100 LEN=99 TOS=0x00 PREC=0xC0 TTL=63 ID=2446 PROTO=ICMP > TYPE=3 CODE=3 [SRC=192.168.2.100 DST=192.168.1.100 LEN=71 TOS=0x00 > PREC=0x00 TTL=63 ID=31218 DF PROTO=UDP SPT=1030 DPT=53 LEN=51 ]

It's an iptables rule that limits icmp packets.

It : - is not applied on the internals of the mesh (172.16/16) - limits icmp to 30/s from your clients (192.168/16) - limits icmp to 5/min and adds an entry in the syslog with the prefix STORMWARNING if it comes from an other IP than the previous ones.

It's strange that you get such a message with 2 192.168/16 IPS. I thought you would fall into case 2.

Any idea ?

You can comment the rules in /etc/rc.d/rc.firewall if it annoys you.

=
============ Dave,

That's a PacketStorm. It is similar to the issue that Kyle just saw on his network - although it was with clients, while this appears to be between nodes. Looking at this below, here's what I see. It is on a bridged interface (br0) - so it's likely an issue from node to node only. If it were on wlan0, it would be node to client. SRC is one of your nodes - 1.110.146.200 DST is another node - 1.155.80.161 assume that one of the DST 's is the gateway, likely the 1.24.71.99 address.
 * If you look on down, you will see another DST 1.24.71.99. I would

If you are running dev74 on this node, the "threshold" for stormwarnings was set too low, and that was supposedly fixed in dev76. If you are dev76 or later, it likely really is a stormwarning. Packetstorms can really mess up a mesh network.

I'd suspect that maybe there is a weak link from one node to the other? Or possibly some interference. I think that this indicates that a number of packets were stored, then forwarded all at once.

Maybe someone else will build more on this.

Kb

Links
See HjDetectMode