From owner-freebsd-pf@FreeBSD.ORG Sun Feb 10 18:46:31 2013 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BD23F59D for ; Sun, 10 Feb 2013 18:46:31 +0000 (UTC) (envelope-from tyler@tysdomain.com) Received: from tds-solutions.net (tds-solutions.net [69.164.206.65]) by mx1.freebsd.org (Postfix) with ESMTP id 87AC5CCD for ; Sun, 10 Feb 2013 18:46:31 +0000 (UTC) Received: by tds-solutions.net (Postfix, from userid 5002) id B9797A063; Sun, 10 Feb 2013 11:46:30 -0700 (MST) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on wuff X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 Received: from [192.168.1.101] (host-184-166-35-152.gdj-co.client.bresnan.net [184.166.35.152]) (Authenticated sender: tyler) by tds-solutions.net (Postfix) with ESMTPSA id 52278A007 for ; Sun, 10 Feb 2013 11:46:29 -0700 (MST) Message-ID: <5117EB02.70105@tysdomain.com> Date: Sun, 10 Feb 2013 11:46:26 -0700 From: "Littlefield, Tyler" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-pf@freebsd.org Subject: initial pf configuration Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Feb 2013 18:46:31 -0000 hello: This is my initial pf configuration. I'd like to make sure it's ok. Also, if there's anything else I could do better, I would like to know. This is for a single public server running two servers--ssh and my mud. if="em0" tcp_services="{ 22 6666}" set block-policy drop set skip on lo set loginterface $if set ruleset-optimization profile set skip on lo scrub in on $if all fragment reassemble block in all antispoof quick for { $if lo } pass out from any to any pass in on $if proto tcp from any to any port $tcp_services synproxy state -- Take care, Ty http://tds-solutions.net The aspen project: a barebones light-weight mud engine: http://code.google.com/p/aspenmud He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave. From owner-freebsd-pf@FreeBSD.ORG Mon Feb 11 11:06:49 2013 Return-Path: Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B2D8A2CA for ; Mon, 11 Feb 2013 11:06:49 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id A4CE31BD5 for ; Mon, 11 Feb 2013 11:06:49 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r1BB6npk081369 for ; Mon, 11 Feb 2013 11:06:49 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r1BB6nTM081367 for freebsd-pf@FreeBSD.org; Mon, 11 Feb 2013 11:06:49 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 11 Feb 2013 11:06:49 GMT Message-Id: <201302111106.r1BB6nTM081367@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 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.14 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, 11 Feb 2013 11:06:49 -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/173659 pf [pf] PF fatal trap on 9.1 (taskq fatal trap on pf_test o bin/172888 pf [patch] authpf(8) feature enhancement o kern/172648 pf [pf] [ip6]: 'scrub reassemble tcp' breaks IPv6 packet o kern/171733 pf [pf] PF problem with modulate state in [regression] o kern/169630 pf [pf] [patch] pf fragment reassembly of padded (undersi o kern/168952 pf [pf] direction scrub rules don't work o kern/168190 pf [pf] panic when using pf and route-to (maybe: bad frag o kern/166336 pf [pf] kern.securelevel 3 +pf reload o kern/165315 pf [pf] States never cleared in PF with DEVICE_POLLING o kern/164402 pf [pf] pf crashes with a particular set of rules when fi o kern/164271 pf [pf] not working pf nat on FreeBSD 9.0 [regression] o kern/163208 pf [pf] PF state key linking mismatch o kern/160370 pf [pf] Incorrect pfctl check of pf.conf 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/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/134996 pf [pf] Anchor tables not included when pfctl(8) is run w o kern/133732 pf [pf] max-src-conn issue o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st 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/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/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/103283 pf pfsync fails to sucessfully transfer some sessions 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 48 problems total. From owner-freebsd-pf@FreeBSD.ORG Thu Feb 14 18:12:18 2013 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id ED7F6716 for ; Thu, 14 Feb 2013 18:12:18 +0000 (UTC) (envelope-from 34.24.34@gmail.com) Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by mx1.freebsd.org (Postfix) with ESMTP id B9090336 for ; Thu, 14 Feb 2013 18:12:18 +0000 (UTC) Received: by mail-qe0-f45.google.com with SMTP id b4so1198941qen.4 for ; Thu, 14 Feb 2013 10:12:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=IoSK6motiZTW7lXCoDTYXiVkm/4+HU/ERbt0OywDNzQ=; b=OTvC0wMso2nWFy1Osx3VTQhVSKTAulZO1bxJHyZNiCAkaJ+arLiOMzTU8zxqPvJzEJ Ge0Ph8UNZKaqO9d3uSfZnqqRXCv5Ikv9uzSuyZlsaWZE0+gjYCUsh4/EmWenWR5dBKrO yhfYCXJE8esojot4Et5Nez2h+wNROXKVFVre47QrYWhYVA+i3e5eYULkD9kQW2JG4nPp pHxl6KzIPY5a8S46mxvqGMCOF5fO8lDDLEFtVB6K/clerTMhUbaPUfpxMYSl1dNPTWb3 KYVO4+bFXnng5YgjUOtGk4b85MKkbBQMqf0B9UDMUQu3za4U2wdd8pfY/A+JUvvfw8Ig P14Q== MIME-Version: 1.0 X-Received: by 10.49.118.38 with SMTP id kj6mr12006855qeb.53.1360865182998; Thu, 14 Feb 2013 10:06:22 -0800 (PST) Received: by 10.49.86.130 with HTTP; Thu, 14 Feb 2013 10:06:22 -0800 (PST) Date: Thu, 14 Feb 2013 18:06:22 +0000 Message-ID: Subject: Releasing all outgoing ports for a particular IP. From: Lisa Muir <34.24.34@gmail.com> To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.14 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: Thu, 14 Feb 2013 18:12:19 -0000 Hi Guys, Hope you might be able to help me with a query. Am a little past the newbie stage with pf, and moderately comfortable with it, but by no means a guru yet, finding my way. Have one firewall which has a public interface with multiple ip's and 5 private lans with the usual private lan space ip's. The machine has been running fine for a year and a bit, and I have various port forwarding things going, internal redirection for dmz hosts being accessed from the lan, port forwarding for public ip aliases's on the external interface. Two things have left me with questions, one is about UDP port forwarding which I got working but am not 100% happy with, and I'll come back to that in another thread, and today's one which is releasing all tcp ports for a particular IP which is in the "DMZ" vlan. In this case, the vlans are implemented at the switches, and a seperate interface on the pf firewall links into each vlan, no kernel based vlan in operation. As a rule, we restrict outgoing ports, we only allow out what we know about and approve, but we're putting in a CCTV transmitter into the DMZ which requires access to every tcp port for outgoing. Here is a cut down version of my pf.conf with the relevant data, starting with the definitions for interfaces, the host in question that I am testing with, and the ports: ##################### # Definitions # # interfaces # Vlan1 is the switch management vlan vlan1_if = "em1" # Vlan2 is the business vlan vlan2_if = "em2" # Vlan3 is the topsec secretary vlan vlan3_if = "em3" # Vlan4 is the "dmz" vlan4_if = "em4" # Vlan5 is the domestic house vlan vlan5_if = "em5" # Wlan is the wireless lan in the building wlan_if = "msk0" # The em0 vlan is a direct cat-5 cable link to wireless broadband kit for public internet ext_if = "em0" # The em0_alias0 is a virtual interface for additional public ip stc_dvr_ext_if = "173.47.184.4" tunnel_if = "gif0" vpn_if = "tun0" # Host that we are testing our rules with emailserver = "10.168.3.99" # Ports that we want to open for this host, all tcp going out all_ports = "{ 1:65535 }" The lans, 1, 2, 3, wireless and are restricted to only trafficing on ports such as 80, 443, 25, 587, 143 etc. But I want my email server to go out on any port, so the following lines were added, which work: pass in on $vlan4_if proto tcp from $emailserver to any port $all_ports pass out on $ext_if proto tcp from $ext_if to any port $all_ports The first line of that is suitably restrictive, it only allows that one single host in the DMZ to traffic out on all tcp ports. its the next pass rule that bothers me. Because all lans nat through to the ext_if, this next line effectively opens up all ports to get out into the wild if any of them are accidently opened to get into the gateway. I'd like to be able to restrict that particular pass rule to a single host. Is that possible? or do I just have to live with the fact that I have it restricted at the pass in stage? When i get more info, I may be able to restrict the outgoing destination to a list of ip's rather than passing out to any, which will help tighten the rule up, but it seems a little unrestricted for my liking as is. Lisa. From owner-freebsd-pf@FreeBSD.ORG Thu Feb 14 18:22:38 2013 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 17D2BA59 for ; Thu, 14 Feb 2013 18:22:38 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) by mx1.freebsd.org (Postfix) with ESMTP id A3FB83C5 for ; Thu, 14 Feb 2013 18:22:37 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id dq12so2093699wgb.0 for ; Thu, 14 Feb 2013 10:22:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=97+q2Hu+35ibE0obqY0ledM/NNbWLJRe2KrtfUqlaKQ=; b=mIpqJ9bEB0hQPzY0GUQvQWZi7qKNt+EXgySoXRNhKpbHs6uOU1oczwuak/SsbF2Gfr gP19y+6K4SDG8LnNZWSQWKhHkeMWx08An/1wKljJvahn+M64oWLRE5gmKfqaDMR9F1fD KkUJrqCeG9HXX+s/xI7NMoGJjRIJpuctgfxERmJYUBESkKsHQxGyDywdt9obHFLKukW9 kfeb1ctbvn4Rjv6HNiPqgF2GKepr5hJwpWluFKvwCFEPHRP7AOObfwaztn1DMCX786Q9 h0VsDom1KJtsUzkKniVKT1ljnxpIbWJC13zouUoU8vR0swH3oitWc/W27mzIY/XI3dQ9 0ucA== X-Received: by 10.194.103.163 with SMTP id fx3mr35687594wjb.58.1360866156294; Thu, 14 Feb 2013 10:22:36 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id fg6sm889334wib.10.2013.02.14.10.22.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Feb 2013 10:22:35 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Releasing all outgoing ports for a particular IP. From: Fleuriot Damien In-Reply-To: Date: Thu, 14 Feb 2013 19:22:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <48514518-3109-4BFE-8AB0-B93C694168F2@my.gd> References: To: Lisa Muir <34.24.34@gmail.com> X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQmMc/0Z0kvLbQbY7jAjoz98ZMXF9KP6wwRBDK3BYMUkit1aKET4XWk+YyOjUqrdXDuEdA7C Cc: freebsd-pf@freebsd.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.14 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: Thu, 14 Feb 2013 18:22:38 -0000 On Feb 14, 2013, at 7:06 PM, Lisa Muir <34.24.34@gmail.com> wrote: > Hi Guys, >=20 > Hope you might be able to help me with a query. Am a little past the > newbie stage with pf, and moderately comfortable with it, but by no > means a guru yet, finding my way. >=20 > Have one firewall which has a public interface with multiple ip's and > 5 private lans with the usual private lan space ip's. The machine has > been running fine for a year and a bit, and I have various port > forwarding things going, internal redirection for dmz hosts being > accessed from the lan, port forwarding for public ip aliases's on the > external interface. Two things have left me with questions, one is > about UDP port forwarding which I got working but am not 100% happy > with, and I'll come back to that in another thread, and today's one > which is releasing all tcp ports for a particular IP which is in the > "DMZ" vlan. In this case, the vlans are implemented at the switches, > and a seperate interface on the pf firewall links into each vlan, no > kernel based vlan in operation. >=20 > As a rule, we restrict outgoing ports, we only allow out what we know > about and approve, but we're putting in a CCTV transmitter into the > DMZ which requires access to every tcp port for outgoing. Here is a > cut down version of my pf.conf with the relevant data, starting with > the definitions for interfaces, the host in question that I am testing > with, and the ports: >=20 > ##################### > # Definitions > # > # interfaces >=20 > # Vlan1 is the switch management vlan > vlan1_if =3D "em1" >=20 > # Vlan2 is the business vlan > vlan2_if =3D "em2" >=20 > # Vlan3 is the topsec secretary vlan > vlan3_if =3D "em3" >=20 > # Vlan4 is the "dmz" > vlan4_if =3D "em4" >=20 > # Vlan5 is the domestic house vlan > vlan5_if =3D "em5" >=20 > # Wlan is the wireless lan in the building > wlan_if =3D "msk0" >=20 > # The em0 vlan is a direct cat-5 cable link to wireless broadband kit > for public internet > ext_if =3D "em0" >=20 > # The em0_alias0 is a virtual interface for additional public ip > stc_dvr_ext_if =3D "173.47.184.4" >=20 > tunnel_if =3D "gif0" > vpn_if =3D "tun0" >=20 > # Host that we are testing our rules with > emailserver =3D "10.168.3.99" >=20 > # Ports that we want to open for this host, all tcp going out > all_ports =3D "{ 1:65535 }" >=20 >=20 >=20 > The lans, 1, 2, 3, wireless and are restricted to only trafficing on > ports such as 80, 443, 25, 587, 143 etc. >=20 > But I want my email server to go out on any port, so the following > lines were added, which work: >=20 >=20 > pass in on $vlan4_if proto tcp from $emailserver to any port = $all_ports > pass out on $ext_if proto tcp from $ext_if to any port $all_ports >=20 >=20 >=20 > The first line of that is suitably restrictive, it only allows that > one single host in the DMZ to traffic out on all tcp ports. >=20 > its the next pass rule that bothers me. Because all lans nat through > to the ext_if, this next line effectively opens up all ports to get > out into the wild if any of them are accidently opened to get into the > gateway. I'd like to be able to restrict that particular pass rule to > a single host. >=20 > Is that possible? or do I just have to live with the fact that I have > it restricted at the pass in stage? >=20 > When i get more info, I may be able to restrict the outgoing > destination to a list of ip's rather than passing out to any, which > will help tighten the rule up, but it seems a little unrestricted for > my liking as is. >=20 > Lisa. I think what you want to do is not possible in this way, people more = experienced will correct me if needed. Perhaps you could try adjusting your outgoing NAT rules however ? Example: nat on $ext_if inet proto tcp from $emailserver to any nat on $ext_if inet proto tcp from $dmz:network to any port { 80 443 25 = 465 =85 } nat on $ext_if inet proto udp from $dmz:network to any port { 53 =85 } See the approach here ? Your packets from hosts other than the emailserver (which effectively = has access to everything over TCP) won't go through. Now, why do you bother with "ports $all_ports" at all ? Just use: pass in on $vlan4_if proto tcp from $emailserver to any Next, if you only use ipv4 you might want to use the "inet" keyword in = your rules, as such: pass in on $vlan4_if inet proto =85 Last, unless you have specific reasons not to, why not make use of the = "quick" keyword so that PF stops processing rules right where you want ? pass in quick on $vlan4_if inet proto tcp=85 I hope this helps. From owner-freebsd-pf@FreeBSD.ORG Thu Feb 14 20:04:40 2013 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7CD26C41 for ; Thu, 14 Feb 2013 20:04:40 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 49B84A7C for ; Thu, 14 Feb 2013 20:04:40 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U652t-000Led-2C; Thu, 14 Feb 2013 15:04:39 -0500 Date: Thu, 14 Feb 2013 15:04:38 -0500 From: Gary Palmer To: Lisa Muir <34.24.34@gmail.com> Subject: Re: Releasing all outgoing ports for a particular IP. Message-ID: <20130214200438.GA85777@in-addr.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: freebsd-pf@freebsd.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.14 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: Thu, 14 Feb 2013 20:04:40 -0000 On Thu, Feb 14, 2013 at 06:06:22PM +0000, Lisa Muir wrote: > Hi Guys, > > Hope you might be able to help me with a query. Am a little past the > newbie stage with pf, and moderately comfortable with it, but by no > means a guru yet, finding my way. > > Have one firewall which has a public interface with multiple ip's and > 5 private lans with the usual private lan space ip's. The machine has > been running fine for a year and a bit, and I have various port > forwarding things going, internal redirection for dmz hosts being > accessed from the lan, port forwarding for public ip aliases's on the > external interface. Two things have left me with questions, one is > about UDP port forwarding which I got working but am not 100% happy > with, and I'll come back to that in another thread, and today's one > which is releasing all tcp ports for a particular IP which is in the > "DMZ" vlan. In this case, the vlans are implemented at the switches, > and a seperate interface on the pf firewall links into each vlan, no > kernel based vlan in operation. > > As a rule, we restrict outgoing ports, we only allow out what we know > about and approve, but we're putting in a CCTV transmitter into the > DMZ which requires access to every tcp port for outgoing. Here is a > cut down version of my pf.conf with the relevant data, starting with > the definitions for interfaces, the host in question that I am testing > with, and the ports: > > ##################### > # Definitions > # > # interfaces > > # Vlan1 is the switch management vlan > vlan1_if = "em1" > > # Vlan2 is the business vlan > vlan2_if = "em2" > > # Vlan3 is the topsec secretary vlan > vlan3_if = "em3" > > # Vlan4 is the "dmz" > vlan4_if = "em4" > > # Vlan5 is the domestic house vlan > vlan5_if = "em5" > > # Wlan is the wireless lan in the building > wlan_if = "msk0" > > # The em0 vlan is a direct cat-5 cable link to wireless broadband kit > for public internet > ext_if = "em0" > > # The em0_alias0 is a virtual interface for additional public ip > stc_dvr_ext_if = "173.47.184.4" > > tunnel_if = "gif0" > vpn_if = "tun0" > > # Host that we are testing our rules with > emailserver = "10.168.3.99" > > # Ports that we want to open for this host, all tcp going out > all_ports = "{ 1:65535 }" > > > > The lans, 1, 2, 3, wireless and are restricted to only trafficing on > ports such as 80, 443, 25, 587, 143 etc. > > But I want my email server to go out on any port, so the following > lines were added, which work: > > > pass in on $vlan4_if proto tcp from $emailserver to any port $all_ports > pass out on $ext_if proto tcp from $ext_if to any port $all_ports > > > > The first line of that is suitably restrictive, it only allows that > one single host in the DMZ to traffic out on all tcp ports. > > its the next pass rule that bothers me. Because all lans nat through > to the ext_if, this next line effectively opens up all ports to get > out into the wild if any of them are accidently opened to get into the > gateway. I'd like to be able to restrict that particular pass rule to > a single host. > > Is that possible? or do I just have to live with the fact that I have > it restricted at the pass in stage? > > When i get more info, I may be able to restrict the outgoing > destination to a list of ip's rather than passing out to any, which > will help tighten the rule up, but it seems a little unrestricted for > my liking as is. Hi Lisa, I believe you should look at PF tags. If you tag the traffic coming in with the pass in on $vlan4_if proto tcp from $emailserver to any port $all_ports rule, you should then be able to use that in our ext_if rule to ensure only those packets are let out e.g. pass in on $vlan4_if proto tcp from $emailserver to any port $all_ports tag MAILSERVER pass out quick on $ext_if tagged MAILSERVER Regards, Gary From owner-freebsd-pf@FreeBSD.ORG Thu Feb 14 20:56:32 2013 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D7A4C642; Thu, 14 Feb 2013 20:56:32 +0000 (UTC) (envelope-from 34.24.34@gmail.com) Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) by mx1.freebsd.org (Postfix) with ESMTP id 676AED89; Thu, 14 Feb 2013 20:56:31 +0000 (UTC) Received: by mail-qe0-f54.google.com with SMTP id 1so1270558qeb.41 for ; Thu, 14 Feb 2013 12:56:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=zgkVOZ+cjnYMjCUc5RFbuGddSyGQfCQ9ifBJaiug7io=; b=obeXFZvkbgLLCqTqozH55v6WvDJZsXdTOtcHfjmgP7beVvEM5X5yQLBQCEo4f9H//M ZELxhCCULVnomjnd1Dyn0Losp0DXU7dkS2w/0G5akQ1qNaELXSvvolY4849CBEqh6BYR TcsmXuXoFc6HSzZpNc1B9S1jRe984ukVjcHQ0lvbh7bVAGZcKpjIQJZYELLi6etaPZFe hU6/Mp0uxe7XUCy/Z+J7Ykdf0jQlab/7KIfmHIGCY+lZjPSiAQJQgy/ZffyK6S5IFlS+ cxymcaMb0N05prtXG5FxBt5qAGpp+aGLN04iIGBu6Cm9GinzsL2lci2JE0ZkgoHhmB2g SJKQ== MIME-Version: 1.0 X-Received: by 10.229.69.24 with SMTP id x24mr12054qci.16.1360875391250; Thu, 14 Feb 2013 12:56:31 -0800 (PST) Received: by 10.49.86.130 with HTTP; Thu, 14 Feb 2013 12:56:31 -0800 (PST) In-Reply-To: <20130214200438.GA85777@in-addr.com> References: <20130214200438.GA85777@in-addr.com> Date: Thu, 14 Feb 2013 20:56:31 +0000 Message-ID: Subject: Re: Releasing all outgoing ports for a particular IP. From: Lisa Muir <34.24.34@gmail.com> To: Gary Palmer Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-pf@freebsd.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.14 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: Thu, 14 Feb 2013 20:56:32 -0000 On Thu, Feb 14, 2013 at 8:04 PM, Gary Palmer wrote: > Hi Lisa, > > I believe you should look at PF tags. If you tag the traffic coming in with > the > > pass in on $vlan4_if proto tcp from $emailserver to any port $all_ports > > rule, you should then be able to use that in our ext_if rule to ensure > only those packets are let out > > e.g. > > pass in on $vlan4_if proto tcp from $emailserver to any port $all_ports tag MAILSERVER > pass out quick on $ext_if tagged MAILSERVER excellent.... exactly what I was hoping for... and might even solve my UDP dilemma. I have CC_UDP = "{15000:15200}" and then a redirect rule: rdr on $ext_if proto udp from any to $ext_if port $CC_UDP -> $lm_laptop and then a pass rule to let it through: pass quick proto udp from any to any port $CC_UDP My initial instinct was to confine the pass rule from any to $lm_laptop but the packets don't forward, presumably because UDP is connectionless and bar the forward, there is nothing in the UDP packets that specifies an ip based destination. I'm going to try tagging these packets also and see if I can refine the pass rule accordingly. Big thanks for this heads up. Lisa.