On Fri, Nov 20, 2020 at 2:52 PM Chris Schanzle <chris.schanzle at nist.gov> wrote: > > On 11/20/20 2:31 PM, Michael B Allen wrote: > > On Fri, Nov 20, 2020 at 2:06 PM Michael B Allen <ioplex at gmail.com> wrote: > >> Apparently I don't know how to do "that" because this: > >> > >> # iptables -A INPUT -p tcp --sport 760 -m conntrack --ctstate > >> NEW,ESTABLISHED -j ACCEPT > >> > >> still doesn't allow the traffic through (not that I would want to > >> allow an --sport rule anyway but I'd just like to confirm that this > >> traffic is indeed responsible). What am I doing wrong here? I've also > >> tried simpler rules without conntrack or cstate but it's still not > >> getting through. > >> > >> Incidentally I added kerberos and kadmin firewalld services without > >> effect either. > > Well I've managed to resolve the issue but I'm not entirely satisfied > > with the solution. Apparently firewalld and iptables are at least > > partially mutually exclusive such that changes to iptable have no > > effect. If I add a Source Port rule using the Firewalld GUI to allow > > source port 760, it resolves the issue. But it seems pretty dubious to > > allow traffic from any particular source port. The service using port > > 760 is krbupdate but there isn't a lot of information about it on the > > net. It doesn't look like destination ports are a range because they > > have changed from 41285 and 46167. There must be something on the > > CentOS 7 side broadcasting info about what ports to use. What a PITA. > > I can't log into a desktop with an nfs home dir without punching a > > reverse hole in my firewall? That shouldn't be. 99% of people will > > just drop the pants on their machine. > > > > Mike > > You didn't state what version of NFS you're using. We're still on nfsv3. What you're describing looks like an issue with locked. Thanks for the inputs but my problem has nothing to do with NFS. Mike