Unrecognized firewall log output

Sometimes, for example, admins create a definition for use as the traffic selector destination in a DNAT, and that won't work unless the definition is bound to the target interface.  Instead of doing that, the admin should always use the "(Address)" object created by WebAdmin when the interface (or Additional Address) was created.

Make sure that your DNATs don't use your manually-created definitions as the 'Destination' in the traffic selector portion of the rule.  Rather that you use "External (Address)" for example.  Similarly, in your other NATs, make sure an "(Address)" object is used wherever possible.

Binding a definition you create to a specific interface can generate strange problems.  The only real reason an admin would want to bind definitions to an Interface would be to eliiminate a spoofing problem.  If you have spoofing protection enabled ('Firewall' 'Advanced' tab), there's never a reason to bind a definition to an interface in a definition you create.

Cheers - Bob

Sometimes, for example, admins create a definition for use as the traffic selector destination in a DNAT, and that won't work unless the definition is bound to the target interface.  Instead of doing that, the admin should always use the "(Address)" object created by WebAdmin when the interface (or Additional Address) was created.

Make sure that your DNATs don't use your manually-created definitions as the 'Destination' in the traffic selector portion of the rule.  Rather that you use "External (Address)" for example.  Similarly, in your other NATs, make sure an "(Address)" object is used wherever possible.

Binding a definition you create to a specific interface can generate strange problems.  The only real reason an admin would want to bind definitions to an Interface would be to eliiminate a spoofing problem.  If you have spoofing protection enabled ('Firewall' 'Advanced' tab), there's never a reason to bind a definition to an interface in a definition you create.

Cheers - Bob