The meaning of the Default_Access_Rule log entry

Last modified on 7 Nov, 2022. Revision 7
I see the log entries about "Default_Access_Rule", what exactly does this mean?
Up to date for
13.00.08
Supported since
8.xx
Status OK

Question:

I have a lot of “Default_Access_Rule” events in my logs, what is the cause of this?

Answer:

Basically “Default_Access_Rule” is a routing problem. The Receive interface has received a packet from a source IP that is not routed on this interface. The action for this is dropped by “Default_Access_Rule”.

Example:

We have 2 Interfaces named Lan and Dmz with the following routes:

Route Lan 192.168.10.0/24
Route Dmz 192.168.20.0/24

Now as an example i move a PC behind the Dmz interface and place it behind the Lan interface without changing the IP to the correct one, the logs will be filled with events that look something like this:

RULE: id=06000051 rev=1 event=ruleset_drop_packet action=drop rule=Default_Access_Rule recvif=Lan srcip=192.168.20.100 destip=224.0.0.22 iphdrlen=24
ipproto=IGMP ipdatalen=16 type=34 maxresp=0 groupaddr=0.0.0.1

ARP: id=00300049 rev=1 event=invalid_arp_sender_ip_address action=drop rule=Default_Access_Rule recvif=Lan hwsender=00-0c-23-2c-30-4a hwdest=ff-ff-ff-ff-ff-ff
arp=request srcenet=00-0c-29-2c-30-4a srcip=192.168.20.100 destenet=00-00-00-00-00-00 destip=192.168.20.1

And the reason is that since 192.168.20.100 is not routed on the Lan interface it will be dropped by the “Default_Access_Rule”.

Troubleshooting:

Troubleshooting “Default_Access_Rule” is usually fairly straight forward as it is always a routing problem. The main problem is that we have received a packet on this interface that is not routed on the receive interface. Your best friend here are the logs, they will immediately tell you which interface the packet was received on and from which source IP. If we look at the example above we clearly see that we have received a packet from a source IP that is not routed on that interface. For a clear view of the routing table use the CLI command “routes” in the console.

Another good “tool” to troubleshoot problems with “Default_Access_Rule” is the ping simulation described in the Clavister VPN cookbook Appendix-A which can be found here (also as PDF) : https://www.clavister.com/services/resources/configuration-cookbooks/

A second example of “Default_access_rule” that could be slightly confusing is when then source IP is not shown in the log but only a MAC address such as this:

Default_Access_Rule;Warning;ARP;invalid_arp_sender_ip_address;drop;G1:003056BD4EC0;FFFFFFFFFFFF;Arp;Failed to verify ARP sender IP address. Dropping

In this scenario it is an ARP broadcast were the IP address is only shown in the data payload. When doing a log query in InControl for instance it may be shown as if the source IP is 0.0.0.0, but the IP address will be shown in the payload. It is a small limitation in how this particular log is presented. A way to see the real source IP would be to either use the “arpsnoop” command in the CLI or examine it using a packet capture (PCAP) of the ARP query.


Related articles

Setup of a Layer-3 bridge over IPsec in cOS Core
12 Apr, 2023 core proxyarp arp ipsec routing
How to disable IP Reputation in cOS Core
21 Mar, 2023 core ipreputation log
Configuring SSL-VPN / OneConnect server on secondary Firewall IP address
8 Apr, 2021 core sslvpn oneconnect interfaces arp
The TCP Window Scale Log Event
15 Nov, 2022 tcp log core
Automatically stop active PCAPdump or Logsnoop in the CLI
7 Dec, 2022 pcapdump log cli core logsnoop
Why some log category ID's are missing
23 May, 2022 core log logreceiver
Assigning additional IPs to cOS Core Ethernet interfaces
7 May, 2021 core ethernet vlan arp garp