topic Re: r77.30 ospf drop hello in Firewall and Security Management

r77.30 ospf drop hello

Oleksandr_Mamen — Wed, 26 Jul 2017 15:25:37 GMT

Hi everyone

There are one cisco router, one cisco switch and checkpoint cluster in my infrastructure. Cisco router and cisco switch already established ospf neighborship and now I'm trying to establish ospf between between Catalyst 3650 and HA-Cluster R77.30. And it is not working.

Debug information
1. Catalyst sends hello to Cluster
14:40:52.400: OSPF: Send hello to 224.0.0.5 area 0 on Vlan201 from 172.16.1.9
14:41:01.645: OSPF: Send hello to 224.0.0.5 area 0 on Vlan201 from 172.16.1.9
2. Cluster receives it:
[Expert@FIREWALL-1:0]# tcpdump -i eth7.201 ip proto ospf
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth7.201, link-type EN10MB (Ethernet), capture size 96 bytes
17:31:58.572861 IP 172.16.1.9 > ospf-all.mcast.net: OSPFv2, Hello, length: 56
17:32:07.999643 IP 172.16.1.9 > ospf-all.mcast.net: OSPFv2, Hello, length: 56
3. But cluster drops this packets
Log Server Origin: 192.168.10.204
Time: 2017-07-26T14:52:54Z
Interface Direction: inbound
Interface Name: eth7.201
Id Generated By Indexer:false
First: true
Sequencenum: 2147483647
Source Zone: Internal
Rule UID: 145130C7-F7D3-4628-B3EA-13B005CFA621
Source: 172.16.1.9
Destination: 224.0.0.5
IP Protocol: 89
Access Rule Name: CLEAN-UP
Access Rule Number: 21
Action: Drop
Type: Log
Policy Management: MANAGEMENT-1
Blade: Firewall
Origin: FIREWALL-1
Service: 89
Product Family: Access
Layer Name: Firewall_layer
Interface: eth7.201
Description: ospf Traffic Dropped from 172.16.1.9 to 224.0.0.5

4. However I have rule for allow ospf traffic with number 4 (which is upper than 21)
SRC: Catalyst, Cluster
DST: multicast 224.0.0.5, 224.0.0.6, 224.0.0.1, Cluster
Service: OSPF, IGMP
Action: Accept

Could somebody give any help? Trying to make it works more than two days.

Alexander

Re: r77.30 ospf drop hello

PhoneBoy — Wed, 26 Jul 2017 16:57:37 GMT

Is 172.16.1.9 associated as the primary IP address of your gateway or cluster?

If not, you may need to explicitly add that to Rule 4.

On an unrelated topic, you named your firewall the name of the product 20 years ago

Re: r77.30 ospf drop hello

Oleksandr_Mamen — Wed, 26 Jul 2017 19:56:02 GMT

Hi, Dameon.

First of all I'd like to thank you for such quick response.

172.16.1.9 is IP-address of Catalyst Switch which tries to establish ospf neighborship by sending hello packets to CP on multicast address 224.0.0.5.

You can see part of debug ip ospf hello catalyst in my previous message. According to the log Catalyst send HELLO-packets with source 172.16.1.9 and destination 224.0.0.5.

Also I used tcpdump on CP and noticed that it receives packets from Catalyst (number 2 in my previous message).

Firewall rules for OSPF were added according to the guide (screenshot in previous message). But CP is dropping hello packets.

Re: r77.30 ospf drop hello

PhoneBoy — Wed, 26 Jul 2017 23:24:26 GMT

This seems like a basic rule matching issue now that I look more closely at this.

Can you paste a screenshot of the objects used in the Destination for Rule 4 (not the Cluster object)?

Re: r77.30 ospf drop hello

Oleksandr_Mamen — Thu, 27 Jul 2017 11:41:49 GMT

Dameon, screenshots of destination objects

1) OSPF-MULTICAST-ADDRESS (range 224.0.0.5-224.0.0.6)

2) ALLSYSTEMS.MCAST.NET (224.0.0.1)

3) C3650_1-SWITCH (172.16.1.9)

Also there are no matches in rule 4 and traffic is dropped according to the Clean-up rule 21

Re: r77.30 ospf drop hello

PhoneBoy — Thu, 27 Jul 2017 15:01:49 GMT

I have a feeling using "Multicast Range" objects may be the issue, which I have to admit, I've never seen before now.

Try creating the multicast addresses as Host objects instead and use those in the policy.

Re: r77.30 ospf drop hello

Oleksandr_Mamen — Fri, 28 Jul 2017 06:06:02 GMT

IT WORKS!

My previous post was in "MODERATING" state to long and I started testing in changing firewall rules.

I have added a lot of new objects to OSPF-RULE: new objects for EVERY cluster link, new objects for multicast addresses and I was very surprised when CP established ospf neighborship after adding new object to the destination field, objects type was HOST and address 224.0.0.5. And after my all-day testing I received message about your answer.

So, thanks, you were right and issue was with object type MULTICAST-RANGE.

But for what should I use that multicast-range obj?

Re: r77.30 ospf drop hello

PhoneBoy — Fri, 28 Jul 2017 06:14:32 GMT

They are explained in the following sk: Multicast address ranges are not supported for use in the rulebase

Basically they are used only in gateway topology, not in the rulebase.

Re: r77.30 ospf drop hello

Gary_Torrico1 — Tue, 30 Jan 2018 03:17:44 GMT

Hello,
I have the same problem.
1.- configure ospf of area 0
2.- Create object for multicast address.
3.- create a rule in the firewall.

4.- Install Policy.

The configuration is successful. I have adjacency with ospf neighbors and I have end-to-end connectivity. But in the smart log I still see drop connections for address 224.0.0.5 in the ospf 89 service.

detail of the drop connection.

Could somebody give any help?

Re: r77.30 ospf drop hello

PhoneBoy — Tue, 30 Jan 2018 14:51:34 GMT

Refer to the following SK: How to troubleshoot "Local interface address spoofing" issues