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
21 Oct, 2022 core arp routing
12 Apr, 2023 core proxyarp arp ipsec routing
9 Dec, 2022 arp core
21 Mar, 2023 core ipreputation log
14 Dec, 2022 incontrol ida log
19 Feb, 2021 core arp
23 Aug, 2022 vmware log ha rarp arp core
27 Oct, 2022 oneconnect log
23 Aug, 2022 core arp garp
8 Apr, 2021 core sslvpn oneconnect interfaces arp
15 Nov, 2022 tcp log core
27 Mar, 2023 core log webui memlog
7 Dec, 2022 pcapdump log cli core logsnoop
23 May, 2022 core log logreceiver
19 Apr, 2023 core hyperv serial console log
17 Feb, 2021 incontrol log
7 May, 2021 core ethernet vlan arp garp
5 Feb, 2021 incontrol log