Minor rpc question ....

Ian Smith smithi at nimnet.asn.au
Mon Nov 3 17:25:42 UTC 2014


In freebsd-questions Digest, Vol 544, Issue 1, Message: 7
On Sun, 02 Nov 2014 17:06:22 -0600 "William A. Mahaffey III" <wam at hiwaay.net> wrote:
 > On 11/02/14 16:43, William A. Mahaffey III wrote:
 > > On 11/02/14 11:12, Ian Smith wrote:
 > >> William, I've just seen your response at
 > >> http://lists.freebsd.org/pipermail/freebsd-questions/2014-November/262026.html 
 > >>
 > >> but as I take questions@ as a digest, I won't get it here till tomorrow
 > >> .. I should have asked you to cc me.

Just got here.  If you (or anyone) do respond to this, please cc me!

Some spring pruning:

 > >>   > 02500  18777 23476935 allow tcp from 192.168.0.0/16 to me
 > >>   > 65000   1795   424041 count ip from any to any
 > >>   > 65100   1371   269257 deny { tcp or udp } from any to any 
 > >> dst-port 111,137,138,513 in
 > >>
 > >>   > w/ port 513 obviously being denied. However, I don't know where that
 > >>   > is happening :-/ & I thought rule 02500 would let all local traffic
 > >>   > through ....

 > >> Rule 2500 only allows tcp, rwho is udp - but 2500 is a bit sweeping
 > >> anyway, perhaps best to enable specific services, even internally?
 > >>
 > >> Ah, yes - I see firewall_myservices and firewall_allowservices are only
 > >> for TCP services.  That's a strange omission, if I'm reading it right,
 > >> especially re rpc.

Well, well .. while browsing freebsd-current@ archives earlier, looking 
for something else entirely, I came across this PR with commit to HEAD: 

Bug 194292 - Patch for adding firewall_myservices_tcp and 
 firewall_myservices_udp support to rc.conf: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194292

 > >> Rather than fixing this properly now for UDP services, I'd just add into
 > >> /etc/rc.firewall after what's now your 2500 or at any rate before 65000:
 > >>
 > >> ${fwcmd} allow udp from ${mynetwork} 513 to me 513

Turns out 'me' was an unfortunate choice for this service, see below ..

 > >> You're already enabling udp services outbound, statefully, which is why
 > >> you can query other hosts.  Now they'll be able to reach you too :)
 > >>
 > >> 'service ipfw restart' and you should be good to go.  You could remove
 > >> 513 from firewall_nologports - but now it'll already be passed by then.

 > > Well, I put that rule in & opened logging for that port & now I get 
 > > ruptime info from other boxen, however, I also get log traffic about 
 > > denied port 513 traffic:
 > >
 > > [root at kabini1, /etc, 4:34:01pm] 368 % service ipfw restart
 > > net.inet.ip.fw.enable: 1 -> 0
 > > net.inet6.ip6.fw.enable: 1 -> 0
 > > Flushed all rules.
 > > 00100 allow ip from any to any via lo0
[.. as before ..]
 > > 01100 check-state
 > > 01200 allow tcp from me to any established
 > > 01300 allow tcp from me to any setup keep-state
 > > 01400 allow udp from me to any keep-state
 > > 01500 allow icmp from me to any keep-state
[..]
 > > 02500 allow tcp from 192.168.0.0/16 to me
 > > 02600 allow udp from 192.168.0.0/24 513 to me dst-port 513
[..]
 > > 65500 deny log logamount 5000 ip from any to any
 > > Firewall rules loaded.
 > > [root at kabini1, /etc, 4:34:03pm] 369 %

 > > [root at kabini1, /etc, 4:37:13pm] 337 % ( tail -20 /var/log/security ; 
 > > date )
 > > Oct 30 11:00:00 kabini1 newsyslog[9861]: logfile turned over due to 
 > > size>100K
 > > Oct 30 11:00:30 kabini1 kernel: ipfw: 65500 Deny UDP 
 > > 92.108.103.99:58507 192.168.0.27:63167 in via re0
 > > Oct 30 11:00:49 kabini1 kernel: ipfw: 65500 Deny P:2 192.168.0.27 
 > > 224.0.0.22 out via re0
 > > Oct 30 11:00:52 kabini1 kernel: ipfw: 65500 Deny P:2 192.168.0.27 
 > > 224.0.0.22 out via re0

Your box tries talking IGMP (see /etc/protocols) to a multicast port:
igmp    2       IGMP            # internet group management protocol
I know nothing about IGMP, but see there's nothing here to permit it.

 > > Oct 30 11:01:16 kabini1 kernel: ipfw: 65500 Deny UDP 126.43.5.41:6881 
 > > 192.168.0.27:63167 in via re0

Torrents, eh?  You'll need rule/s allowing that, assuming you offer 
inbound connections and that your upstream NAT router is forwarding a 
chosen port to you.  I had to do this for my daughter not long ago :) 
and in 'workstation' it's another service - UDP and perhaps TCP too? - 
that you'll need to allow inbound .. unicast, so 'me' would be ok.

[.. more IGMP ..]

 > > Oct 31 10:16:03 kabini1 kernel: ipfw: 65500 Deny UDP 216.180.99.2:53 
 > > 192.168.0.27:28277 in via re0

Likely a late response to a DNS query, not uncommon.  You can adjust the 
dynamic timeouts by sysctls if need be, see ipfw(8); the default for 
net.inet.ip.fw.dyn_udp_lifetime=5 seconds, often insufficient for DNS.

 > > Nov  2 16:31:12 kabini1 kernel: ipfw: 65500 Deny UDP 192.168.0.4:513 
 > > 192.168.0.255:513 in via re0
 > > Nov  2 16:32:25 kabini1 kernel: ipfw: 65500 Deny UDP 192.168.0.9:513 
 > > 192.168.0.255:513 in via re0
 > > Nov  2 16:32:28 kabini1 kernel: ipfw: 65500 Deny UDP 192.168.0.7:513 
 > > 192.168.0.255:513 in via re0
 > > Nov  2 16:34:12 kabini1 kernel: ipfw: 65500 Deny UDP 192.168.0.4:513 
 > > 192.168.0.255:513 in via re0
 > > Nov  2 16:35:25 kabini1 kernel: ipfw: 65500 Deny UDP 192.168.0.9:513 
 > > 192.168.0.255:513 in via re0
 > > Nov  2 16:35:28 kabini1 kernel: ipfw: 65500 Deny UDP 192.168.0.7:513 
 > > 192.168.0.255:513 in via re0
 > > Nov  2 16:37:12 kabini1 kernel: ipfw: 65500 Deny UDP 192.168.0.4:513 
 > > 192.168.0.255:513 in via re0
 > > Nov  2 16:38:25 kabini1 kernel: ipfw: 65500 Deny UDP 192.168.0.9:513 
 > > 192.168.0.255:513 in via re0

Right .. all of these are to 192.168.0.255, the broadcast address for
that /24.  'me' is defined as any address configured on an interface on 
the system .. so apparently 'me' doesn't include the broadcast address,
assuming ifconfig shows you have re0 configured as 192.168.0.27/24 with 
that broadcast address?

 > > Sun Nov  2 16:38:26 CST 2014
 > > [root at kabini1, /etc, 4:38:26pm] 337 %
 > >
 > > [wam at kabini1, ~, 9:03:43am] 330 % ruptime -a
 > > Q6600                      up 299+08:00,     6 users,  load 0.03, 
 > > 0.04, 0.05
 > > athloncube                 up  45+21:08,     4 users,  load 0.00, 
 > > 0.01, 0.05
 > > kabini1                    up     23:01,     1 user,   load 0.35, 
 > > 0.19, 0.10
 > > opty165a                   up 299+08:00,     4 users,  load 0.00, 
 > > 0.00, 0.00
 > > [wam at kabini1, ~, 4:34:49pm] 330 % ruptime
 > > Q6600                    down      0:13
 > > athloncube               down      0:14
 > > kabini1                    up     23:07,     0 users,  load 0.21, 
 > > 0.26, 0.16
 > > opty165a                 down      0:13
 > > [wam at kabini1, ~, 4:41:57pm] 331 % ruptime -a
 > > Q6600                    down      0:13
 > > athloncube               down      0:14
 > > kabini1                    up     23:07,     1 user,   load 0.21, 
 > > 0.26, 0.16
 > > opty165a                 down      0:13
 > > [wam at kabini1, ~, 4:42:03pm] 332 %
 > >
 > >
 > > err, well, I had it for a second :-/ ....

I think your outbound queries (yes, to 192.168.0.255) got responses due 
to the stateful UDP rule at 1400, but later, when you weren't querying 
directly, other systems' broadcast queries were not being allowed in.

 > Sooooo tacky to self reply, but it seems warranted here. Using the ipfw 
 > command:
 > 
 > ${fwcmd} add pass udp from 192.168.0.0/24 513 to 192.168.0.0/24 513
 > 
 > gets ruptime traffic in/out *and* cuts out extraneous logging .... Just 
 > for posterity :-) ....

Yes that does it, because it allows packets in to the broadcast address. 
Sorry I misled you with that 'me' rule; I didn't consider broadcasts, 
even while knowing that's how rwhod has always worked :)  I've rarely 
used 'me', preferring to use specific addresses (including broadcast)

cheers, Ian


More information about the freebsd-questions mailing list