From owner-freebsd-pf@FreeBSD.ORG Sun Mar 20 12:34:47 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70CEA1065670 for ; Sun, 20 Mar 2011 12:34:47 +0000 (UTC) (envelope-from atmotaruno@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 269FA8FC0A for ; Sun, 20 Mar 2011 12:34:46 +0000 (UTC) Received: by vws18 with SMTP id 18so5313392vws.13 for ; Sun, 20 Mar 2011 05:34:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=tV62YBe/jJ5f1Q9FqIqVRd4rsmK3Gz7vhx5Zcw83oFo=; b=X8Plf5kgKPnae701vA6gm0knlQCaPmo58o5g2z0rRuAKkB6XJzWRkyONk7/G3IwMx0 gKtQRX4NsAIsbRGwDbSWXsO64OxuNEKPLjnufLlcoKarzuxTK5hjrpSaFi3tRuCeY7Uh nT0dg1xQQc6dGqii2/VzbGk9yMdYGar8wQfaE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=AeCb2X0D07Q2JAxIcuhrgBsPEXX02VeHbBB3c3yIV63c2XVY7TXDi1Lc0q4++DqA6c MOOBGrjPYkMkgjdH4ul45sb10tKpIKnUxLruHhkkWJ22tGHK8NAJJOqlGGFLPOEIkKll w1/7A36PEklx1KKA8Z7mJPQM9HxDsO+EEzR/0= MIME-Version: 1.0 Received: by 10.52.68.175 with SMTP id x15mr4118021vdt.163.1300622815886; Sun, 20 Mar 2011 05:06:55 -0700 (PDT) Received: by 10.220.19.136 with HTTP; Sun, 20 Mar 2011 05:06:55 -0700 (PDT) Date: Sun, 20 Mar 2011 19:06:55 +0700 Message-ID: From: Nugroho Atmotaruno To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: pf rdr & dummynet patch X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2011 12:34:47 -0000 Hi all, I want to ask about PR 148260[1] patch, about pf rdr & dummynet incompatibility, will it be committed? [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=148260&cat= -- Regards, Nugroho From owner-freebsd-pf@FreeBSD.ORG Mon Mar 21 01:29:09 2011 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D5BB106564A; Mon, 21 Mar 2011 01:29:09 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 276CE8FC08; Mon, 21 Mar 2011 01:29:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p2L1T9iC034351; Mon, 21 Mar 2011 01:29:09 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p2L1T9uZ034347; Mon, 21 Mar 2011 01:29:09 GMT (envelope-from linimon) Date: Mon, 21 Mar 2011 01:29:09 GMT Message-Id: <201103210129.p2L1T9uZ034347@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-pf@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/155736: [pf] [altq] borrow from parent queue does not work with cbq X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 01:29:09 -0000 Synopsis: [pf] [altq] borrow from parent queue does not work with cbq Responsible-Changed-From-To: freebsd-bugs->freebsd-pf Responsible-Changed-By: linimon Responsible-Changed-When: Mon Mar 21 01:28:56 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=155736 From owner-freebsd-pf@FreeBSD.ORG Mon Mar 21 11:07:03 2011 Return-Path: Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 911E91065670 for ; Mon, 21 Mar 2011 11:07:03 +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 81B808FC13 for ; Mon, 21 Mar 2011 11:07:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p2LB734d086068 for ; Mon, 21 Mar 2011 11:07:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p2LB72Y8086066 for freebsd-pf@FreeBSD.org; Mon, 21 Mar 2011 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 21 Mar 2011 11:07:02 GMT Message-Id: <201103211107.p2LB72Y8086066@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-pf@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 11:07:03 -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/155736 pf [pf] [altq] borrow from parent queue does not work wit o kern/153307 pf [pf] Bug with PF firewall o kern/148290 pf [pf] "sticky-address" option of Packet Filter (PF) blo o kern/148260 pf [pf] [patch] pf rdr incompatible with dummynet o kern/147789 pf [pf] Firewall PF no longer drops connections by sendin o kern/146832 pf [pf] "(self)" not always matching all local IPv6 addre o kern/143543 pf [pf] [panic] PF route-to causes kernel panic o bin/143504 pf [patch] outgoing states are not killed by authpf(8) o conf/142961 pf [pf] No way to adjust pidfile in pflogd o conf/142817 pf [patch] etc/rc.d/pf: silence pfctl o kern/141905 pf [pf] [panic] pf kernel panic on 7.2-RELEASE with empty o kern/140697 pf [pf] pf behaviour changes - must be documented o kern/137982 pf [pf] when pf can hit state limits, random IP failures o kern/136781 pf [pf] Packets appear to drop with pf scrub and if_bridg o kern/135948 pf [pf] [gre] pf not natting gre protocol o kern/135162 pf [pfsync] pfsync(4) not usable with GENERIC kernel o kern/134996 pf [pf] Anchor tables not included when pfctl(8) is run w o kern/133732 pf [pf] max-src-conn issue o kern/132769 pf [pf] [lor] 2 LOR's with pf task mtx / ifnet and rtent f kern/132176 pf [pf] pf stalls connection when using route-to [regress o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st o kern/129861 pf [pf] [patch] Argument names reversed in pf_table.c:_co o kern/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o kern/127439 pf [pf] deadlock in pf f kern/127345 pf [pf] Problem with PF on FreeBSD7.0 [regression] o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] [lor] pf_ioctl.c + if.c o kern/114095 pf [carp] carp+pf delay with high state limit s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/103283 pf pfsync fails to sucessfully transfer some sessions o kern/103281 pf pfsync reports bulk update failures o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o bin/86635 pf [patch] pfctl(8): allow new page character (^L) in pf. o kern/82271 pf [pf] cbq scheduler cause bad latency 46 problems total. From owner-freebsd-pf@FreeBSD.ORG Tue Mar 22 09:23:00 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33690106564A for ; Tue, 22 Mar 2011 09:23:00 +0000 (UTC) (envelope-from andy@time-domain.co.uk) Received: from mail.time-domain.co.uk (81-179-248-237.static.dsl.pipex.com [81.179.248.237]) by mx1.freebsd.org (Postfix) with ESMTP id ACB5A8FC17 for ; Tue, 22 Mar 2011 09:22:59 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.time-domain.co.uk (8.14.3/8.14.3) with ESMTP id p2M8wKLL007659 for ; Tue, 22 Mar 2011 08:58:20 GMT Date: Tue, 22 Mar 2011 08:58:20 +0000 (GMT) From: andy thomas X-X-Sender: andy-tds@mail.time-domain.co.uk To: freebsd-pf@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: PF port forward problem with Sonicwall VPN (revisited) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 09:23:00 -0000 At the end of January I posted this message (see below) regarding a problem with forwarding incoming traffic on port 444 to an internal IP address on port 443. At the time I didn't get very far with this and the problem "went off the boil" a bit after we upgraded the ShrewSoft VPN installations on the remote Windows PCs to the latest available version and this works fine with the existing IPSec installation on the firewall, which has taken the pressure off me. But I've now started looking at the problem afresh and after logging into the Sonicwall VPN appliance's web interface from a local PC, there is a diagnostic ping utility on the Sonicwall - it is possible to ping the internal firewall interface vr1 (which uses the IP address 192.168.30.1) but attempts to ping the external interface on vr0 or any external address fail. The pf ruleset remains as before: ext_if="vr0" (external IP address) int_if="vr1" (192.168.30.1) sonicwall="192.168.30.28" rdr pass log on $ext_if proto tcp from any to $ext_if port 444 -> $sonicwall port 443 An almost identical rule is used for a webmail server except that there is no port address translation (ie, external port 443 forwards directly to internal port 443) and this has no problems. Clearly something is missing from my Sonicwall rule that is blocking traffic from the Sonicwall to the external interface - as I'm doing PAT as well as NAT in this instance, do I need to add an additional rule(s)? Andy ---------- Forwarded message ---------- Date: Fri, 28 Jan 2011 08:49:27 +0000 (GMT) From: andy thomas To: freebsd-pf@freebsd.org Subject: PF port forward problem with Sonicwall VPN I'm maintaining some OpenBSD-based firewalls and have been really stumped with a problem when trying to add a Sonicwall VPN appliance behind the firewall, and thought I'd ask here for help. The Sonicwall device uses SSL on port 443 for it's external VPN traffic and listens on other ports for internal LAN traffic and it uses a single network interface for this. On our installation, there is a webmail server behind the firewall listening on port 443 and the existing PF rule for this is (abbreviated for clarity): ext_if="vr0" int_if="vr1" webmail="192.168.30.14" rdr pass log on $ext_if proto tcp from any to $ext_if port 443 -> $webmail port 443 This works fine so as external port 443 is already in use for webmail, I decided to use external port 444 for the Sonicwall and added these two extra rules: sonicwall="192.168.30.28" rdr pass log on $ext_if proto tcp from any to $ext_if port 444 -> $sonicwall port 443 However, the Sonicwall cannot be accessed from the external port 444 although it can be accessed internallt on port 443 of course. I have tested this rule by changing it to point to the webmail server like this: rdr pass log on $ext_if proto tcp from any to $ext_if port 444 -> $webmail port 443 and this works fine as I can access webmail on port 444. But why can't I access the Sonicwall on port 444? Does anyone know if the Sonicwall uses additional ports or has anyone got this device to with with a PF-based firewall? Thanks in advance for any suggestions, Andy From owner-freebsd-pf@FreeBSD.ORG Tue Mar 22 09:40:55 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD715106566C for ; Tue, 22 Mar 2011 09:40:55 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 6DD438FC08 for ; Tue, 22 Mar 2011 09:40:55 +0000 (UTC) Received: by wwc33 with SMTP id 33so8443366wwc.31 for ; Tue, 22 Mar 2011 02:40:54 -0700 (PDT) Received: by 10.227.205.12 with SMTP id fo12mr5111904wbb.70.1300786853846; Tue, 22 Mar 2011 02:40:53 -0700 (PDT) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id l24sm1538495wbc.64.2011.03.22.02.40.51 (version=SSLv3 cipher=OTHER); Tue, 22 Mar 2011 02:40:52 -0700 (PDT) Message-ID: <4D886EA2.2070000@my.gd> Date: Tue, 22 Mar 2011 10:40:50 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-pf@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: PF port forward problem with Sonicwall VPN (revisited) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 09:40:56 -0000 On 3/22/11 9:58 AM, andy thomas wrote: > ---------- Forwarded message ---------- > Date: Fri, 28 Jan 2011 08:49:27 +0000 (GMT) > From: andy thomas > To: freebsd-pf@freebsd.org > Subject: PF port forward problem with Sonicwall VPN > > I'm maintaining some OpenBSD-based firewalls and have been really > stumped with a problem when trying to add a Sonicwall VPN appliance > behind the firewall, and thought I'd ask here for help. > > The Sonicwall device uses SSL on port 443 for it's external VPN traffic > and listens on other ports for internal LAN traffic and it uses a single > network interface for this. On our installation, there is a webmail > server behind the firewall listening on port 443 and the existing PF > rule for this is (abbreviated for clarity): > > ext_if="vr0" > int_if="vr1" > > webmail="192.168.30.14" > > rdr pass log on $ext_if proto tcp from any to $ext_if port 443 -> > $webmail port 443 > Ok > This works fine so as external port 443 is already in use for webmail, I > decided to use external port 444 for the Sonicwall and added these two > extra rules: > > sonicwall="192.168.30.28" > > rdr pass log on $ext_if proto tcp from any to $ext_if port 444 -> > $sonicwall port 443 > This rule rewrites the destination IP address so that it is now the sonicwall's instead of your PF's public IP. This rule rewrites the destination TCP port so that it is now port 443 instead of the original port 444. Take good note that the source address remains unchanged so your sonicwall needs to know a route back to the client. > However, the Sonicwall cannot be accessed from the external port 444 > although it can be accessed internallt on port 443 of course. I have > tested this rule by changing it to point to the webmail server like this: > > rdr pass log on $ext_if proto tcp from any to $ext_if port 444 -> > $webmail port 443 > Seeing you can access your webmail just fine on port 444 but not the sonicwall clearly shows the problem is with the sonicwall, not PF. Possible issues to investigate: 1/ lack of a default gateway on your sonicwall 2/ misconfigured security rules on your sonicwall not allowing the traffic. > and this works fine as I can access webmail on port 444. But why can't I > access the Sonicwall on port 444? Does anyone know if the Sonicwall uses > additional ports or has anyone got this device to with with a PF-based > firewall? > > Thanks in advance for any suggestions, > I would advise you change your RDR rule to a NAT rule, so that traffic will be seen coming from the PF's interface (choose which) and the sonicwall will have a direct connection with this network. > Andy > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" From owner-freebsd-pf@FreeBSD.ORG Wed Mar 23 07:21:39 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1828C1065673 for ; Wed, 23 Mar 2011 07:21:39 +0000 (UTC) (envelope-from andy@time-domain.co.uk) Received: from mail.time-domain.co.uk (81-179-248-237.static.dsl.pipex.com [81.179.248.237]) by mx1.freebsd.org (Postfix) with ESMTP id A56018FC0C for ; Wed, 23 Mar 2011 07:21:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.time-domain.co.uk (8.14.3/8.14.3) with ESMTP id p2N7La7n014122; Wed, 23 Mar 2011 07:21:37 GMT Date: Wed, 23 Mar 2011 07:21:36 +0000 (GMT) From: andy thomas X-X-Sender: andy-tds@mail.time-domain.co.uk To: Damien Fleuriot In-Reply-To: <4D886EA2.2070000@my.gd> Message-ID: References: <4D886EA2.2070000@my.gd> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: freebsd-pf@freebsd.org Subject: Re: PF port forward problem with Sonicwall VPN (revisited) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 07:21:39 -0000 On Tue, 22 Mar 2011, Damien Fleuriot wrote: > On 3/22/11 9:58 AM, andy thomas wrote: >> ---------- Forwarded message ---------- >> Date: Fri, 28 Jan 2011 08:49:27 +0000 (GMT) >> From: andy thomas >> To: freebsd-pf@freebsd.org >> Subject: PF port forward problem with Sonicwall VPN >> >> I'm maintaining some OpenBSD-based firewalls and have been really >> stumped with a problem when trying to add a Sonicwall VPN appliance >> behind the firewall, and thought I'd ask here for help. >> >> The Sonicwall device uses SSL on port 443 for it's external VPN traffic >> and listens on other ports for internal LAN traffic and it uses a single >> network interface for this. On our installation, there is a webmail >> server behind the firewall listening on port 443 and the existing PF >> rule for this is (abbreviated for clarity): >> >> ext_if="vr0" >> int_if="vr1" >> >> webmail="192.168.30.14" >> >> rdr pass log on $ext_if proto tcp from any to $ext_if port 443 -> >> $webmail port 443 >> > > Ok > > >> This works fine so as external port 443 is already in use for webmail, I >> decided to use external port 444 for the Sonicwall and added these two >> extra rules: >> >> sonicwall="192.168.30.28" >> >> rdr pass log on $ext_if proto tcp from any to $ext_if port 444 -> >> $sonicwall port 443 >> > > This rule rewrites the destination IP address so that it is now the > sonicwall's instead of your PF's public IP. > This rule rewrites the destination TCP port so that it is now port 443 > instead of the original port 444. > > Take good note that the source address remains unchanged so your > sonicwall needs to know a route back to the client. Presuably using a NAT rule rather than RDR will provide this return path? >> However, the Sonicwall cannot be accessed from the external port 444 >> although it can be accessed internallt on port 443 of course. I have >> tested this rule by changing it to point to the webmail server like this: >> >> rdr pass log on $ext_if proto tcp from any to $ext_if port 444 -> >> $webmail port 443 >> > > Seeing you can access your webmail just fine on port 444 but not the > sonicwall clearly shows the problem is with the sonicwall, not PF. This is what I thought initially but after I found I could not ping the external interface from the Sonicwall, it started to look like a PF problem. > Possible issues to investigate: > > 1/ lack of a default gateway on your sonicwall This is definitely configured correctly. > 2/ misconfigured security rules on your sonicwall not allowing the traffic. No security rules have been set up, only the basic network configuration has been carried out so far to get the device onto the network. >> and this works fine as I can access webmail on port 444. But why can't I >> access the Sonicwall on port 444? Does anyone know if the Sonicwall uses >> additional ports or has anyone got this device to with with a PF-based >> firewall? >> >> Thanks in advance for any suggestions, >> > > I would advise you change your RDR rule to a NAT rule, so that traffic > will be seen coming from the PF's interface (choose which) and the > sonicwall will have a direct connection with this network. I'm not an expert on PF so will need to read up on this - is it simply a case or replacing 'RDR' with 'NAT' in the existing rule? I must also be careful not to make any changes that may affect anything else on the internal network as this would be catastrophic for the organisation concerned (it's a remote site). Thanks for your prompt reply. Andy From owner-freebsd-pf@FreeBSD.ORG Wed Mar 23 10:11:30 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E49721065670 for ; Wed, 23 Mar 2011 10:11:30 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7BF6C8FC15 for ; Wed, 23 Mar 2011 10:11:27 +0000 (UTC) Received: by bwz12 with SMTP id 12so7562558bwz.13 for ; Wed, 23 Mar 2011 03:11:27 -0700 (PDT) Received: by 10.204.126.131 with SMTP id c3mr6151314bks.104.1300875087119; Wed, 23 Mar 2011 03:11:27 -0700 (PDT) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id v21sm5790847bkt.11.2011.03.23.03.11.25 (version=SSLv3 cipher=OTHER); Wed, 23 Mar 2011 03:11:26 -0700 (PDT) Message-ID: <4D89C74C.7010502@my.gd> Date: Wed, 23 Mar 2011 11:11:24 +0100 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: andy thomas References: <4D886EA2.2070000@my.gd> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-pf@freebsd.org Subject: Re: PF port forward problem with Sonicwall VPN (revisited) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 10:11:31 -0000 On 3/23/11 8:21 AM, andy thomas wrote: > On Tue, 22 Mar 2011, Damien Fleuriot wrote: > >> On 3/22/11 9:58 AM, andy thomas wrote: >>> ---------- Forwarded message ---------- >>> Date: Fri, 28 Jan 2011 08:49:27 +0000 (GMT) >>> From: andy thomas >>> To: freebsd-pf@freebsd.org >>> Subject: PF port forward problem with Sonicwall VPN >>> >>> I'm maintaining some OpenBSD-based firewalls and have been really >>> stumped with a problem when trying to add a Sonicwall VPN appliance >>> behind the firewall, and thought I'd ask here for help. >>> >>> The Sonicwall device uses SSL on port 443 for it's external VPN traffic >>> and listens on other ports for internal LAN traffic and it uses a single >>> network interface for this. On our installation, there is a webmail >>> server behind the firewall listening on port 443 and the existing PF >>> rule for this is (abbreviated for clarity): >>> >>> ext_if="vr0" >>> int_if="vr1" >>> >>> webmail="192.168.30.14" >>> >>> rdr pass log on $ext_if proto tcp from any to $ext_if port 443 -> >>> $webmail port 443 >>> >> >> Ok >> >> >>> This works fine so as external port 443 is already in use for webmail, I >>> decided to use external port 444 for the Sonicwall and added these two >>> extra rules: >>> >>> sonicwall="192.168.30.28" >>> >>> rdr pass log on $ext_if proto tcp from any to $ext_if port 444 -> >>> $sonicwall port 443 >>> >> >> This rule rewrites the destination IP address so that it is now the >> sonicwall's instead of your PF's public IP. >> This rule rewrites the destination TCP port so that it is now port 443 >> instead of the original port 444. >> >> Take good note that the source address remains unchanged so your >> sonicwall needs to know a route back to the client. > > Presuably using a NAT rule rather than RDR will provide this return path? > A NAT rule will not provide any better route, however it will replace the *source* IP address with your PF's . Before RDR: 88.190.13.60:28052 -> 212.163.10.24:444 After RDR: 88.190.13.60:28052 -> 192.168.30.28:443 Before NAT: 88.190.13.60:28052 -> 212.163.10.24:444 After NAT: 192.168.30.21:61209 -> 192.168.30.28:444 Notice how the destination port remained unchanged ! So you will have to either use both a RDR and a NAT rule, or just change the HTTPS port on your sonicwall to 444 to only use a NAT rule. NAT explained: http://www.openbsd.org/faq/pf/nat.html#works >>> However, the Sonicwall cannot be accessed from the external port 444 >>> although it can be accessed internallt on port 443 of course. I have >>> tested this rule by changing it to point to the webmail server like >>> this: >>> >>> rdr pass log on $ext_if proto tcp from any to $ext_if port 444 -> >>> $webmail port 443 >>> >> >> Seeing you can access your webmail just fine on port 444 but not the >> sonicwall clearly shows the problem is with the sonicwall, not PF. > > This is what I thought initially but after I found I could not ping the > external interface from the Sonicwall, it started to look like a PF > problem. > Well, you want to investigate a bit then. Set your rules on the PF to log passed/blocked packets. Then run: tcpdump -nei pflog0 ip and host 192.168.30.28 Then from the sonicwall try to ping the external interface. You'll see if your packet is blocked and by what rule number. Issue pfctl -vvsr to dump your firewall rules and check what rule blocked your packet. >> Possible issues to investigate: >> >> 1/ lack of a default gateway on your sonicwall > > This is definitely configured correctly. > Can you reach external hosts from the sonicwall, for example 88.190.222.254 ? >> 2/ misconfigured security rules on your sonicwall not allowing the >> traffic. > > No security rules have been set up, only the basic network configuration > has been carried out so far to get the device onto the network. > But perhaps there are default values that would block things ? >>> and this works fine as I can access webmail on port 444. But why can't I >>> access the Sonicwall on port 444? Does anyone know if the Sonicwall uses >>> additional ports or has anyone got this device to with with a PF-based >>> firewall? >>> >>> Thanks in advance for any suggestions, >>> >> >> I would advise you change your RDR rule to a NAT rule, so that traffic >> will be seen coming from the PF's interface (choose which) and the >> sonicwall will have a direct connection with this network. > > I'm not an expert on PF so will need to read up on this - is it simply a > case or replacing 'RDR' with 'NAT' in the existing rule? I must also be > careful not to make any changes that may affect anything else on the > internal network as this would be catastrophic for the organisation > concerned (it's a remote site). > See if you can change the sonicwall's HTTPS port to 444, then set up a NAT rule like this: nat pass on $extif inet proto tcp from any to $extif port 444 -> ($internal_if) This should do the trick nicely. Later on, you'll be able to refine the nat rule a bit to only allow trusted IPs to connect to your sonicwall. From owner-freebsd-pf@FreeBSD.ORG Fri Mar 25 06:15:08 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 615A0106566C for ; Fri, 25 Mar 2011 06:15:08 +0000 (UTC) (envelope-from andy@time-domain.co.uk) Received: from mail.time-domain.co.uk (81-179-248-237.static.dsl.pipex.com [81.179.248.237]) by mx1.freebsd.org (Postfix) with ESMTP id DE1BF8FC16 for ; Fri, 25 Mar 2011 06:15:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.time-domain.co.uk (8.14.3/8.14.3) with ESMTP id p2P6F5MY027358; Fri, 25 Mar 2011 06:15:05 GMT Date: Fri, 25 Mar 2011 06:15:05 +0000 (GMT) From: andy thomas X-X-Sender: andy-tds@mail.time-domain.co.uk To: Damien Fleuriot In-Reply-To: <4D89C74C.7010502@my.gd> Message-ID: References: <4D886EA2.2070000@my.gd> <4D89C74C.7010502@my.gd> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: freebsd-pf@freebsd.org Subject: Re: PF port forward problem with Sonicwall VPN (revisited) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 06:15:08 -0000 On Wed, 23 Mar 2011, Damien Fleuriot wrote: > > > On 3/23/11 8:21 AM, andy thomas wrote: >> On Tue, 22 Mar 2011, Damien Fleuriot wrote: >> >>> On 3/22/11 9:58 AM, andy thomas wrote: >>>> ---------- Forwarded message ---------- >>>> Date: Fri, 28 Jan 2011 08:49:27 +0000 (GMT) >>>> From: andy thomas >>>> To: freebsd-pf@freebsd.org >>>> Subject: PF port forward problem with Sonicwall VPN >>>> >>>> I'm maintaining some OpenBSD-based firewalls and have been really >>>> stumped with a problem when trying to add a Sonicwall VPN appliance >>>> behind the firewall, and thought I'd ask here for help. >>>> >>>> The Sonicwall device uses SSL on port 443 for it's external VPN traffic >>>> and listens on other ports for internal LAN traffic and it uses a single >>>> network interface for this. On our installation, there is a webmail >>>> server behind the firewall listening on port 443 and the existing PF >>>> rule for this is (abbreviated for clarity): >>>> >>>> ext_if="vr0" >>>> int_if="vr1" >>>> >>>> webmail="192.168.30.14" >>>> >>>> rdr pass log on $ext_if proto tcp from any to $ext_if port 443 -> >>>> $webmail port 443 >>>> >>> >>> Ok >>> >>> >>>> This works fine so as external port 443 is already in use for webmail, I >>>> decided to use external port 444 for the Sonicwall and added these two >>>> extra rules: >>>> >>>> sonicwall="192.168.30.28" >>>> >>>> rdr pass log on $ext_if proto tcp from any to $ext_if port 444 -> >>>> $sonicwall port 443 >>>> >>> >>> This rule rewrites the destination IP address so that it is now the >>> sonicwall's instead of your PF's public IP. >>> This rule rewrites the destination TCP port so that it is now port 443 >>> instead of the original port 444. >>> >>> Take good note that the source address remains unchanged so your >>> sonicwall needs to know a route back to the client. >> >> Presuably using a NAT rule rather than RDR will provide this return path? >> > > A NAT rule will not provide any better route, however it will replace > the *source* IP address with your PF's . > > Before RDR: > 88.190.13.60:28052 -> 212.163.10.24:444 > After RDR: > 88.190.13.60:28052 -> 192.168.30.28:443 > > > Before NAT: > 88.190.13.60:28052 -> 212.163.10.24:444 > After NAT: > 192.168.30.21:61209 -> 192.168.30.28:444 > > Notice how the destination port remained unchanged ! > So you will have to either use both a RDR and a NAT rule, or just change > the HTTPS port on your sonicwall to 444 to only use a NAT rule. > > NAT explained: http://www.openbsd.org/faq/pf/nat.html#works > > > >>>> However, the Sonicwall cannot be accessed from the external port 444 >>>> although it can be accessed internallt on port 443 of course. I have >>>> tested this rule by changing it to point to the webmail server like >>>> this: >>>> >>>> rdr pass log on $ext_if proto tcp from any to $ext_if port 444 -> >>>> $webmail port 443 >>>> >>> >>> Seeing you can access your webmail just fine on port 444 but not the >>> sonicwall clearly shows the problem is with the sonicwall, not PF. >> >> This is what I thought initially but after I found I could not ping the >> external interface from the Sonicwall, it started to look like a PF >> problem. >> > > Well, you want to investigate a bit then. > Set your rules on the PF to log passed/blocked packets. > Then run: tcpdump -nei pflog0 ip and host 192.168.30.28 > > Then from the sonicwall try to ping the external interface. > You'll see if your packet is blocked and by what rule number. > > Issue pfctl -vvsr to dump your firewall rules and check what rule > blocked your packet. > > >>> Possible issues to investigate: >>> >>> 1/ lack of a default gateway on your sonicwall >> >> This is definitely configured correctly. >> > > Can you reach external hosts from the sonicwall, for example > 88.190.222.254 ? > > >>> 2/ misconfigured security rules on your sonicwall not allowing the >>> traffic. >> >> No security rules have been set up, only the basic network configuration >> has been carried out so far to get the device onto the network. >> > > But perhaps there are default values that would block things ? > > >>>> and this works fine as I can access webmail on port 444. But why can't I >>>> access the Sonicwall on port 444? Does anyone know if the Sonicwall uses >>>> additional ports or has anyone got this device to with with a PF-based >>>> firewall? >>>> >>>> Thanks in advance for any suggestions, >>>> >>> >>> I would advise you change your RDR rule to a NAT rule, so that traffic >>> will be seen coming from the PF's interface (choose which) and the >>> sonicwall will have a direct connection with this network. >> >> I'm not an expert on PF so will need to read up on this - is it simply a >> case or replacing 'RDR' with 'NAT' in the existing rule? I must also be >> careful not to make any changes that may affect anything else on the >> internal network as this would be catastrophic for the organisation >> concerned (it's a remote site). >> > > See if you can change the sonicwall's HTTPS port to 444, then set up a > NAT rule like this: > > nat pass on $extif inet proto tcp from any to $extif port 444 -> > ($internal_if) > > This should do the trick nicely. > > Later on, you'll be able to refine the nat rule a bit to only allow > trusted IPs to connect to your sonicwall. Thank you for all your helpful suggestions - I am collecting the Sonicwall VPN device from the remote location next Wednesday and will try the above rules and suggestions with an identical spare firewall I have here. Once it's all working here I'll take the Sonicwall back to the customer's site and update the firewall rules there and make sure they work. I'm not sure the Sonicwall can be configured to use port 444 - its configuration options are quite limited and accessible only through a web interface (which uses frames, meaning I can't use the lynx text browser installed on the firewall to configure it remotely). I'll post my progress with this here next week. Thanks again for your help, it is much appreciated. Andy From owner-freebsd-pf@FreeBSD.ORG Fri Mar 25 22:30:14 2011 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9DD5106566B for ; Fri, 25 Mar 2011 22:30:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C91DF8FC08 for ; Fri, 25 Mar 2011 22:30:14 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p2PMUEu8006108 for ; Fri, 25 Mar 2011 22:30:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p2PMUEJM006105; Fri, 25 Mar 2011 22:30:14 GMT (envelope-from gnats) Date: Fri, 25 Mar 2011 22:30:14 GMT Message-Id: <201103252230.p2PMUEJM006105@freefall.freebsd.org> To: freebsd-pf@FreeBSD.org From: =?UTF-8?Q?Marcin_Wi=C5=9Bnicki?= Cc: Subject: Re: kern/148260: [pf] [patch] pf rdr incompatible with dummynet X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?UTF-8?Q?Marcin_Wi=C5=9Bnicki?= List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 22:30:14 -0000 The following reply was made to PR kern/148260; it has been noted by GNATS. From: =?UTF-8?Q?Marcin_Wi=C5=9Bnicki?= To: bug-followup , adg Cc: Subject: Re: kern/148260: [pf] [patch] pf rdr incompatible with dummynet Date: Fri, 25 Mar 2011 22:52:22 +0100 How about a more generic solution: Add new mbuf tag PACKET_TAG_PFIL_RESUME_FROM that contains address of a function registered with pfil_add_hook (ipfw_check_hook in this case) and modify pfil_run_hooks() to skip all hooks until that one (if such tag is present). Before reinjecting packet into ip_output by dummynet, prepend this m_tag to mbuf (also strip that tag if it ever comes back?). I don't know if mbuf api allows it but such tag could theoretically have just one instance (created on dummynet module load) to avoid allocation costs. This way you don't have to put ugly workaround in every pfil consumer. From owner-freebsd-pf@FreeBSD.ORG Sat Mar 26 16:35:03 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1671B106564A for ; Sat, 26 Mar 2011 16:35:03 +0000 (UTC) (envelope-from leslie@eskk.nu) Received: from mx1.bjare.net (mx1.bjare.net [212.31.160.3]) by mx1.freebsd.org (Postfix) with ESMTP id 8A18D8FC12 for ; Sat, 26 Mar 2011 16:35:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mx1.bjare.net (Postfix) with ESMTP id D502A5E131 for ; Sat, 26 Mar 2011 17:17:55 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mx1.bjare.net X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mx1.bjare.net ([127.0.0.1]) by localhost (mx1.bjare.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id tixsWMkIZdcK for ; Sat, 26 Mar 2011 17:17:53 +0100 (CET) X-BN-MX1: ja X-BN-MailInfo: BjareNet Received: from bljbsd01.no-ip.org (c-195-216-040-164.static.bjare.net [195.216.40.164]) by mx1.bjare.net (Postfix) with ESMTP id 5E8525E133 for ; Sat, 26 Mar 2011 17:17:53 +0100 (CET) Message-ID: <4D8E11CB.2070501@eskk.nu> Date: Sat, 26 Mar 2011 17:18:19 +0100 From: Leslie Jensen User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; sv-SE; rv:1.9.2.15) Gecko/20110307 Thunderbird/3.1.9 MIME-Version: 1.0 To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Lost in rules! X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 16:35:03 -0000 Hello list. I've had a machine running Freebsd 7.2-RELEASE as a firewall and Squid proxy server on a network with 10 pc behind it for some years. Now I've got some new hardware and have installed Freebsd 8.2-RELEASE with exactly the same set-up. My problem is that PF is not acting the same. Everything is blocked, if I remove the first rule "block in log on $ext_if all" I get some functionality but it won't redirect the traffic to Squid for example. I've been trying to fix it but I need some new eyes to help me. Below are the pf.conf on the new 8.2 machine and further below is the original pf.conf from the 7.2 system I'm aware that there has been some changes to the pf syntax, but when doing pfctl -n -f /etc/pf.conf there's no indication that my syntax is wrong. Will you Please take a look and see if you can see what's wrong. Thank you :-) /Leslie My new pf.conf --------------------------------------------------------------- # # macros ext_if="xl0" int_if="bfe0" tcp_services="{ 22, 993, 5910:5917 }" tcp_priv_services="{ 389, 443 }" proxy_services = "{ 21, 80 }" icmp_types="{ echoreq unreach squench timex }" internal_net = "172.17.0/16" proxy = "127.0.0.1" vncports="{ 5900, 5901 }" # tables table persist table persist # options set block-policy return # ports are closed but can be seen set loginterface $ext_if set skip on lo0 # scrub scrub in # Testing for VNC! # Translate incoming packets' destination addresses. # As an example, redirect a TCP and UDP port to an internal machine. # rdr on $ext_if inet proto tcp from to ($ext_if) port 5910 \ # -> 172.17.0.160 port 5900 # redirect www trafic to proxy rdr on $int_if inet proto tcp from $internal_net to any port $proxy_services -> $proxy port 8080 # ext_if IP address could be dynamic, hence ($ext_if) nat on $ext_if from !($ext_if) to any -> ($ext_if) # filter rules block in log on $ext_if all block drop in log quick proto ipv6 all block drop out log quick proto ipv6 all block in log quick on $ext_if from label "ssh bruteforce" pass in log on $int_if inet proto tcp from $internal_net to $proxy port 8080 keep state pass out log on $ext_if inet proto tcp from $proxy to any port $proxy_services keep state pass out log # Let the goodguys access the machine from the outside pass in log on $ext_if inet proto tcp from to ($ext_if) port $tcp_services flags S/SA keep state # We need this for the rdr to VNC (change of portnumber) pass in on $ext_if inet proto tcp from to $internal_net port $vncports flags S/SA synproxy state # ICMP answers (traffic) needs to be passed: pass in inet proto icmp all icmp-type $icmp_types keep state # traffic must be passed to and from the internal network pass in quick on $int_if # _______________________________________________________________________ The original pf.conf -------------------------------------------------------------------------- # macros ext_if="xl0" int_if="bfe0" tcp_services="{ 22, 993, 5910:5917 }" tcp_priv_services="{ 389, 443 }" proxy_services = "{ 21, 80 }" icmp_types="echoreq" internal_net = "172.17.0/16" proxy = "127.0.0.1" # tables table persist table persist # options set block-policy return # ports are closed but can be seen set loginterface $ext_if set skip on lo0 # scrub scrub in # Testing for VNC! # Translate incoming packets' destination addresses. # As an example, redirect a TCP and UDP port to an internal machine. # rdr on $ext_if inet proto tcp from to ($ext_if) port 5910 \ # -> 172.17.0.160 port 5900 # redirect www trafic to proxy rdr on $int_if inet proto tcp from $internal_net to any port $proxy_services -> $proxy port 8080 # ext_if IP address could be dynamic, hence ($ext_if) nat on $ext_if from !($ext_if) to any -> ($ext_if) # filter rules block in log (all) block drop in log quick proto ipv6 all block drop out log quick proto ipv6 all block in log quick on $ext_if from label "ssh bruteforce" pass in log on $int_if inet proto tcp from $internal_net to $proxy port 8080 keep state pass out log on $ext_if inet proto tcp from $proxy to any port $proxy_services keep state pass out keep state # Let the goodguys access the machine from the outside pass in on $ext_if inet proto tcp from to ($ext_if) \ port $tcp_services flags S/SA keep state # We need this for the rdr to VNC (change of portnumber) pass in on $ext_if inet proto tcp from to $internal_net \ port $vncports flags S/SA synproxy state # ICMP answers (traffic) needs to be passed: # pass in inet proto icmp all icmp-type $icmp_types keep state # traffic must be passed to and from the internal network pass in quick on $int_if # From owner-freebsd-pf@FreeBSD.ORG Sat Mar 26 16:46:10 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9655F106566B for ; Sat, 26 Mar 2011 16:46:10 +0000 (UTC) (envelope-from Greg.Hennessy@nviz.net) Received: from mail1.jellyfishnet.co.uk (mail1.jellyfishnet.co.uk [93.91.20.9]) by mx1.freebsd.org (Postfix) with ESMTP id 1D73B8FC08 for ; Sat, 26 Mar 2011 16:46:09 +0000 (UTC) Received: from pemexhub01.jellyfishnet.co.uk.local (93.91.20.3) by mail1.jellyfishnet.co.uk (93.91.20.9) with Microsoft SMTP Server (TLS) id 8.1.393.1; Sat, 26 Mar 2011 16:46:14 +0000 Received: from PEMEXMBXVS02.jellyfishnet.co.uk.local ([192.168.65.37]) by pemexhub01.jellyfishnet.co.uk.local ([192.168.65.7]) with mapi; Sat, 26 Mar 2011 16:46:08 +0000 From: Greg Hennessy To: Leslie Jensen , "freebsd-pf@freebsd.org" Date: Sat, 26 Mar 2011 16:46:06 +0000 Thread-Topic: Lost in rules! Thread-Index: Acvr08zfCCUo8nFKQSSUqzzFeyfGagAAOykg Message-ID: <9E8D76EC267C9444AC737F649CBBAD903A32A37EE2@PEMEXMBXVS02.jellyfishnet.co.uk.local> References: <4D8E11CB.2070501@eskk.nu> In-Reply-To: <4D8E11CB.2070501@eskk.nu> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Subject: RE: Lost in rules! X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 16:46:10 -0000 You've enabled routing ?=20 What are the logs telling you ?=20 Change this=20 "block in log on $ext_if all" to block log all there maybe an egress block somewhere.=20 > -----Original Message----- > From: owner-freebsd-pf@freebsd.org [mailto:owner-freebsd- > pf@freebsd.org] On Behalf Of Leslie Jensen > Sent: 26 March 2011 4:18 PM > To: freebsd-pf@freebsd.org > Subject: Lost in rules! >=20 > Hello list. >=20 > I've had a machine running Freebsd 7.2-RELEASE as a firewall and Squid pr= oxy > server on a network with 10 pc behind it for some years. >=20 > Now I've got some new hardware and have installed Freebsd 8.2-RELEASE > with exactly the same set-up. >=20 > My problem is that PF is not acting the same. Everything is blocked, if I > remove the first rule "block in log on $ext_if all" I get some functional= ity but it > won't redirect the traffic to Squid for example. >=20 > I've been trying to fix it but I need some new eyes to help me. >=20 > Below are the pf.conf on the new 8.2 machine and further below is the > original pf.conf from the 7.2 system >=20 > I'm aware that there has been some changes to the pf syntax, but when > doing pfctl -n -f /etc/pf.conf there's no indication that my syntax is wr= ong. >=20 > Will you Please take a look and see if you can see what's wrong. >=20 > Thank you :-) >=20 > /Leslie >=20 >=20 >=20 > My new pf.conf > --------------------------------------------------------------- >=20 > # > # macros > ext_if=3D"xl0" > int_if=3D"bfe0" >=20 > tcp_services=3D"{ 22, 993, 5910:5917 }" > tcp_priv_services=3D"{ 389, 443 }" > proxy_services =3D "{ 21, 80 }" > icmp_types=3D"{ echoreq unreach squench timex }" > internal_net =3D "172.17.0/16" > proxy =3D "127.0.0.1" > vncports=3D"{ 5900, 5901 }" >=20 > # tables > table persist > table persist >=20 > # options > set block-policy return # ports are closed but can be seen > set loginterface $ext_if >=20 > set skip on lo0 >=20 > # scrub > scrub in >=20 > # Testing for VNC! > # Translate incoming packets' destination addresses. > # As an example, redirect a TCP and UDP port to an internal machine. > # rdr on $ext_if inet proto tcp from to ($ext_if) port 5910 \ > # -> 172.17.0.160 port 5900 >=20 > # redirect www trafic to proxy > rdr on $int_if inet proto tcp from $internal_net to any port $proxy_servi= ces - > > $proxy port 8080 >=20 > # ext_if IP address could be dynamic, hence ($ext_if) nat on $ext_if from > !($ext_if) to any -> ($ext_if) >=20 > # filter rules > block in log on $ext_if all >=20 > block drop in log quick proto ipv6 all >=20 > block drop out log quick proto ipv6 all >=20 > block in log quick on $ext_if from label "ssh bruteforce" >=20 > pass in log on $int_if inet proto tcp from $internal_net to $proxy port > 8080 keep state >=20 > pass out log on $ext_if inet proto tcp from $proxy to any port > $proxy_services keep state >=20 > pass out log >=20 > # Let the goodguys access the machine from the outside pass in log on > $ext_if inet proto tcp from to ($ext_if) port $tcp_services fl= ags > S/SA keep state >=20 > # We need this for the rdr to VNC (change of portnumber) pass in on $ext_= if > inet proto tcp from to $internal_net port $vncports flags S/SA > synproxy state >=20 > # ICMP answers (traffic) needs to be passed: > pass in inet proto icmp all icmp-type $icmp_types keep state >=20 > # traffic must be passed to and from the internal network pass in quick o= n > $int_if # >=20 > __________________________________________________________ > _____________ >=20 >=20 > The original pf.conf > -------------------------------------------------------------------------= - >=20 >=20 > # macros > ext_if=3D"xl0" > int_if=3D"bfe0" >=20 > tcp_services=3D"{ 22, 993, 5910:5917 }" > tcp_priv_services=3D"{ 389, 443 }" > proxy_services =3D "{ 21, 80 }" > icmp_types=3D"echoreq" > internal_net =3D "172.17.0/16" > proxy =3D "127.0.0.1" >=20 > # tables > table persist > table persist >=20 > # options > set block-policy return # ports are closed but can be seen > set loginterface $ext_if >=20 > set skip on lo0 >=20 > # scrub > scrub in >=20 > # Testing for VNC! > # Translate incoming packets' destination addresses. > # As an example, redirect a TCP and UDP port to an internal machine. > # rdr on $ext_if inet proto tcp from to ($ext_if) port 5910 \ > # -> 172.17.0.160 port 5900 >=20 > # redirect www trafic to proxy > rdr on $int_if inet proto tcp from $internal_net to any port $proxy_servi= ces - > > $proxy port 8080 >=20 > # ext_if IP address could be dynamic, hence ($ext_if) nat on $ext_if from > !($ext_if) to any -> ($ext_if) >=20 > # filter rules > block in log (all) >=20 > block drop in log quick proto ipv6 all >=20 > block drop out log quick proto ipv6 all >=20 > block in log quick on $ext_if from label "ssh bruteforce" >=20 > pass in log on $int_if inet proto tcp from $internal_net to $proxy port > 8080 keep state >=20 > pass out log on $ext_if inet proto tcp from $proxy to any port > $proxy_services keep state >=20 > pass out keep state >=20 > # Let the goodguys access the machine from the outside pass in on $ext_if > inet proto tcp from to ($ext_if) \ port $tcp_services flags S/= SA > keep state >=20 > # We need this for the rdr to VNC (change of portnumber) pass in on $ext_= if > inet proto tcp from to $internal_net \ port $vncports flags S/= SA > synproxy state >=20 > # ICMP answers (traffic) needs to be passed: > # pass in inet proto icmp all icmp-type $icmp_types keep state >=20 > # traffic must be passed to and from the internal network pass in quick o= n > $int_if # >=20 >=20 > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" From owner-freebsd-pf@FreeBSD.ORG Sat Mar 26 17:14:37 2011 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03CD5106564A; Sat, 26 Mar 2011 17:14:37 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CF64A8FC0A; Sat, 26 Mar 2011 17:14:36 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p2QHEanD075585; Sat, 26 Mar 2011 17:14:36 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p2QHEaAb075581; Sat, 26 Mar 2011 17:14:36 GMT (envelope-from linimon) Date: Sat, 26 Mar 2011 17:14:36 GMT Message-Id: <201103261714.p2QHEaAb075581@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-pf@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/155945: [pf] [ip6] pf match engine is broken with ipv6 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 17:14:37 -0000 Old Synopsis: pf match engine is broken with ipv6 New Synopsis: [pf] [ip6] pf match engine is broken with ipv6 Responsible-Changed-From-To: freebsd-bugs->freebsd-pf Responsible-Changed-By: linimon Responsible-Changed-When: Sat Mar 26 17:13:45 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=155945 From owner-freebsd-pf@FreeBSD.ORG Sat Mar 26 18:43:50 2011 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13C20106566C; Sat, 26 Mar 2011 18:43:50 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DFFE98FC18; Sat, 26 Mar 2011 18:43:49 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p2QIhn3U056957; Sat, 26 Mar 2011 18:43:49 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p2QIhnw2056953; Sat, 26 Mar 2011 18:43:49 GMT (envelope-from remko) Date: Sat, 26 Mar 2011 18:43:49 GMT Message-Id: <201103261843.p2QIhnw2056953@freefall.freebsd.org> To: eugene@zhegan.in, remko@FreeBSD.org, freebsd-pf@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/155945: [pf] [ip6] pf match engine is broken with ipv6 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 18:43:50 -0000 Synopsis: [pf] [ip6] pf match engine is broken with ipv6 State-Changed-From-To: open->feedback State-Changed-By: remko State-Changed-When: Sat Mar 26 18:39:38 UTC 2011 State-Changed-Why: >From the quick look I did, I can see it matches rule 107. It continues parsing till it does no longer finds something that matches, which is 107 in this case. >From what I know proto ipv6 is not the same as proto inet6, where proto ipv6 means for me the tunnel that I have to sixxs.net while inet6 is the native ipv6 communication. So you may want to consider changing rule 128 to do the thing you want it to do. Can you get back to me to tell whether this works or not? Thanks, Remko http://www.freebsd.org/cgi/query-pr.cgi?pr=155945 From owner-freebsd-pf@FreeBSD.ORG Sat Mar 26 20:00:21 2011 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66080106566B for ; Sat, 26 Mar 2011 20:00:21 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3F2A78FC16 for ; Sat, 26 Mar 2011 20:00:21 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p2QK0KRA019629 for ; Sat, 26 Mar 2011 20:00:20 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p2QK0KSG019628; Sat, 26 Mar 2011 20:00:20 GMT (envelope-from gnats) Date: Sat, 26 Mar 2011 20:00:20 GMT Message-Id: <201103262000.p2QK0KSG019628@freefall.freebsd.org> To: freebsd-pf@FreeBSD.org From: "Eugene M. Zheganin" Cc: Subject: Re: kern/155945: [pf] [ip6] pf match engine is broken with ipv6 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Eugene M. Zheganin" List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 20:00:21 -0000 The following reply was made to PR kern/155945; it has been noted by GNATS. From: "Eugene M. Zheganin" To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/155945: [pf] [ip6] pf match engine is broken with ipv6 Date: Sun, 27 Mar 2011 00:12:22 +0500 Yes, I does. Thank you. So, does this mean it's not a bug ? To be honest, I fugured out this solution by myself a few hours earlier. In my defense I should say that is referenced in pf.conf manual page only 2 times (for the whole article) and it's quite difficult to fugure out that thing by myself. Earlier I encountered similar problem with ipfw, which was even weirder (you have to put proto ipv6 at the end of the rule, where it means 'inner proto', but not at the beginning of the rule, where it means something different). I think at least documentation should be made more clear. Sorry for your time; thanks for the answer. Eugene. From owner-freebsd-pf@FreeBSD.ORG Sat Mar 26 23:34:55 2011 Return-Path: Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9187F106566C for ; Sat, 26 Mar 2011 23:34:55 +0000 (UTC) (envelope-from remko@elvandar.org) Received: from mailgate.jr-hosting.nl (mailgate.jr-hosting.nl [IPv6:2a01:4f8:63:1281::3]) by mx1.freebsd.org (Postfix) with ESMTP id 33F568FC13 for ; Sat, 26 Mar 2011 23:34:55 +0000 (UTC) Received: from [10.0.2.10] (46-129-9-181.dynamic.upc.nl [46.129.9.181]) by mailgate.jr-hosting.nl (Postfix) with ESMTPSA id 8EBDB1CC28; Sun, 27 Mar 2011 00:34:53 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Remko Lodder In-Reply-To: <201103262000.p2QK0KSG019628@freefall.freebsd.org> Date: Sun, 27 Mar 2011 00:34:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201103262000.p2QK0KSG019628@freefall.freebsd.org> To: "Eugene M. Zheganin" X-Mailer: Apple Mail (2.1084) Cc: freebsd-pf@FreeBSD.org Subject: Re: kern/155945: [pf] [ip6] pf match engine is broken with ipv6 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 23:34:55 -0000 Dear Eugene, On Mar 26, 2011, at 9:00 PM, Eugene M. Zheganin wrote: > The following reply was made to PR kern/155945; it has been noted by = GNATS. >=20 > From: "Eugene M. Zheganin" > To: bug-followup@FreeBSD.org > Cc: =20 > Subject: Re: kern/155945: [pf] [ip6] pf match engine is broken with = ipv6 > Date: Sun, 27 Mar 2011 00:12:22 +0500 >=20 > Yes, I does. > Thank you. You are welcome ofcourse! >=20 > So, does this mean it's not a bug ? No, it's not a bug. > To be honest, I fugured out this solution by myself a few hours = earlier. :-) good work then! > In my defense I should say that is referenced in pf.conf manual=20= > page only 2 times (for the whole article) and it's quite difficult to=20= > fugure out that thing by myself. Earlier I encountered similar problem=20= > with ipfw, which was even weirder (you have to put proto ipv6 at the = end=20 > of the rule, where it means 'inner proto', but not at the beginning of=20= > the rule, where it means something different). I dont know IPFW, but I do understand PF a fair bit. Most recently (in = the last few days) I added a SIXXS.net tunnel to my PFsense box, and well it needs IPV6 = connectivity through PF.. so I was kinda cheating because I knew what meant what ;) >=20 > I think at least documentation should be made more clear. If it is not clear enough it might be an idea to get it more clear. The = problem on our end is that it's contributed code, from OpenBSD (by Daniel Hartmeier) and that = if we are to modify it locally, we potentially generate a lot of fuzz when someone imports a = newer version, which is what Ermal is currently doing (with Bjoern if I can recall = correctly). So, we need to get this upstream if it is really unclear/needed. Are there others that confirm this? >=20 > Sorry for your time; thanks for the answer. No problem, my time wasn't wasted, because it helped you! That's the = great thing about the community, as long as it helps people, we don't mind :-) Cheers REmko >=20 > Eugene. > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" >=20 --=20 /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | X http://www.evilcoder.org/ | Quis custodiet ipsos custodes / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-pf@FreeBSD.ORG Sat Mar 26 23:59:59 2011 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 132F9106566B; Sat, 26 Mar 2011 23:59:59 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DFB028FC13; Sat, 26 Mar 2011 23:59:58 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p2QNxwxh035325; Sat, 26 Mar 2011 23:59:58 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p2QNxwfH035321; Sat, 26 Mar 2011 23:59:58 GMT (envelope-from remko) Date: Sat, 26 Mar 2011 23:59:58 GMT Message-Id: <201103262359.p2QNxwfH035321@freefall.freebsd.org> To: eugene@zhegan.in, remko@FreeBSD.org, freebsd-pf@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: kern/155945: [pf] [ip6] pf match engine is broken with ipv6 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 23:59:59 -0000 Synopsis: [pf] [ip6] pf match engine is broken with ipv6 State-Changed-From-To: feedback->closed State-Changed-By: remko State-Changed-When: Sat Mar 26 23:59:58 UTC 2011 State-Changed-Why: Eugene reported that that my feedback indeed resolved the problem. This might be due to lack of documentation from the upstream vendor, we will investigate together whether that is needed or not, but this is no longer a real problem. http://www.freebsd.org/cgi/query-pr.cgi?pr=155945