From nobody Thu Dec 30 06:32:20 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 E14381923F50 for ; Thu, 30 Dec 2021 06:32:57 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JPdkK4hpzz3r2x for ; Thu, 30 Dec 2021 06:32:57 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: by mail-lj1-x231.google.com with SMTP id k27so39106770ljc.4 for ; Wed, 29 Dec 2021 22:32:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tenebras-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lAnXtRvR18D3PbTUcL74AmxbGruN5KNV99kzR3zVFLs=; b=b6ohoc6XfCRc5Z9MqFfe+V25m3SfOzngZ0yZk7lvXXmcFa77MgegfuVVFF252u1pjR t2PN3ACLa7P4rAgfMgEeul3hKmdgJ/7zz6MCOwYFM/1GKyt+l6QyYZf+23uidfzYxv/A WW4+zVwdi12mXj4/0DqNT8J0iop1R5WvhHK2qfsdjottpsOhDYb4TaJerDyJkqPGHxYE SBNEHiQivD+EoGWUR7H6iJP+GPOjsSQkNDanRG7yP4+Pp5wRQdPGLokLqIfi2+Uvz20Y 0e7l7EQd+ch4M3Ai6ZzBeKBlgC0odjFn28yfKw+rtSoYsa9hDF5xcivexVIGjdG5/4Dd pVNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lAnXtRvR18D3PbTUcL74AmxbGruN5KNV99kzR3zVFLs=; b=AlNgWRQajWfBHu8EYhmx4I1SbFJ8/p/CKWWfEeczSXrWm6xzqZ4cMpihSSJKqK12nY s82gVtdJlalQEKzNGdryY3WZIYKDd4qFsQTlAA3aaMzr8RrOVC/SfNwJKsUKioI3JLPN RJ3axcxMJnDLgLQlxT+VhagBVuZpKyDinrXmf7bxaU8Uzu5GBQYUlIOjikDhS6rkyovS YlLVANVr6WkUw1UHQkC4ctJfB+ku+W0m94TgOesnu8DWEKiO5aSKZExlts7l1v/XIP2D AEhhlqFIGC76MvAEvIsG5zmQ1vA25TkF4WgKvA2rV09Dl6d0ss93C67RUxX19xf1JeQ9 MOEA== X-Gm-Message-State: AOAM532LYieFxFeiO1iSZPd3dE/ore/k7ydwDyzDZCdeCJ5W11+fYEuB 5ROW7ay2fJdCVRBYg9VBKATTL+K3A2QtsoQkH+6VYQ== X-Google-Smtp-Source: ABdhPJy5Dxno3ey7RhWG2PzLmu3bqUhw1zCEWwv0bIMgnLdUo8faZAelwrikd1gZMDEP2DnZ6ZngVRTai2BXC7t20Tw= X-Received: by 2002:a2e:83cd:: with SMTP id s13mr25752940ljh.373.1640845976190; Wed, 29 Dec 2021 22:32:56 -0800 (PST) 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 References: <8b2c341d-10e6-51a2-0654-86f4394865c7@tundraware.com> In-Reply-To: From: Michael Sierchio Date: Wed, 29 Dec 2021 22:32:20 -0800 Message-ID: Subject: Re: ipfw syntax clarification To: Kurt Hackenberg Cc: "questions@FreeBSD.org" Content-Type: multipart/alternative; boundary="0000000000008ae09205d45739f1" X-Rspamd-Queue-Id: 4JPdkK4hpzz3r2x X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --0000000000008ae09205d45739f1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 29, 2021 at 10:08 PM Kurt Hackenberg wrote: > 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 i= n > >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} > You don't want to permit any traffic from the bad IPs that aren't part of a stateful rule. Not accounting for NAT (which makes things a little more complicated, but still entirely feasible): $FW add 00500 check-state :gb $FW add deny ip from table\(reject\) to any in recv $WAN ... $FW add allow tcp from any to any out xmit $WAN setup keep-state :gb $FW add allow udp from any to any out xmit $WAN keep-state :gb $FW add allow icmp from any to any out xmit $WAN keep-state :gb $FW add allow ip6 from any to any out xmit $WAN setup keep-state :gb proto tcp $FW add allow ip6 from any to any out xmit $WAN keep-state :gb proto udp $FW add allow ipv6-icmp from any to any out xmit $WAN keep-state :gb To the OP: there are no geoblocks of CIDR addresses =E2=80=93 they don't r= eally exist. You can block NL, for example, but that includes addresses in the Antilles. There are addresses that belong in the FR blocks that are in North America (Saint-Pierre et Miquelon). Actual location of IP addresses is something known to the CDNs (Akamai, Cloudflare, AWS, etc.) and is somewhat proprietary. --0000000000008ae09205d45739f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Dec 29, 2021 at 10:08 PM Kurt= Hackenberg <kh@panix.com> wrote:=
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:
>
>=C2=A0 =C2=A0ipfw add deny all from table\(10\) to any via ${OIF}
>
>This does block traffic which originates from those IPs to our server.<= br> >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 inte= nded
>to geoblock known problem areas.=C2=A0 However, it's sometimes desi= rable 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 connec= t 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.=C2=A0 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:

=C2=A0 =C2=A0 ipfw add pass tcp from me to table\(10\) via ${OIF} establish= ed
=C2=A0 =C2=A0 ipfw add pass tcp from table\(10\) to me via ${OIF} establish= ed
=C2=A0 =C2=A0 ipfw add pass tcp from me to table\(10\) via ${OIF} setup
=C2=A0 =C2=A0 ipfw add deny all from table\(10\) to any via ${OIF}

You don't want to permit any traffic from t= he bad IPs that aren't part of a stateful rule.=C2=A0

Not= accounting for NAT (which makes things a little more complicated, but stil= l entirely feasible):

$FW add 00500 che= ck-state :gb

$FW add=C2= =A0 =C2=A0 =C2=A0 =C2=A0deny ip from table\(reject\) to any in recv $WAN

...

$FW add =C2=A0 =C2=A0 =C2=A0 allow t= cp from any to any out xmit $WAN setup keep-state :gb

$FW add =C2=A0 =C2=A0 =C2=A0 allow u= dp from any to any out xmit $WAN keep-state :gb

$FW add =C2=A0 =C2=A0 =C2=A0 allow i= cmp from any to any out xmit $WAN keep-state :gb


$FW add =C2=A0 =C2=A0 =C2=A0 allow i= p6 from any to any out xmit $WAN setup keep-state :gb proto tcp

$FW add =C2=A0 =C2=A0 =C2=A0 allow i= p6 from any to any out xmit $WAN keep-state :gb proto udp

$FW add =C2=A0 =C2=A0 =C2=A0 allow i= pv6-icmp from any to any out xmit $WAN keep-state :gb

=

To the OP:=C2=A0 there are no geoblocks of C= IDR addresses =E2=80=93 they don't really exist.=C2=A0 You can block NL= , for example, but that includes addresses in the Antilles.=C2=A0 There are= addresses that belong in the FR blocks that are in North America (Saint-Pi= erre et Miquelon).=C2=A0 Actual location of IP addresses is something known= to the CDNs (Akamai, Cloudflare, AWS, etc.) and is somewhat proprietary.


--0000000000008ae09205d45739f1--