| CPUG | |
| The Check Point User Group | |
| A Resource For The Check Point Community. Fast. Useful. Independent. | |
|
| |||||||
![]() |
| | LinkBack | Thread Tools | Display Modes |
| |||
| Hi, Running out of idea with this one : Have a couple of nokias in HA cluster with VRRP on all interfaces. Running pretty fine. s2p3 is my external if leading to internet, and antispoofing defined consequently as "External" for this one. However, there is a group in the object list, when I click "Where Used ?" I can see that it's bound to s2p3 antispoofing !. I indeed deployed a new subnet in front of my external interface, eventually not reachable due to antispoofing (this /28 subnet is included in the larger /16 subnet behind my internal interface). Then I updated the group mentionned above with this /28 subnet, and no more antispoofing issue. How an "External" antispoofing flagged interface can still have a specific antispoofing group bound to it ?!?! Getting nuts here !!! -jc firewall[admin]# fw ver This is Check Point VPN-1(TM) & FireWall-1(R) NG Feature Pack 3 Build 537001004 firewall[admin]# uname -ras IPSO firewall 3.6-FCS6 releng 1061 01.21.2003-230310 i386 Mgmt : # fw ver This is Check Point VPN-1(TM) & FireWall-1(R) NG Feature Pack 3 Build 537001004 |
| |||
| Just tried, it isn't the case. If I switch to "Internal", the "Not Defined" radiobox is checked by default. Feels like my firewalls objects are corrupt. But everything works fine, at the same time. Is there a way to check for fw object corruption without changing anything in the database ? |
| |||
| Remove the interface out of the cluster topology and then go into the topology of the interface on each member and make sure they both say External and not anything else. Once that is done, put the interface back into the cluster topology. |
| |||
| Lackie's hint is the one that will work for you. It's a confirmed CP bug posted on the knowledge base, antis-poffing settings are not inhereted to cluster interfaces in cluster settings, you have to get the interface out of the cluster, configure anti-spoofing and return it back as a part of the cluster. |
| |||
| Thanks to Lackie and Ezabi. In my case the "cluster topology" tab has'nt any topo. Only cluster members topology is filled with topo. Don't know if that is normal or not. probably not. btw, Object.C was a interesting read. Look at the external interface antispoof definition : :officialname (eth-s2p3c0) :antispoof (true) :netaccess ( :AdminInfo ( :chkpf_uid ("{DBCB494A-8AAC-11D7-8B80-849BA631B0B0}") :ClassName (netaccess) ) :access (undefined) :allowed (ReferenceObject :Name (fw3_s2p3_spoof) :Table (network_objects) :Uid ("{D55E9940-8AAC-11D7-8B80-849BA631B0B0}") ) :enable_overlapping_nat (false) :force_policy (true) :leads_to_internet (true) :log (log) :overlap_nat_dst_ipaddr () :overlap_nat_netmask (255.255.255.0) :overlap_nat_src_ipaddr () :perform_anti_spoofing (true) ) Should'nt I have this instead ? :access (this) :allowed () :enable_overlapping_nat (false) :force_policy (true) :leads_to_internet (true) Last question : As it works flawlessly, in the meantime, is there some paper somewhere explaining this as a good workaround for external antispoofing issues, for example in the case you don't want to use exclusion groups when having a /16 behind internal interface, and few /28 of the same range behind external ? If yes, its not a bug but a useful cheat indeed ? -jc |
![]() |
| Thread Tools | |
| Display Modes | |
| |