FireWall-1 FAQ: Accepted, then Rejected on Rule 0?
Please note: This content was from when I was operating my FireWall-1 FAQ site, which I stopped operating in August 2005. For some reason people still have links to this stuff on the Internet that people are still clicking on.
I am making this information available again AS IS. Given how old this information is, it is likely wildly inaccurate. I have no plans to update this information.
If you're still running versions of Check Point VPN-1/FireWall-1 where this information is still relevant to you, do yourself a favor and upgrade to a more recent release. If you happen to be running a current release and the information is useful, it's by happenstance :)
Q:
In my logs, I am seeing:
17:13:45 accept kyle >le0 proto
tcp src jungleman dst kyle service telnet s_port 2390 len 48 rule 4
17:13:45 reject kyle <qe0
proto tcp src jungleman dst kyle service telnet s_port 2390 len 48 rule
0
Why is the connection first accepted by my rule 4, then rejected by rule 0? ## A: FireWall-1 can potentially inspect packets against the rulebase twice: * When the packet enters the firewall * When the packet is exiting the firewall (after it has been routed) This can be set with the "Apply Gateway Rules to Interface Direction" setting in the Rulebase Properties as well as on a rule-by-rule basis with the Install-On Field (e.g. Src, Dst, and Specific Targets). In all cases, however, anti-spoof checking is performed twice: * When the packet enters the firewall * When the packet is exiting the firewall (after it has been routed) This check can not be easily disabled and is not controlled by the "Apply Gateway Rules to Interface Direction" setting. It is always checked inbound and outbound. ### Now, onto the Problem at Hand When anti-spoofing checks fail, they show up in the logs as either drops or rejects on rule 0. If you get a log entry that looks like: 17:13:45 drop kyle >le0 proto tcp src jungleman dst kyle service telnet s_port 2390 len 48 rule 0 it means that the source IP of the traffic (in this case jungleman) is not properly included in le0's "valid addresses" setting. If, on the other hand, you see something like this (as was the question above): 17:13:45 reject kyle <qe0 proto tcp src jungleman dst kyle service telnet s_port 2390 len 48 rule 0 it means that the destination IP of the traffic (in this case, kyle) is not in qe0's "valid addresses" setting. Note this may actually indicate a routing problem, particularly if the interface it is being rejected on is not the interface you expect. ### A Final Note In FireWall-1 4.1 and earlier, both the incoming and outgoing anti-spoof checks are performed before address translation. This means that any traffic passing through the firewall must pass anti-spoofing checks before address translation rules are applied. In NG and later, NAT occurs before routing, but only if "Perform Destination Translation on Client Side" is enabled in the global properties, Network Address Translation tab. See also How to define Anti-Spoofing.
