From nobody Mon Nov 18 12:23:20 2024 X-Original-To: freebsd-net@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 4XsRcN54ccz5d2v7; Mon, 18 Nov 2024 12:23:32 +0000 (UTC) (envelope-from driesm@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R10" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XsRcN4Yp0z4P9b; Mon, 18 Nov 2024 12:23:32 +0000 (UTC) (envelope-from driesm@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1731932612; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ICqCu9eiIYL6I02QhnOF7a8dyulG4HVSXPTG0X6Ejk0=; b=am+LGQOvcIbFsss4a121aUYiJyL2fFLyYrk/9i4psUJLakEYUJfaxuo0wakG1bDUGDc04l rY07J3RyO5KnzX0HlmnGPXC2eXGlYg4VTl9fbq4rcEJ0eKlgL9JuoPA7O4zXagTGLBSi28 EXORNLkpZD4uCXpnKms0ZYRfNN/cOh4wuXxEMP4kG1IgD7IShsU59cgwUvz5fa4TBIfoTT r1qWUx2xF/nktwhpyS7KntiAqm4nx0PjazxB4ahAqETZgND2KagCHxbwyLopLGEQM4jtcN MT0TOZTR/84ucthlET9/ii4C0p/OUao21rZYpJtwMyVS1I974Fs26zxkH4pQwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1731932612; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ICqCu9eiIYL6I02QhnOF7a8dyulG4HVSXPTG0X6Ejk0=; b=eSLmAN0aGgrgCTmTHdPaeAtF+CtITxBuCpFnRRb+vdOhgy8DhKPBZWxBXvPD2UYjiC+b67 PBWe2J2ywXT7agKIT2i0fA/wB1WgcEuNYL1cqTr95K+RHv1YBCnvsusalhrSRqD5zTNqQ8 wLFUaerEhgkieMt/xaHmHSVKZ8V5ZTmtfLzPBjIkqAzRqLZNRwdFgdXxTyNjULuYP3fXi+ rvvfKcYf5GAwVkUU4/HBLdVs6asASIeQ/6UIJz1TDY/P+qvV9h8VMZtRCd0GUidXOvZSmR sZFMU1MxaxAR9Vdcmqjdihod/PK3f7Pap1O/Cxrzl9x+2Bw6qYX65uFi0Usc3g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1731932612; a=rsa-sha256; cv=none; b=rtBM3eq65fUake+Qk1m6gZY5rAZ2uLsgFdTiTDxtgc6ZVdeYW1eotRfImJt0hKvKSRzex8 BX49vrkQKVQtrXRR1gzeXOCSUzW+l/ph9227fvkQgInFESfF6Fag8Hu2ZCt12mUo/ScIXx /x/MFfwLfzleZn8tp46Ek0L0YVBfOCsYZfJVA0jpLcxnNWclPHcxz8CpBQMBrBY4qbzWk4 gzzGO0XqymJHYE42lecgk70z6UmGBaXb2G5r1H/+EoHE+XlDvBt3btF2Fmtmv8fwp4IxJ/ 9DpR9Iqhk+GMPOJkWIU9RCiQSQS/sE4eXzdIy9ef8gH2r2eEetDNjyXmuCeFkQ== Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) (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 "WR4" (verified OK)) (Authenticated sender: driesm) by smtp.freebsd.org (Postfix) with ESMTPSA id 4XsRcN42HMzypW; Mon, 18 Nov 2024 12:23:32 +0000 (UTC) (envelope-from driesm@freebsd.org) Received: by mail-ot1-f41.google.com with SMTP id 46e09a7af769-718186b5c4eso878455a34.2; Mon, 18 Nov 2024 04:23:32 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCU/x2KKRhaGKRxx6V+GYyultf7gBvEA+6BbADJ9CNROHnEq1VKl7Df9DD5V8wl36CQXEPjm+Ue2ArVFQA==@freebsd.org, AJvYcCV9aAbfqZPLhQMeMo//ynxUID+GGYUMoNzxD376P37wU8GKaHZZs4hFlTri/aunnen4KWp+QHyRHbP2rQ==@freebsd.org X-Gm-Message-State: AOJu0YxkYI8/gogwmA95QiQ5ReenDHeQ7jscznVZTukIhAyaSZZ+ykz2 GdKkTKloCGt5yexDTlHxVeggsYfgbBX3YFkxBpChqEs+hFohQhAayM1LKRSGle5hUL1VvfJvdK3 3l7wtoYa57a35gGcJxKq8vcteMB4= X-Google-Smtp-Source: AGHT+IGCaPGSf0cMinAISwUPL3x/XlQwgxJtGo7VmZF/Q02eKcsgx9AyoO1JCsuZUe3vURstv+4B5AmeDh5oUDFwnsg= X-Received: by 2002:a05:6830:620a:b0:718:4073:428f with SMTP id 46e09a7af769-71a7798c242mr10051027a34.16.1731932611861; Mon, 18 Nov 2024 04:23:31 -0800 (PST) List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org MIME-Version: 1.0 References: <610cbd98-0e4c-474f-b352-9786fc9e6a70@FreeBSD.org> In-Reply-To: <610cbd98-0e4c-474f-b352-9786fc9e6a70@FreeBSD.org> From: Dries Michiels Date: Mon, 18 Nov 2024 13:23:20 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: IPFW statefull firewall ruleset - some sites or applications do not work as expected To: Ronald Klop Cc: freebsd-ipfw@freebsd.org, freebsd-pf@freebsd.org, FreeBSD Net Content-Type: multipart/alternative; boundary="0000000000001aef6306272efcc2" --0000000000001aef6306272efcc2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, unfortunately that's not the case, as I have onepass to off, meaning that after every rule, the packet continues to be processed by the next rule (so the NAT does get reached). Op do 14 nov 2024 om 11:17 schreef Ronald Klop : > Op 02-11-2024 om 16:30 schreef Dries Michiels: > > Hello, > > > > So I have a very basic ruleset, as described in the FreeBSD handbook, > see below. I have "blurred" my open ports as seen in the ruleset below. > > Igc0 is my WAN port and in the table "trusted_if" are like my LAN if an= d > some bridges. > > > > 00001 reass ip from any to any in > > 00010 allow ip from any to any via table(trustedif) > > 00050 deny log ip from any to any not antispoof in > > 00100 nat 1 ip4 from any to any in recv igc0 > > 00500 skipto 10000 tcp from any to any out xmit igc0 setup keep-state > :default > > 00501 skipto 10000 udp from any to any out xmit igc0 keep-state :defaul= t > > 05000 allow tcp from any to me *some open ports* in recv igc0 setup > keep-state :default > > 05001 allow udp from any to me *some open ports* in recv igc0 keep-stat= e > :default > > 09998 deny log tcp from any to any > > 09999 deny log udp from any to any > > 10000 nat 1 ip4 from any to any out xmit igc0 > > 65535 allow ip from any to any > > > > Now comes the tricky part. There are some applications that don't work > correctly with this ruleset. > > For example, itsme (belgium application) to identify yourself with a lo= t > of accounts, does not work. > > Recently my banking website also stopped working. So now I'm wondering > how do I start to troubleshoot this issue? > > Are there any ceavets with this ruleset when redirects are happening fo= r > example? I'm also wondering if Belgian PF users have the same issue?=C2= =A3 > > > > I'm hopeful to get to the bottom of this as its quite annoying needing > to switch wifi channels to my ISP's router which does work with these > applications. > > > > Regards > > Dries > > > > > > Hi, > > It is a while ago that I build ipfw firewalls, but doesn't rule 10 match > all internal (from LAN) traffic, preventing outgoing (to WAN) packets to > get to the nat rules? > > I would suggest something like this: > > 00001 reass ip from any to any in > 00050 deny log ip from any to any not antispoof in > 00100 nat 1 ip4 from any to any via igc0 > 00300 check-state :default > 00200 allow ip from any to any in table(trustedif) keep-state :default > 05000 allow tcp from any to me *some open ports* in recv igc0 setup > keep-state :default > 05001 allow udp from any to me *some open ports* in recv igc0 keep-state > :default > 09999 deny log ip from any to any > 65535 allow ip from any to any > > > > Regards, > Ronald. > > --0000000000001aef6306272efcc2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, unfortunately=C2=A0that's not the case, as I have = onepass to off, meaning that after every rule, the packet continues to be p= rocessed=C2=A0by the next rule (so the NAT does get reached).


Op do 14 nov 2024 om 11:17 schreef Ronald Klop <ronald@freebsd.org>:
Op 02-11-2024 om 16:30 schreef Dries Michiels: > Hello,
>
> So I have a very basic ruleset, as described in the FreeBSD handbook, = see below. I have "blurred" my open ports as seen in the ruleset = below.
> Igc0 is my WAN port and in the table "trusted_if" are like m= y LAN if and some bridges.
>
> 00001 reass ip from any to any in
> 00010 allow ip from any to any via table(trustedif)
> 00050 deny log ip from any to any not antispoof in
> 00100 nat 1 ip4 from any to any in recv igc0
> 00500 skipto 10000 tcp from any to any out xmit igc0 setup keep-state = :default
> 00501 skipto 10000 udp from any to any out xmit igc0 keep-state :defau= lt
> 05000 allow tcp from any to me *some open ports* in recv igc0 setup ke= ep-state :default
> 05001 allow udp from any to me *some open ports* in recv igc0 keep-sta= te :default
> 09998 deny log tcp from any to any
> 09999 deny log udp from any to any
> 10000 nat 1 ip4 from any to any out xmit igc0
> 65535 allow ip from any to any
>
> Now comes the tricky part. There are some applications that don't= =C2=A0work correctly with this ruleset.
> For example, itsme (belgium application) to identify yourself with a l= ot of accounts, does not=C2=A0work.
> Recently my banking=C2=A0website also stopped working. So now I'm = wondering how do I start to troubleshoot=C2=A0this issue?
> Are there any ceavets=C2=A0with this ruleset when redirects are happen= ing for example? I'm also wondering if Belgian PF users have the same i= ssue?=C2=A3
>
> I'm hopeful=C2=A0to get to the bottom of this as its quite annoyin= g needing to switch wifi channels to my ISP's router which does work wi= th these applications.
>
> Regards
> Dries
>
>

Hi,

It is a while ago that I build ipfw firewalls, but doesn't rule 10 matc= h all internal (from LAN) traffic, preventing outgoing (to WAN) packets to = get to the nat rules?

I would suggest something like this:

00001 reass ip from any to any in
00050 deny log ip from any to any not antispoof in
00100 nat 1 ip4 from any to any via igc0
00300 check-state :default
00200 allow ip from any to any in table(trustedif) keep-state :default
05000 allow tcp from any to me *some open ports* in recv igc0 setup keep-st= ate :default
05001 allow udp from any to me *some open ports* in recv igc0 keep-state :d= efault
09999 deny log ip from any to any
65535 allow ip from any to any



Regards,
Ronald.

--0000000000001aef6306272efcc2--