Network Management

Hi all,

We are installing worldwide new Checkpoint firewalls. Now we see in the tracker of Checkpoint the following logs

Check Point logging laat geblokte snmp-traps zien:

Number:                3338438
Date:                     21Feb2017
Time:                     12:28:06
Interface:               eth3
Origin:                   <firewall>
Type:                     Log
Action:                   Drop
Service:                gsnmp-trap (162)
Source Port:          54606
Source:                 <Wireless Virtual Controller or AP>
Destination:          <Airwave server address>
Protocol:               udp
Information:          message_info: Violated unidirectional connection
Product:                Security Gateway/Management
Product Family:    Network
Policy Info:            Policy Name: Standard
                              Created at: Tue Feb 21 09:56:58 2017
                              Installed from: fw-mgmt-internal1

Checkpoint has an article about this:
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk31808&partition=Advanced&product=Security

But this doesn't help us.

Does someone has experience with this, or can help us.

Without knowing anything, it looks like a controller or AP is sending traps to Airwave, which is perfectly normal.  You might want to ask Checkpoint to clarify.

Hi Colin,

Thanks for your reply. It seems the way the AP/Controller is sending the trap is not according the official way or is using the same source port to quick after each other.

Comment of Checkpoint FAQ

CauseBy default, a reply to a UDP packet is not allowed.
The Security Gateway can mark a connection in the Connections Table to allow traffic to pass only in one direction (hence the term 'unidirectional').
If a UDP connection uses a bi-directional communication method, this would create a violation.

Please ask checkpoint to explain if there is a problem with the source port.  UDP is a unidirectional protocol and an SNMP trap is, as well.  We need more technical information about why it is flagged.

Hi,

I'm facing the same log on firewall.

In fact SNMP Trap is sent from controller to airwave server. For each trap sent, Airwave send a packet as response... The firewall drops the response, because of UDP/162 is unidirectionnal only.

here a tcpdump on airwave :

09:11:03.571810 IP controller.49670 > airwave.162:  F=apr U=SNMPv3 [|snmp][|snmp]
09:11:03.573017 IP airwave.162 > controller.49670:  F= [|snmp][|snmp]
09:11:04.573582 IP controller.49670 > airwave.162:  F=apr U=SNMPv3 [|snmp][|snmp]
09:11:04.574619 IP airwave.162 > controller.49670:  F= [|snmp][|snmp]
09:11:05.575797 IP controller.49670 > airwave.162:  F=apr U=SNMPv3 [|snmp][|snmp]
09:11:05.577613 IP airwave.162 > controller.49670:  F= [|snmp][|snmp]

The firewall drop every packet from airwave to controller with the contraint violated unidirectionnal connection.

On airwave, all traps are received and all seems working fine even if the response is dropped. so my question :

Why Airwave send response on every trap reveived ?

Hi,

Are you sending snmp traps or inform, based on tcpdump output it looks you are using snmpv3 user and we use snmpv3 for inform.

Inform is unidirectional, what ever event sent by controller, it will send acknowldegment whether it received event or not.

Thank you for your reply. We are in inform type.

And just to be sure, as Firewall drops the response, controllers will resend the message until the retry counter expire ?

I dont think controller resend the same inform packet to airwave if it does not received ack packet from airwave.

controller does not store any historical log events.

Note: It always recommand to allow port 162/161 both ways on firewall if you have in between airwave/controller.