dhclient[486]: send_packet: Permission denied

Morris

Morris

I am getting endless reports in my syslog about the DHCP client that is denied permission to send a packet.

Code: 
Apr 12 09:27:21 [hostname] dhclient[486]: send_packet: Permission denied
Apr 12 09:33:17 [hostname] syslogd: last message repeated 1 times
Apr 12 09:38:18 [hostname] syslogd: last message repeated 1 times
Apr 12 09:47:39 [hostname] syslogd: last message repeated 3 times
Apr 12 09:56:00 [hostname] syslogd: last message repeated 8 times
Apr 12 10:07:14 [hostname] syslogd: last message repeated 5 times
Apr 12 10:17:50 [hostname] syslogd: last message repeated 6 times
Apr 12 10:27:41 [hostname] syslogd: last message repeated 13 times
Apr 12 10:38:09 [hostname] syslogd: last message repeated 20 times
Apr 12 10:48:09 [hostname] syslogd: last message repeated 11 times
Apr 12 10:56:49 [hostname] syslogd: last message repeated 3 times
Apr 12 11:06:45 [hostname] syslogd: last message repeated 1 times
Apr 12 11:12:44 [hostname] syslogd: last message repeated 1 times
Apr 12 11:26:52 [hostname] syslogd: last message repeated 2 times
Apr 12 11:37:28 [hostname] syslogd: last message repeated 4 times
Apr 12 11:42:03 [hostname] syslogd: last message repeated 1 times
Apr 12 11:49:41 [hostname] syslogd: last message repeated 1 times
Apr 12 12:06:34 [hostname] syslogd: last message repeated 7 times
Apr 12 12:18:36 [hostname] syslogd: last message repeated 19 times

etc. etc.

This is on a host in a VM where the provider gives me a fixed IPv4, a fixed IPv6 (/64) and a block of /48 of IPv6. I don't know if my VM picks the address up via DHCP or not but it does run three DHCP client processes.

Code: 
547 _dhcp         1  20    0    12M  2384K select   0:03   0.00% dhclient
489 root          1  39    0    11M  2360K select   0:02   0.00% dhclient
486 root          1  20    0    11M  2220K select   0:01   0.00% dhclient

This is my ifconfig output (with some anonymization), the bridge is there for the purposes of iocage:
Code: 
vtnet0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=6c03bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
    ether XX:XX:XX:XX:XX:XX
    inet6 fe80::5054:ff:xxxx:xxxx%vtnet0 prefixlen 64 scopeid 0x1
    inet6 2a01:7c8:xxxx:xxx:xxxx:xx:xxxx:xxxx prefixlen 64 deprecated autoconf
    inet 37.xx.xxx.xxx netmask 0xffffff00 broadcast 37.xx.xxx.255
    media: Ethernet 10Gbase-T <full-duplex>
    status: active
    nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
    options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
    inet6 ::1 prefixlen 128
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
    inet 127.0.0.1 netmask 0xff000000
    groups: lo
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    ether 02:a5:2b:ac:25:00
    id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
    maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
    root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
    member: vtnet0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
            ifmaxaddr 0 port 1 priority 128 path cost 2000
    groups: bridge
    nd6 options=9<PERFORMNUD,IFDISABLED>
pflog0: flags=141<UP,RUNNING,PROMISC> metric 0 mtu 33160
    groups: pflog

I have found some old posts suggesting the DHCP client wants to do a broadcast but is not allowed to (by PF? by some ACLs?) but also reports that that was caused by a bug that has since been fixed. That would explain why I don't see many recent reports. But why am I now seeing this? Have I misconfigured something?
 
I'm not sure what exactly you want to know. I rent a VPS from a hoster (which claims to run KVM with ZFS) and in that VPS I run FreeBSD 12.1 Release P3. FreeBSD 12 is one of the OS-es they offer so their install script comes with basic configurations to fit their system I suppose. I then updated FreeBSD 12.0 to 12.1 using FreeBSD-update.

The ifconfig I shared is from the VPS, not a jail.

I don't use the VPS firewall the hoster offers but I run a pf that I configured myself instead:
Code: 
#### MACRO SECTION
ext_if = "vtnet0" # external interface
int_if = "lo0"  # internal interface
public_ip = "{" $ext_if "}" # this machine public IP (IPv4 and IPv6)
local_ip = $int_if:0 # home


# ssh: ssh connections
# www: the http services
# domain: DNS resolution
# ntp: the ntp daemon
in_tcp_services_restricted = "{ ssh }" # only for in rules (restrictive)
in_tcp_services = "{ http, https }" # only for in rules (non restrictive)
out_tcp_services = "{ ssh, http, https, domain }" # only for out rules
out_udp_services = "{ domain, ntp }" # only out rules

# only ping and traceroute ICMP messages allowed
# unreach allow to probe for MTU discovery
icmp_types = "{ echoreq, unreach }"

# specific ICMP for IPv6
icmp6_types = "{ toobig, echoreq, routersol, routeradv, neighbradv, neighbrsol }"

#### TABLE SECTION
# ssh bruteforce protection (table definition)
table <bruteforce> persist

# MARTIANS
# non-routables addresses as defined by standards
table <martians> const { 127.0.0.0/8 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8 \
  169.254.0.0/16 192.0.2.0/24 0.0.0.0/8 240.0.0.0/4 255.255.255.255/32 \
  ::/128 ::1/128 ::ffff:0:0/96 ::/96 100::/64 2001:10::/28 2001:db8::/32 \
  fc00::/7 fe80::/10 fec0::/10 ff00::/8 }

#### OPTIONS SECTION
# Enabling scrub provides a measure of protection against certain kinds of attacks
# based on incorrect handling of packet fragments
scrub in all

#### RULE SECTION
# block all traffic by default
# THIS MUST BE THE FIRST RULE
block log all

# The antispoof mechanism protects against activity from spoofed or forged IP
# addresses, mainly by blocking packets appearing on interfaces and in directions
# which are logically not possible.
antispoof log quick for $ext_if
antispoof log for $int_if # no quick, we need internal for ntp

# block non-routables addresses (quick: immediate effect, no further rules checked)
# only ext_if because we use "martians" in loopback interface (it's correct)
block drop in log quick on $ext_if from <martians> to any
block drop out log quick on $ext_if from any to <martians>

# block anything coming from source we have no back routes for
# block packets whose ingress interface does not match the one the route back to
# their source address
block in log quick from {no-route urpf-failed} to any

# rule to block bruteforce on all connections (both in and out)
# quick: if the rule apply, no other rules are checked!
block log quick from <bruteforce>
block log quick from <fail2ban>

# max-src-conn is the number of simultaneous connections allowed from one host.
# max-src-conn-rate is the rate of new connections allowed from any single host
#                    per number of seconds (4 connection every 30 seconds).
# overload <bruteforce> means that any host which exceeds these limits gets its
# address added to the bruteforce table. The ruleset blocks all traffic from
# addresses in the bruteforce table. Finally, flush global says that when a host
# reaches the limit, that all (global) of that host's connections will be terminated (flush).
#
pass in on $ext_if inet proto tcp from any to $public_ip port $in_tcp_services_restricted \
    flags S/SA keep state \
    (max-src-conn 8, max-src-conn-rate 4/30, \
    overload <bruteforce> flush global)

pass in on $ext_if inet6 proto tcp from any to $public_ip port $in_tcp_services_restricted \
    flags S/SA keep state \
    (max-src-conn 8, max-src-conn-rate 4/30, \
    overload <bruteforce> flush global)

# HTTP and HTTPS (no bruteforce check)
pass in on $ext_if inet proto tcp from any to $public_ip port $in_tcp_services keep state
pass in on $ext_if inet6 proto tcp from any to $public_ip port $in_tcp_services keep state

# allows connections created by this system to pass out, while retaining state
# information on those connections. This state information allows return traffic
# for those connections to pass back and should only be used on machines that can be trusted.
# we allow only the specified services
pass out on $ext_if inet proto tcp from $public_ip to any port $out_tcp_services keep state # out only
pass out on $ext_if inet6 proto tcp from $public_ip to any port $out_tcp_services keep state # out only
pass out on $ext_if inet proto udp from $public_ip to any port $out_udp_services keep state # out only
pass out on $ext_if inet6 proto udp from $public_ip to any port $out_udp_services keep state # out only

# allow ntpq for local interface
pass on $int_if inet proto udp from $local_ip to $local_ip port ntp
pass on $int_if inet6 proto udp from $local_ip to $local_ip port ntp

# ICMP
# allow only specified icmp_types (both in and out)
pass on $ext_if inet proto icmp all icmp-type $icmp_types keep state
pass on $ext_if inet6 proto icmp6 all icmp6-type $icmp6_types keep state

# allow out the default range for traceroute(8):
pass out on $ext_if inet proto udp from $public_ip to any port 33433 >< 33626 keep state # out only
pass out on $ext_if inet6 proto udp from $public_ip to any port 33433 >< 33626 keep state # out only
Does this answer your question?
 
SirDice said:
Look in rc.conf and see how your interfaces are configured.
Click to expand...
The IPs are fixed for the VPS (I can see them in the control panel) but they are picked up by DHCP and RA, apparently:
Code: 
ifconfig_vtnet0="DHCP"
ifconfig_vtnet0_ipv6="inet6 accept_rtadv"

SirDice said:
Yes, DHCP is blocked by your firewall rules.
Click to expand...
OK, strange that I never had this problem until not too long ago. Perhaps the update to 12.1 changed something.

Is this indeed a broadcast attempt by the DHCP client? Should I just allow that on the local network in my pf.conf?
 
I'm guessing it manages to request an IP address just before the firewall is loaded. What's being blocked is probably the renewal attempts. Those are likely failing, but if the renewal fails it's still going to keep the address. At least until the lease time expires (which could be a long time). In any case, DHCP is a little more involved than just a broadcast.

Dynamic Host Configuration Protocol - Wikipedia

en.wikipedia.org en.wikipedia.org
 
OK, I've added the following to the firewall:
Code: 
# allow DHCP in and out
pass in on $ext_if inet proto udp from port = 68 to port = 67
pass out on $ext_if inet proto udp from port = 67 to port = 68

I thought it was fixed as it had gone quiet but no, it's back.

Code: 
Apr 15 11:31:42 ApBeau1 dhclient[515]: send_packet: Permission denied
Apr 15 11:32:08 ApBeau1 syslogd: last message repeated 3 times
Apr 15 11:33:40 ApBeau1 syslogd: last message repeated 3 times
etc.

Considering it had gone quiet suggests that it is indeed an attempt to renew the DHCP lease. What I don't get is why the error says 'Permission denied'. If it had been a firewall issue, should those packets not just be blocked and the DHCP client never receive a response?

The 'Permission' element suggests to me that it happens before it can even send a packet for a firewall to block. As if the DHCP user has no rights to send packets.
 
I'm facing the same problem.
FreeBSD 12.1
In my case I'm using IPFW.

I can't find any message in /var/log/security about this block.
I think is not the firewall rules.


Code: 
Apr  5 20:36:34 dhclient[569]: send_packet: Permission denied
Apr  5 20:38:45 syslogd: last message repeated 1 times
Apr  5 20:40:10 syslogd: last message repeated 1 times
Apr  5 20:45:38 syslogd: last message repeated 2 times
 
You must log in or register to reply here.
Back
Top