Re: (ipfw) Re: HELP! fetch: stuck forever OR error: RPC failed: curl 56 recv failure: Operation timed out

From: FreeBSD User <freebsd_at_walstatt-de.de>
Date: Mon, 09 Dec 2024 16:45:14 UTC
Am Mon, 9 Dec 2024 21:43:14 +0900
Tomoaki AOKI <junchoon@dec.sakura.ne.jp> schrieb:

> On Mon, 9 Dec 2024 11:09:14 +0100
> Juraj Lutter <otis@FreeBSD.org> wrote:
> 
> > > On 8 Dec 2024, at 20:30, Ronald Klop <ronald@FreeBSD.org> wrote:
> > > 
> > > Hi,
> > > 
> > > I can reproduce your error.
> > > 
> > > A cronjob which does a scp to another server didn't work anymore. When I go back to the
> > > previous BE it works fine again. Ipfw disable firewall also makes the scp work.
> > > 
> > > Scp also seems to work fine if I replace the statefull firewall rules with stateless
> > > "pass all from any to any".  
> > 
> > Have you tried to allow ICMP in both directions explicitly, in case of stateful rules?
> > 
> > —
> > Juraj Lutter
> > otis@FreeBSD.org  
> 
> I think would usually work for clients with some limited services
> exposed to outside. IIUC, it basically allow all sessions from inside
> and allows limited serivices configured with variables
> via /etc/rc.conf[.local].
> 
> Some notes.
>   *Last actual changes in /usr/src/libexec/rc/rc.firewall was at
>    Jul.23, 2020.
>      https://github.com/freebsd/freebsd-src/commits/main/libexec/rc/rc.firewall
>        [cgit.freebsd.org seems to be unstable now.]
> 
>   *Variable firewall_logif currently does not exist.
> 
>   *Don't you need allowing 22/UDP, too, like below?
>      firewall_myservices="22/tcp 22/udp"
> 
> And if you're creating kernel config from scratch (such as copying from
> GENERIC at some point and editing it), it's no longer adviced.
> It's not robust for changes in GENERIC.
> 
> Instead, include GENERIC and describe changes you want.
> 
> An example (one of my test kernel config for a bit old stable).
> 
>    ===== Start example =====
>  
> include GENERIC
> 
> ident   TEST15
> 
> nooptions       DDB
> nooptions       GDB 
> nooptions       INVARIANTS
> nooptions       INVARIANT_SUPPORT
> nooptions       WITNESS
> nooptions       WITNESS_SKIPSPIN
> nooptions       DEADLKRES
> 
> options         CAM_IOSCHED_DYNAMIC
> 
> device          sg
> 
>    ===== End example =====
> 
> 

Thank you very much for the advice - but I do this kind of confugration now since, I guess,
2020 or 2021. consider the host's kernel name to be "THOR", then /etc/src.conf has lines

KERNCONF=       THOR
KERNCONFDIR=    /etc/config/amd64/kernel_conf/

and the target's config file "/etc/config/amd64/kernel_conf/THOR" contains

include         GENERIC
include         NODEVICE-THOR
include         "std.nodebug"
include         ADDON-THOR

This concept isn't bullet proof, since I had trouble with the relatively recent introduced
"std.nodebug". As you mentioned, NODEVICE contains ALL "nooptions" and "nodevice" and ADDON
contains some extra options not contained in GENERIC. GENERIC is a symbolic link to the
original GENERIC in the appropriate sys folder.

Thanks to FReeBSD's sophisticated kernel configuration, this hierarchical scheme prevents most
accidents triggered by significant GENERIC changes.

Do you suspect a misconfiguration due to uncaught changes in GENERIC? 

-- 
O. Hartmann