This discussion has been locked.

You can no longer post new replies to this discussion. If you have a question you can start a new discussion

8116 packets from Cisco

Hi,
recently we add a couple of Cisco PIX to our network and now i find a lot of packets blocked AND logged by packet filter.
I think this packets is like an 'heartbeat' between two Cisco (in load bal & falut tol.) but i can't find a good rule to ignore this!!
Anynone can help me to write the rule?
This is a sample from live log....

12:26:56 0.0.0.0 8116 -> 0.0.0.0 8116 UDP 20 44 255
12:26:56 0.0.0.0 8116 -> 0.0.0.0 8116 UDP 20 44 255
12:26:56 0.0.0.0 8116 -> 0.0.0.0 8116 UDP 20 40 255
12:26:56 0.0.0.0 8116 -> 0.0.0.0 8116 UDP 20 44 255
12:26:57 0.0.0.0 8116 -> 0.0.0.0 8116 UDP 20 44 255
12:26:57 0.0.0.0 8116 -> 0.0.0.0 8116 UDP 20 44 255
12:26:57 0.0.0.0 8116 -> 0.0.0.0 8116 UDP 20 44 255
12:26:57 0.0.0.0 8116 -> 0.0.0.0 8116 UDP 20 40 255
12:26:57 0.0.0.0 8116 -> 0.0.0.0 8116 UDP 20 44 255
12:26:58 0.0.0.0 8116 -> 0.0.0.0 8116 UDP 20 44 255
12:26:58 0.0.0.0 8116 -> 0.0.0.0 8116 UDP 20 40 255
12:26:58 0.0.0.0 8116 -> 0.0.0.0 8116 UDP 20 44 255
12:26:58 0.0.0.0 8116 -> 0.0.0.0 8116 UDP 20 44 255
12:26:58 0.0.0.0 8116 -> 0.0.0.0 8116 UDP 20 44 255
12:26:59 0.0.0.0 8116 -> 0.0.0.0 8116 UDP 20 44 255
12:26:59 0.0.0.0 8116 -> 0.0.0.0 8116 UDP 20 40 255
12:26:59 0.0.0.0 8116 -> 0.0.0.0 8116 UDP 20 44 255
12:26:59 0.0.0.0 8116 -> 0.0.0.0 8116 UDP 20 44 255

P.S. I tried this rule with no effects... Anomalia-8116 is my definition for that service.

[none]    -  Any  0.0.0.0/0   Anomalia-8116    0.0.0.0/0   Any    [none]

Thanks in advance!!

This thread was automatically locked due to age.

Parents

0 NimmdirKeks over 19 years ago

Don't think its the hearbeat. It's more like a "line up" check from the router. Something similar is being broadcasted by a few cluster boxes.
Could be possible, that the routers will run havoc if you try to drop the traffic.

Chris
Cancel
Vote Up 0 Vote Down

Cancel
0 galpe over 19 years ago in reply to NimmdirKeks

Ok, probably isn't heartbeat, but now this traffic is already blocked by Astaro without any problem... I just need a way to don't log the event.
Thanks for your response...
Cancel
Vote Up 0 Vote Down

Cancel
0 doug_p over 19 years ago in reply to galpe

You can add a pass rule to keep the traffic out of the logs if it is just traffic that is being seen on an interface). I had to add rules like this to get rid of logging for internal only Windows traffic.
Cancel
Vote Up 0 Vote Down

Cancel
0 galpe over 19 years ago in reply to doug_p

Do you mean an 'Allow' rule?
Cancel
Vote Up 0 Vote Down

Cancel
0 doug_p over 19 years ago in reply to galpe

Yes.
Cancel
Vote Up 0 Vote Down

Cancel
0 galpe over 19 years ago in reply to doug_p

Thank you, i tried but nothing change...i'm having lot of logged packet by packet filter...
Cancel
Vote Up 0 Vote Down

Cancel
0 AdrienBelcourt over 19 years ago in reply to galpe

If an "any-any-any drop nolog" as your last rule does not catch it then I would go to Astaro Support and pose the question to them.

Port 8116 is Checkpoint Clustering protocol

#                           David Pinch  April 2002
cp-cluster      8116/tcp    Check Point Clustering
cp-cluster      8116/udp    Check Point Clustering

From http://www.iana.org/assignments/port-numbers
Cancel
Vote Up 0 Vote Down

Cancel
0 cyclops over 19 years ago in reply to AdrienBelcourt

try instead of "any-any-any drop nolog" "any-any-IP_address_of_firewall drop nolog" before calling support ;-)

Greetings
cyclops
Cancel
Vote Up 0 Vote Down

Cancel
0 BarryG over 19 years ago in reply to cyclops

You also should have a rule to drop packets to the network broadcast address.

Barry
Cancel
Vote Up 0 Vote Down

Cancel
0 AdrienBelcourt over 19 years ago in reply to BarryG

Quite right Cyclops/Barry - LOL thankyou. Broadcast must be to either to broadcast or network addresses regardless of the actual address destination address being 0.0.0.0. Might need to define global broadcast address of 255.255.255.255 (as mentioned in context sensitive help) to catch it if internal(broadcast) does not.
Cancel
Vote Up 0 Vote Down

Cancel
0 galpe over 19 years ago in reply to AdrienBelcourt

Yeah!!! Thanks Everybody (and official support) but this solutions don't work!
This packets are terrible!!! With any-any my rule go in forward chain (and have no effect) and whit any- the packet doesn't match!!!
I find a solution with a DNAT rule like:

Any-Any-8116 ---> DNAT to Any--8116

The DNAT is apply before packet fileter rules....
So a packet filter rule like:

Any--8116 DROP

will burn this million of packets!!!!
Cancel
Vote Up 0 Vote Down

Cancel

Reply

0 galpe over 19 years ago in reply to AdrienBelcourt

Yeah!!! Thanks Everybody (and official support) but this solutions don't work!
This packets are terrible!!! With any-any my rule go in forward chain (and have no effect) and whit any- the packet doesn't match!!!
I find a solution with a DNAT rule like:

Any-Any-8116 ---> DNAT to Any--8116

The DNAT is apply before packet fileter rules....
So a packet filter rule like:

Any--8116 DROP

will burn this million of packets!!!!
Cancel
Vote Up 0 Vote Down

Cancel

Children

0 AdrienBelcourt over 19 years ago in reply to galpe

Nice one. Thanks for the solution share. Interesting you have to DNAT them to catch them in the packet filter.
Cancel
Vote Up 0 Vote Down

Cancel
0 BarryG over 19 years ago in reply to AdrienBelcourt

You shouldn't need to NAT them.

You need to drop the 8116 packets for the following:
INT ASL IP
INT Broadcast (x.x.x.255 or whatever)
Global Broadcast (if needed)
INT Network address (x.x.x.0 or whatever) (if there's traffic on that addr)

That should do it; if not, then it sounds like a bug.

Barry
Cancel
Vote Up 0 Vote Down

Cancel