Drop Code: 95(Access Rule Policy not found)
dojjan
Newbie ✭
Hey!
I'm wondering if anyone ever heard of this drop code? I've not stumbled into it before now.
I can not find any information regarding this drop code.
I'm having issues with certain clients behind an IPSEC tunnel reaching servers in a local zone in a supermassive 9200.
When the client ping the server, I can see the traffic being consumed and then forwarded out of the correct interface.
I can see the server reply, but the sonicwall drops the packet with Drop Code: 95(Access Rule Policy not found).
*This is NOT the implicit deny rule.
*The initial traffic is allowed, and forwarded, but the reply is dropped which it should not be, since its stateful.
*The client is behind an IPSEC.
*The server is behind a local interface/zone.
Cheers!
Category: High End Firewalls
0
Answers
You're right, this is a stateful firewall and hence the reply should be also allowed. If you don't mind, could you please share a screenshot of the packet capture that you've taken for this?
Thanks!
Shipra Sahu
Technical Support Advisor, Premier Services
Hi, thanks for the fast reply.
I sure can.
These are ICMP requests, and the replies (red).
Good day,
I am wondering if there has been any resolution to this case as I am experiencing the same issue with one of my site-to-site vpn connections. It stopped working on the 19th of January and I see the same issue when performing packet captures.
Packet comments
in:X9*(interface),out:--,DROPPED, Drop Code: 95(Access Rule Policy not found), Module Id: 25(network), (Ref.Id: _6063_txGsIboemfJqQlu),5:5)
[Expert Info (Comment/Comment): in:X9*(interface),out:--,DROPPED, Drop Code: 95(Access Rule Policy not found), Module Id: 25(network), (Ref.Id: _6063_txGsIboemfJqQlu),5:5) ]
[in:X9*(interface),out:--,DROPPED, Drop Code: 95(Access Rule Policy not found), Module Id: 25(network), (Ref.Id: _6063_txGsIboemfJqQlu),5:5) ]
[Severity level: Comment]
[Group: Comment]
Frame 385: 68 bytes on wire (544 bits), 68 bytes captured (544 bits) on interface unknown, id 0
Ethernet II, Src: Dell_68:01:48 (14:18:77:68:01:48), Dst: Sonicwal_85:ae:7d (c0:ea:e4:85:ae:7d)
Internet Protocol Version 4, Src: 172.19.56.198, Dst: 53.202.69.17
Transmission Control Protocol, Src Port: 80, Dst Port: 13633, Seq: 0, Ack: 1, Len: 0
Source Port: 80
Destination Port: 13633
[Stream index: 1]
[TCP Segment Len: 0]
Sequence number: 0 (relative sequence number)
Sequence number (raw): 3406660696
[Next sequence number: 1 (relative sequence number)]
Acknowledgment number: 1 (relative ack number)
Acknowledgment number (raw): 970971558
1000 .... = Header Length: 32 bytes (8)
Flags: 0x012 (SYN, ACK)
000. .... .... = Reserved: Not set
...0 .... .... = Nonce: Not set
.... 0... .... = Congestion Window Reduced (CWR): Not set
.... .0.. .... = ECN-Echo: Not set
.... ..0. .... = Urgent: Not set
.... ...1 .... = Acknowledgment: Set
.... .... 0... = Push: Not set
.... .... .0.. = Reset: Not set
.... .... ..1. = Syn: Set
[Expert Info (Chat/Sequence): Connection establish acknowledge (SYN+ACK): server port 80]
[Connection establish acknowledge (SYN+ACK): server port 80]
[Severity level: Chat]
[Group: Sequence]
.... .... ...0 = Fin: Not set
[TCP Flags: ·······A··S·]
Window size value: 8192
[Calculated window size: 8192]
Checksum: 0x56ce [unverified]
[Checksum Status: Unverified]
Urgent pointer: 0
Options: (12 bytes), Maximum segment size, No-Operation (NOP), Window scale, No-Operation (NOP), No-Operation (NOP), SACK permitted
[SEQ/ACK analysis]
[This is an ACK to the segment in frame: 384]
[Timestamps]
VSS Monitoring Ethernet trailer, Source Port: 8224
Hey!
If I answer from my side (I'm the TS). The issue did not get resolved, the TAC just told me to upgrade, which I could not do at that moment. So we worked around it.
We did not however try to reboot or do a HA failover. Since this, atleast for us, happened out of the blue, maybe a reboot would solve something. But it's a long shot.
Is your tunnel a route based or policy based VPN if I may ask?
Hi,
Thanks for the quick response, the tunnel is based on the VPN (auto added access rules) Policy
client to VPN rule:
vpn to client rule:
How does your tunnel config look like? What I'm after here is, if you do have a policy based VPN. Are all your address objects in the correct zone?
I have the remote client ip addresses in VPN Zone and I have local client addresses in a separate zone
@WCG_Admin,
I am seeing this is as a reported issue on an older firmware 6.2.x and should be addressed on the latest release 6.5.4.7. What firmware do you have on the firewall?
Thanks!
Shipra Sahu
Technical Support Advisor, Premier Services
I could not see any issue resolved in 6.5.4.7 in regarding to this in the release notes. Whats the issue id?
@dojjan,
Not all issue IDs are listed on the release notes. The issue ID is 189173, and it was reported on 6.2 versions.
Thanks!
Shipra Sahu
Technical Support Advisor, Premier Services
6.5.1.3.11, I will upgrade to 6.5.4.7 and let you know if it makes any difference, thanks.
Have you tried a reboot yet? I too was around 6.5.1.3, but was unable tro try reboot without upgrading.
I upgraded to 6.5.4.7 and initially it made no difference to the vpn as I got the same errors in packet capture. I had to remove the vpn and re-create it for the Access Rules to start working.
The problem now is that I have duplicate access rules for the vpn because it seems that the rules associated with the previous vpn were not removed when I removed the VPN.
How do I remove those stale rules now seeing that they are auto created when the vpn is configured?
@WCG_Admin,
Please refer to this KB article.
Thanks!
Shipra Sahu
Technical Support Advisor, Premier Services
Great, thank you very much... I have managed to remove the stale firewall rules now and the vpn is working as expected.
Shipra Sahu
Technical Support Advisor, Premier Services
Some of our services affected by this got resolved by a reboot of the HA cluster.
I can not confirm the other services that got broken because they are still in a work around.
But my gut tells me they will work too if we revert.