# How to see who disables rule 65535



## pavlar (Mar 4, 2020)

I had a  connection with the server by ssh with a delay.I rebooted the server. Entry appeared on line 65535. Communication by ssh is good

```
65535      27       1359 Wed Mar  4 08:01:36 2020 deny ip from any to any
```


----------



## Bobi B. (Mar 4, 2020)

That is probably the default rule for ipfw(8): search for `65535`.

The delay is usually caused by reverse DNS resolve by the sshd(8). What does w(1) shows as `FROM`? Is it a host name or an IP address?


----------



## pavlar (Mar 4, 2020)

I would like to find out who(what service) sends these  27       1359 ? If IPFW repels them, then they carry some kind of threat. These entries appear only after a system reboot (12.1-RELEASE-p2 ). Or is it a bug of IPFW?


----------



## xtaz (Mar 4, 2020)

Add a rule above it numbered something like 65534 which says deny log ip from any to any. Then it will log anything that hits that rule and you can see what it is. As that rule will always be hit before the 65535 one.

It could well be packets it receives during the time when ipfw first loads from the kernel or kernel module, to the time when the rules are loaded from the rc script. In which case adding a new rule like this won't show you anything at all. During those few seconds that 65535 rule will be the only rule in the firewall, so all packets will hit it.


----------



## SirDice (Mar 4, 2020)

pavlar said:


> If IPFW repels them, then they carry some kind of threat.


Don't be so dramatic. It's just a couple of packets that got blocked. Nothing more.


----------



## pavlar (Mar 4, 2020)

xtaz said:


> Add a rule above it numbered something like 65534 which says deny log ip from any to any. Then it will log anything that hits that rule and you can see what it is. As that rule will always be hit before the 65535 one.
> 
> It could well be packets it receives during the time when ipfw first loads from the kernel or kernel module, to the time when the rules are loaded from the rc script. In which case adding a new rule like this won't show you anything at all. During those few seconds that 65535 rule will be the only rule in the firewall, so all packets will hit it.


Like this?
ipfw -at list
..........
65534      0        0                         deny log logamount 100 ip from any to any
65535     27     1359 Wed Mar  4 08:01:36 2020 deny ip from any to any

After rebooting system with new rules
65534     0        0                         deny log ip from any to any
65535    22     3556 Wed Mar  4 17:53:11 2020 deny ip from any to any


----------



## xtaz (Mar 4, 2020)

Exactly like that. But yes, that shows 0 packets hit that rule. So as I thought, rule 65535 is just being hit because during boot ipfw is loaded into the kernel and at that point the only rule is 65535 deny ip from any to any. There are no other rules. So all traffic is being denied.

For several seconds anything that is received by the server will just be denied as the server mounts partitions and starts up all the stuff from the rc scripts. At some point it runs the rc script which loads the firewall rules, and then traffic is allowed as per your rules.

But the 65535 rule will show the count of packets it denied during this time unless you reset the counters.

If it was traffic that arrived after the server had booted then the rule 65534 that you added would show packets. But it doesn't.

Nothing dodgy about it.


----------



## pavlar (Mar 5, 2020)

I would like to know the source of these packets.
I did not get these packets immediately after rebooting the system 10 and 11.
I sequentially upgraded the system from 10 to 12 and did not change the rules IPFW


----------



## pavlar (Mar 11, 2020)

Personally, I think IPFW is the weakest point in freebsd. Complexity, inability to efficiently filter MAC addresses. In my opinion iptables are much better. For example, in iptables, MAC addresses are filtered by a single line.
iptables -A INPUT -m --mac-source AA:BB:CC:11:EE:FF -j  DROP

FirewallD  also has such an opportunity https://firewalld.org/2015/12/mac-address-support


----------



## Bobi B. (Mar 12, 2020)

Out of curiosity, can you list some cases, where you had a need of MAC-address filtering?


----------



## pavlar (Mar 18, 2020)

Bobi B. said:


> Out of curiosity, can you list some cases, where you had a need of MAC-address filtering?


I have a local  network with static address allocation I know all MAC and IP of users and I disconnect MAC and IP users Windows  with a virus and users who use other people's IP addresses  Now to disable MAC of computer with MAC which is not included in the list of allowed in rules of, for example, iptables, I put  computer with CentOS  before computer with  FreeBSD.On my LAN, every IP corresponds a specific MAC. In addition ,find not his  MAC, allowed in iptables rules ,for non-advanced user of network is harder than IP. And finally ,on any level gateway routers you also need to be able to filter MAC


----------



## wolffnx (Mar 21, 2020)

pavlar said:


> I have a local  network with static address allocation I know all MAC and IP of users and I disconnect MAC and IP users Windows  with a virus and users who use other people's IP addresses  Now to disable MAC of computer with MAC which is not included in the list of allowed in rules of, for example, iptables, I put  computer with CentOS  before computer with  FreeBSD.On my LAN, every IP corresponds a specific MAC. In addition ,find not his  MAC, allowed in iptables rules ,for non-advanced user of network is harder than IP. And finally ,on any level gateway routers you also need to be able to filter MAC



me too, i'only miss iptables for MAC filtering and string filter,but here I'discover PF,  and find other solutions to replace my needs
if you choose FreeBSD take a look on PF too, this kind of situations can be and opportunity to change your way of manage your network 
btw,in iptables I'manage the access to internet for the users but is not 100% secure, the user can spoof the MAC address as you now
unless you have port security active in your managed switchs,but is more dificult to mantain


----------

