From nobody Thu Dec 30 06:08:04 2021 X-Original-To: questions@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 17105191ED82 for ; Thu, 30 Dec 2021 06:08:23 +0000 (UTC) (envelope-from kh@panix.com) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4JPd9x6x9Kz3l4l for ; Thu, 30 Dec 2021 06:08:21 +0000 (UTC) (envelope-from kh@panix.com) Received: from rain.home (pool-173-48-63-106.bstnma.fios.verizon.net [173.48.63.106]) by mailbackend.panix.com (Postfix) with ESMTPSA id 4JPd9q31DDz44WJ for ; Thu, 30 Dec 2021 01:08:15 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=panix.com; s=panix; t=1640844495; bh=WWzEFDk5sot4bsKZHW1PAWMGt7fFX8InOD8RuYt74gY=; h=Date:From:To:Subject:References:In-Reply-To; b=BIn3RH2h4z4YBIceLbhHfIbypkQfOe4Ik+Ljg77zHKlvWFsiFOwDe7vdzn0o6AV/H sGie2ojP8A6LXUB57+aaGlb2sK7xFYS4EKI2j47ETW0myESrllUti9wHcK6fLWCRHz AtW2ua6lQIZaeMp3VvspnjMt6T1rDC5USR8GPKVU= Date: Thu, 30 Dec 2021 01:08:04 -0500 From: Kurt Hackenberg To: questions@freebsd.org Subject: Re: ipfw syntax clarification Message-ID: References: <8b2c341d-10e6-51a2-0654-86f4394865c7@tundraware.com> List-Id: User questions List-Archive: https://lists.freebsd.org/archives/freebsd-questions List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8b2c341d-10e6-51a2-0654-86f4394865c7@tundraware.com> X-Rspamd-Queue-Id: 4JPd9x6x9Kz3l4l X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=panix.com header.s=panix header.b=BIn3RH2h; dmarc=none; spf=pass (mx1.freebsd.org: domain of kh@panix.com designates 166.84.1.89 as permitted sender) smtp.mailfrom=kh@panix.com X-Spamd-Result: default: False [-1.64 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[panix.com:s=panix]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[166.84.1.89:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:166.84.1.64/26]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[questions@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_NA(0.00)[panix.com]; NEURAL_SPAM_SHORT(0.86)[0.859]; DKIM_TRACE(0.00)[panix.com:+]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:2033, ipnet:166.84.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[173.48.63.106:received] X-ThisMailContainsUnwantedMimeParts: N On Wed, Dec 29, 2021 at 05:32:15PM -0600, Tim Daneliuk via freebsd-questions wrote: >We have a FBSD firewall/gateway/natd server on the permimeter of one of our networks. > >We have an ipfw table that is loaded with pesky IPs like this: > > ipfw add deny all from table\(10\) to any via ${OIF} > >This does block traffic which originates from those IPs to our server. >However, it also prevents our server from originating requests TO those IPs. > >This is an issue because some of the table entries are CIDR blocks intended >to geoblock known problem areas. However, it's sometimes desirable to, say, >connect to a web server within one of those CIDR blocks. > >How/can the rule above be modified to let no one in the table to connect or >ping to the server, but still allow the server to connect to something in >the forbidden blocks/IPs? Your browser tries to make a TCP connection to a web server in the hostile zone, but establishing that connection takes two-way communication. Blocking all incoming traffic from that outside web server makes it impossible to establish the connection. You can deny incoming TCP connections from the hostile zone, but still allow outgoing connections to it, with something like this: ipfw add pass tcp from me to table\(10\) via ${OIF} established ipfw add pass tcp from table\(10\) to me via ${OIF} established ipfw add pass tcp from me to table\(10\) via ${OIF} setup ipfw add deny all from table\(10\) to any via ${OIF} The deny-all rule will be applied only if none of the preceding ones match. Those TCP flags "setup" and "established" just match TCP messages with certain flags set; this example doesn't keep track of existing TCP connections. (ipfw can do that, with other rules, but you may not need it.) To be able to ping things in the hostile zone, you'll have to let in ICMP echo replies. What about UDP? For example, domain name lookups. You probably want to query name servers in the hostile zone, to connect to web servers there. DNS can use either TCP or UDP. Outgoing TCP connections would be covered by the example above, but UDP doesn't do connections; you'd have to handle that somewhat differently. "Me" above is just addresses on the computer where the firewall runs. If this computer routes between the local net and the world, you'd do the same firewalling of some but not all traffic between other computers on the local net and the hostile zone. And there's IPv6, which has its own version of ICMP.