From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 19 11:07:14 2012 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 91EE01065673 for ; Mon, 19 Mar 2012 11:07:14 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7C46D8FC16 for ; Mon, 19 Mar 2012 11:07:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2JB7E3g033609 for ; Mon, 19 Mar 2012 11:07:14 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2JB7Dbt033607 for freebsd-ipfw@FreeBSD.org; Mon, 19 Mar 2012 11:07:13 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 19 Mar 2012 11:07:13 GMT Message-Id: <201203191107.q2JB7Dbt033607@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 11:07:14 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/165190 ipfw [ipfw] [lo] [patch] loopback interface is not marking f kern/163873 ipfw [ipfw] ipfw fwd does not work with 'via interface' in o kern/158066 ipfw [ipfw] ipfw + netgraph + multicast = multicast packets o kern/157796 ipfw [ipfw] IPFW in-kernel NAT nat loopback / Default Route o kern/157689 ipfw [ipfw] ipfw nat config does not accept nonexistent int o kern/156770 ipfw [ipfw] [dummynet] [patch]: performance improvement and f kern/155927 ipfw [ipfw] ipfw stops to check packets for compliance with o bin/153252 ipfw [ipfw][patch] ipfw lockdown system in subsequent call o kern/153161 ipfw [ipfw] does not support specifying rules with ICMP cod o kern/152113 ipfw [ipfw] page fault on 8.1-RELEASE caused by certain amo o kern/148827 ipfw [ipfw] divert broken with in-kernel ipfw o kern/148689 ipfw [ipfw] antispoof wrongly triggers on link local IPv6 a o kern/148430 ipfw [ipfw] IPFW schedule delete broken. o kern/148091 ipfw [ipfw] ipfw ipv6 handling broken. o kern/143973 ipfw [ipfw] [panic] ipfw forward option causes kernel reboo o kern/143621 ipfw [ipfw] [dummynet] [patch] dummynet and vnet use result o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/135476 ipfw [ipfw] IPFW table breaks after adding a large number o o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n p kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l f kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o bin/83046 ipfw [ipfw] ipfw2 error: "setup" is allowed for icmp, but s o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes s kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 42 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Sat Mar 24 01:01:56 2012 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 789A91065674; Sat, 24 Mar 2012 01:01:56 +0000 (UTC) (envelope-from freebsd-ipfw@herveybayaustralia.com.au) Received: from mail.unitedinsong.com.au (mail.unitedinsong.com.au [150.101.178.33]) by mx1.freebsd.org (Postfix) with ESMTP id B00628FC0C; Sat, 24 Mar 2012 01:01:55 +0000 (UTC) Received: from laptop1.herveybayaustralia.com.au (laptop1.herveybayaustralia.com.au [192.168.0.182]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.unitedinsong.com.au (Postfix) with ESMTPSA id EE11B5C22; Sat, 24 Mar 2012 11:15:27 +1000 (EST) Message-ID: <4F6D1D00.1080607@herveybayaustralia.com.au> Date: Sat, 24 Mar 2012 11:01:52 +1000 From: Da Rock User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111109 Thunderbird/7.0.1 MIME-Version: 1.0 To: Julian Elischer References: <4F5A161C.8060407@herveybayaustralia.com.au> <8823954.VFuFedYPUb@magi> <4F644CF4.2010004@herveybayaustralia.com.au> <4F64BC7A.8080607@freebsd.org> In-Reply-To: <4F64BC7A.8080607@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-ipfw@freebsd.org Subject: Re: newbie IPFW user - when handbook examples dont work... X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 01:01:56 -0000 On 03/18/12 02:31, Julian Elischer wrote: > On 3/17/12 1:36 AM, Da Rock wrote: >> On 03/14/12 17:09, Rémy Sanchez wrote: >>> On Saturday 10 March 2012 00:39:24 Da Rock wrote: >>>> I'm relatively new to IPFW, not FBSD; the last time I used IPFW (I >>>> believe) was using 4.3. I'm now attempting to use IPFW for some tests >>>> (and hopefully move to production), and I'm trying to determine how I >>>> would setup binat using IPFW; or even if its possible at all. >>>> >>>> I've been hunting some more in depth documentation, but it appears >>>> to be >>>> scarce/not definitive. I suspect using the modes in libalias such as >>>> "use same ports" and "reverse" might be able to do what I'm looking >>>> for? >>>> >>>> Any clarity much appreciated. >>>> _______________________________________________ >>>> freebsd-ipfw@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >>>> To unsubscribe, send any mail to >>>> "freebsd-ipfw-unsubscribe@freebsd.org" >>> Well, what do you want to do with your firewall ? >>> >>> Because ipfw is kick-ass for QoS management, and is fairly simple to >>> use in >>> other tasks, but if you want to do some complex NAT, it's going to >>> be a pain >>> in comparison to what pf offers. >>> >>> Just make sure of what your main requirement is :) >>> >>> My 2 cents, >> Bluntly put, but very accurate :) >> >> I want it to do something pf cant - port forward ipsec packets for >> Android L2TP/IPSec. Apparently (according to pfsense experts) it is >> impossible until Android 3.0 or 4.0. My next port of call will be >> ipfilter, and thats a known working solution but I want to use more >> robust native tools. > > you need to really explain what you want here.. do you want the IP > packets to still have the original ports/addesses in them or do you > want to have the packets untouched, but redirected? > > a picture helps too. To be honest I'm not sure anyone specifically understands why pf fails. I think it may have to do with fragmentation reassembly. To describe in a nutshell (remembering that this is a testbed scenario atm to be replicated 1:1 with the real world): [WAN] <---> [EXTIF/red0][INTIF/green0] <---> [internal network/LAN] <---> [VPN - L2TP/IPSec] This is in a VBox environment atm, using a virtual lan. This is turning out to be a lot harder than I thought; I've tried all kinds of tricks but its a complete no go! I resorted to the example in the handbook for NAT, and I still cannot communicate from the VPN to the rest of the network. I cannot for the life of me determine the reason for this, and I now turn to the gurus of the IPFW :) These are the rules I'm using (for the most part a direct copy/paste of the handbook, with some variations such as ssh and non discriminate outbound traffic): #!/bin/sh cmd="ipfw -q add" skip="skipto 500" pif=red0 ks="keep-state" good_tcpo="22,25,37,43,53,80,443,110,119" ipfw -q -f flush $cmd 001 allow log ip from any to any ssh keep-state $cmd 002 allow log all from any to any via green0 # exclude LAN traffic $cmd 003 allow log all from any to any via lo0 # exclude loopback traffic $cmd 100 divert natd log ip from any to any in via $pif $cmd 101 check-state log # Authorized outbound packets $cmd 120 $skip log ip from any to any in via green0 setup $ks #$cmd 121 $skip log udp from any to any 53 out via $pif $ks #$cmd 125 $skip log tcp from any to any $good_tcpo out via $pif setup $ks #$cmd 130 $skip log icmp from any to any out via $pif $ks #$cmd 135 $skip log udp from any to any 123 out via $pif $ks # Deny all inbound traffic from non-routable reserved address spaces #$cmd 300 deny log all from 192.168.0.0/16 to any in via $pif #RFC 1918 private IP $cmd 301 deny log all from 172.16.0.0/12 to any in via $pif #RFC 1918 private IP $cmd 302 deny log all from 10.0.0.0/8 to any in via $pif #RFC 1918 private IP $cmd 303 deny log all from 127.0.0.0/8 to any in via $pif #loopback $cmd 304 deny log all from 0.0.0.0/8 to any in via $pif #loopback $cmd 305 deny log all from 169.254.0.0/16 to any in via $pif #DHCP auto-config $cmd 306 deny log all from 192.0.2.0/24 to any in via $pif #reserved for docs $cmd 307 deny log all from 204.152.64.0/23 to any in via $pif #Sun cluster $cmd 308 deny log all from 224.0.0.0/3 to any in via $pif #Class D & E multicast # Authorized inbound packets $cmd 400 allow log udp from any to me 68 in $ks $cmd 440 allow log all from me to any $cmd 445 allow log all from any to me $cmd 450 deny log ip from any to any # This is skipto location for outbound stateful rules $cmd 500 divert natd log ip from any to any out via $pif The default is to allow (for the moment). I've set the natd in the rc.conf: gateway_enable="YES" firewall_enable="YES" firewall_logging="YES" natd_enable="YES" natd_interface="red0" natd_flags="-dynamic -m -log -log_denied" So I can see the alias logs: icmp=0, udp=13, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / tot=13 (sock=0) icmp=0, udp=14, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / tot=14 (sock=0) icmp=0, udp=13, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / tot=13 (sock=0) icmp=0, udp=14, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / tot=14 (sock=0) icmp=0, udp=13, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / tot=13 (sock=0) icmp=0, udp=12, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / tot=12 (sock=0) icmp=0, udp=11, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / tot=11 (sock=0) icmp=0, udp=10, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / tot=10 (sock=0) icmp=0, udp=11, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / tot=11 (sock=0) icmp=0, udp=10, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / tot=10 (sock=0) And the firewall logs show that the traffic *from* the VPN hits rule 3 quitting at rule 450, and I cannot prevent it no matter what I try. What am I missing here? Logging is verbose and unlimited. I did start with exactly what was in the handbook, with ssh turned on and a generic outbound skipto. The kernel is built with these options (although I did try without): include GENERIC ident FIREWALL # IPFW for NAT options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=5 options IPFIREWALL_FORWARD options DUMMYNET options IPDIVERT options HZ=1000 # ALTQ Support options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_CDNR options ALTQ_PRIQ #options ALTQ_NOPCC options ALTQ_DEBUG Also, I understand the need for protection from syslog DOS when verbose logging is on, but is there any way to mitigate it? The logs show only the first hits and then nothing, but they don't count individual peers - just the hits. That appears to be quite a hole in the system... TIA > >> >> As for being a pita - I don't know. It doesn't seem any harder to me, >> could even be easier; seems to be a psychological thing. I'll get >> back to you (the list) when I have achieved an outcome and let you >> know. So far I haven't had to compile a new kernel, so thats a >> definite plus... that could change though. More info in the next >> episode ;) I've just finished wrestling with certificate >> generation.... grr! It was easier last time, not sure what has been >> the issue this time. >> _______________________________________________ >> freebsd-ipfw@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" >> >> > From owner-freebsd-ipfw@FreeBSD.ORG Sat Mar 24 16:57:09 2012 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 843F7106564A; Sat, 24 Mar 2012 16:57:09 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 7B1178FC20; Sat, 24 Mar 2012 16:57:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id q2OGuS82047247; Sun, 25 Mar 2012 03:56:29 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 25 Mar 2012 03:56:28 +1100 (EST) From: Ian Smith To: Da Rock In-Reply-To: <4F6D1D00.1080607@herveybayaustralia.com.au> Message-ID: <20120325013410.H2060@sola.nimnet.asn.au> References: <4F5A161C.8060407@herveybayaustralia.com.au> <8823954.VFuFedYPUb@magi> <4F644CF4.2010004@herveybayaustralia.com.au> <4F64BC7A.8080607@freebsd.org> <4F6D1D00.1080607@herveybayaustralia.com.au> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1336100332-1332606636=:2060" Content-ID: <20120325033051.E2060@sola.nimnet.asn.au> Cc: freebsd-ipfw@freebsd.org, Julian Elischer Subject: Re: newbie IPFW user - when handbook examples dont work... X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 16:57:09 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1336100332-1332606636=:2060 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-ID: <20120325033051.D2060@sola.nimnet.asn.au> On Sat, 24 Mar 2012, Da Rock wrote: > On 03/18/12 02:31, Julian Elischer wrote: > > On 3/17/12 1:36 AM, Da Rock wrote: > > > On 03/14/12 17:09, Rémy Sanchez wrote: > > > > On Saturday 10 March 2012 00:39:24 Da Rock wrote: > > > > > I'm relatively new to IPFW, not FBSD; the last time I used IPFW (I > > > > > believe) was using 4.3. I'm now attempting to use IPFW for some tests > > > > > (and hopefully move to production), and I'm trying to determine how I > > > > > would setup binat using IPFW; or even if its possible at all. > > > > > > > > > > I've been hunting some more in depth documentation, but it appears to > > > > > be > > > > > scarce/not definitive. I suspect using the modes in libalias such as > > > > > "use same ports" and "reverse" might be able to do what I'm looking > > > > > for? > > > > > > > > > > Any clarity much appreciated. [..] > > > I want it to do something pf cant - port forward ipsec packets for > > > Android L2TP/IPSec. Apparently (according to pfsense experts) it is > > > impossible until Android 3.0 or 4.0. My next port of call will be > > > ipfilter, and thats a known working solution but I want to use more > > > robust native tools. > > > > you need to really explain what you want here.. do you want the IP packets > > to still have the original ports/addesses in them or do you want to have > > the packets untouched, but redirected? > > > > a picture helps too. > To be honest I'm not sure anyone specifically understands why pf fails. I > think it may have to do with fragmentation reassembly. Can't comment; I suppose you've asked on the pf list? > To describe in a nutshell (remembering that this is a testbed scenario atm to > be replicated 1:1 with the real world): > > [WAN] <---> [EXTIF/red0][INTIF/green0] <---> [internal network/LAN] > <---> [VPN - L2TP/IPSec] I'm hampered in this by not knowing exactly which ports are used, either way, by L2TP/IPSec? This would be easier if that were explicit, same with your other mentioned NAT need, for VoIP. A short tcpdump segment? To echo Julian: 'you need to really explain what you want here..' re the addresses and ports of specific 'unusual' traffic you want NAT'd. > This is in a VBox environment atm, using a virtual lan. > > This is turning out to be a lot harder than I thought; I've tried all kinds > of tricks but its a complete no go! I resorted to the example in the handbook Oh dear. Sorry, but ipfw(8) and rc.firewall are the only decent docs, you will find it harder if you allow yourself to be misled by that rave; not unlike teaching structured programming to someone who learned BASIC. The ipfw handbook section - originally written by someone who admitedly prefers ipfilter and has written rulesets more suitable for it, later 'updated' by a plethora of real factual errors and illinformed advice - is the largest factor mitigating against more widespread and better-informed use of ipfw, in my view. Yes, I have to plead guilty of having failed to completely rewrite it, which is its only cure. > for NAT, and I still cannot communicate from the VPN to the rest of the > network. I cannot for the life of me determine the reason for this, and I now > turn to the gurus of the IPFW :) > > These are the rules I'm using (for the most part a direct copy/paste of the > handbook, with some variations such as ssh and non discriminate outbound > traffic): > > #!/bin/sh > cmd="ipfw -q add" > skip="skipto 500" > pif=red0 > ks="keep-state" > good_tcpo="22,25,37,43,53,80,443,110,119" > > ipfw -q -f flush > > $cmd 001 allow log ip from any to any ssh keep-state Not here; you're doing that, both in and out, before any NAT remapping. You'd be better off using stateful rules (later) for this, at least while you're getting things sorted out. Ignore the handbook rave's push to use stateful rules everywhere, often for no good reason. > $cmd 002 allow log all from any to any via green0 # exclude LAN traffic This allows all traffic from the LAN in, but also permits all traffic going out - on _any_ interface including your outside red0 - that came in on green0! And doing so before any NAT mapping, which will fail. Unless you're really familiar with what 'via' does on both inbound and outbound passes through the firewall (see ipfw(8)), try to always use 'in recv' and 'out xmit' to disambiguate, especially with outbound. > $cmd 003 allow log all from any to any via lo0 # exclude loopback traffic In that case 'via' IS appropriate on both passes, but see rc.firewall for a better approach to handling loopback traffic (both IPv4 and v6). > $cmd 100 divert natd log ip from any to any in via $pif > $cmd 101 check-state log Actually the state checking has occurred already on the first keep-state rule encountered (rule 1). Check rc.firewall 'simple' for the correct placement of nat/divert rules with anti-spoofing rules both before and after NAT, some of which you're not doing till way below. > # Authorized outbound packets > $cmd 120 $skip log ip from any to any in via green0 setup $ks 'skipto .. keep-state' rules can be very hard to follow. Drop the $ks if you just want to separate traffic coming 'in recv green0'. Anyway, 'skipto 500' according to that ruleset (and the comment below) is meant to be for _outbound_ traffic, before being NAT'd. This is confus{ing,ed} at the best of times, but will fail if passed inbound. > #$cmd 121 $skip log udp from any to any 53 out via $pif $ks > #$cmd 125 $skip log tcp from any to any $good_tcpo out via $pif setup $ks > #$cmd 130 $skip log icmp from any to any out via $pif $ks > #$cmd 135 $skip log udp from any to any 123 out via $pif $ks Argh, that example ruleset is so weird, it's hard to know where to start. I'd scrap the lot, start with rc.firewall 'simple' with maybe bits of 'workstation' for outbound traffic, but at least obvious flows. > # Deny all inbound traffic from non-routable reserved address spaces I think this is where you meant to skipto on _inbound_ traffic, not 500? > #$cmd 300 deny log all from 192.168.0.0/16 to any in via $pif #RFC 1918 > private IP > $cmd 301 deny log all from 172.16.0.0/12 to any in via $pif #RFC 1918 > private IP > $cmd 302 deny log all from 10.0.0.0/8 to any in via $pif #RFC 1918 > private IP > $cmd 303 deny log all from 127.0.0.0/8 to any in via $pif #loopback > $cmd 304 deny log all from 0.0.0.0/8 to any in via $pif #loopback > $cmd 305 deny log all from 169.254.0.0/16 to any in via $pif #DHCP > auto-config > $cmd 306 deny log all from 192.0.2.0/24 to any in via $pif #reserved for > docs > $cmd 307 deny log all from 204.152.64.0/23 to any in via $pif #Sun cluster > $cmd 308 deny log all from 224.0.0.0/3 to any in via $pif #Class D & E > multicast That takes care of spoofed inbound traffic, but doesn't stop spoofed outbound traffic from your net. Again, refer to rc.firewall. > # Authorized inbound packets > $cmd 400 allow log udp from any to me 68 in $ks > > $cmd 440 allow log all from me to any > $cmd 445 allow log all from any to me > > $cmd 450 deny log ip from any to any > > # This is skipto location for outbound stateful rules > $cmd 500 divert natd log ip from any to any out via $pif If you skipto 500 on inbound traffic (as above) that'll be ignored, and: > The default is to allow (for the moment). Even so, an explicit allow|deny rule at end shows counts which may help. > I've set the natd in the rc.conf: > > gateway_enable="YES" > firewall_enable="YES" > firewall_logging="YES" > natd_enable="YES" > natd_interface="red0" > natd_flags="-dynamic -m -log -log_denied" Mmm. > So I can see the alias logs: > > icmp=0, udp=13, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / tot=13 > (sock=0) > icmp=0, udp=14, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / tot=14 > (sock=0) > icmp=0, udp=13, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / tot=13 > (sock=0) > icmp=0, udp=14, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / tot=14 > (sock=0) > icmp=0, udp=13, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / tot=13 > (sock=0) > icmp=0, udp=12, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / tot=12 > (sock=0) > icmp=0, udp=11, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / tot=11 > (sock=0) > icmp=0, udp=10, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / tot=10 > (sock=0) > icmp=0, udp=11, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / tot=11 > (sock=0) > icmp=0, udp=10, tcp=0, sctp=0, pptp=0, proto=0, frag_id=0 frag_ptr=0 / tot=10 > (sock=0) Mmm, I've never found natd's logging of much use myself. Adding extra 'count log' rules before and after performing NAT can be more helpful if anything weird seems to be happening, I find. > And the firewall logs show that the traffic *from* the VPN hits rule 3 > quitting at rule 450, and I cannot prevent it no matter what I try. rule 3? loopback? 'ipfw show' is better than a verbal description. > What am I missing here? Logging is verbose and unlimited. I did start with > exactly what was in the handbook, with ssh turned on and a generic outbound > skipto. The kernel is built with these options (although I did try without): It's sad to have to say, ignore the Handbook and really study ipfw(8). > include GENERIC > ident FIREWALL > > # IPFW for NAT > options IPFIREWALL > options IPFIREWALL_VERBOSE > options IPFIREWALL_VERBOSE_LIMIT=5 More generally bad Handbook advice, based on a misunderstanding of how syslogd(8) works :( Better using 'log logamount N' for different rules. > options IPFIREWALL_FORWARD Only needed if you're using forward|fwd rules. Otherwise you can use a GENERIC kernel, loading ipfw and ipdivert. > options DUMMYNET > options IPDIVERT > options HZ=1000 > > # ALTQ Support > options ALTQ > options ALTQ_CBQ > options ALTQ_RED > options ALTQ_RIO > options ALTQ_HFSC > options ALTQ_CDNR > options ALTQ_PRIQ > #options ALTQ_NOPCC > options ALTQ_DEBUG > > Also, I understand the need for protection from syslog DOS when verbose > logging is on, but is there any way to mitigate it? The logs show only the > first hits and then nothing, but they don't count individual peers - just the > hits. That appears to be quite a hole in the system... Well you've got IPFIREWALL_VERBOSE_LIMIT=5. Try 100 while testing, you can just adjust the sysctl anytime, and add 'logamount N' where needed. Also, traffic counted both ways under keep-state rules can be confusing. > TIA > > > > > > > > As for being a pita - I don't know. It doesn't seem any harder to me, > > > could even be easier; seems to be a psychological thing. I'll get back to > > > you (the list) when I have achieved an outcome and let you know. So far I > > > haven't had to compile a new kernel, so thats a definite plus... that > > > could change though. More info in the next episode ;) I've just finished > > > wrestling with certificate generation.... grr! It was easier last time, > > > not sure what has been the issue this time. It is a psychological thing, or rather perhaps philosophical. If you follow rc.firewall eg 'simple' and 'workstation' and ipfw(8) you'll have a better clue than the convoluted monstrosities of Handbook examples. All IMHO, OC .. cheers, Ian --0-1336100332-1332606636=:2060--