Anti Spoofing Issue

[futureechos]

I've got an issue with our Cluster, probably of our own making.

Our DMZ networks are 10.96.x.x. These are directly connected to the nokia's. We have another 10.0.0.0/8 network connected indirectly to our internal network via a 172.20.0.0 network. There is a static route to the 10.0.0.0/8 via the 172.20.x.x.

When I try and route traffic tothe 10.0.0.0/8 the return traffic gets blocked via smart defense Anti Spoofing.

There is an anti spoofing group defined on that interface which already has 172.20.x.x in the group. I added 10.0.0.0/8 to the anti spoof group which then prevented any traffic getting through. I've fixed that little problem but I'd like to know how to get traffic the the 10.0.0.0/8 without it getting marked spoof on return.

thanks for advice.

[dantro]

Go to the topology of your firewall object that is shown as origin for the address spoofing. You will find the topology settings when double clicking this Check Point object. Now edit the interface properties of the interface that has to deal with your 10.0.0.0 network. Switch from the General to the Topology tab. Make sure that under 'specific' your anti spoofing group is defined, otherwise fix it and tell the interface which networks it has to handle. Install the policy.

Best regards,
Danny Trommer
CCSA/CCSE/CCSE+

[MarioL]

Never tried "overlapping" anti-spoofing configurations, but from what you describe, your configuration should look something like this:

DMZ interfaces -- This network (guessing here)
172.20.x.x interface -- Group with 10.0.0.0/8 and 172.20.0.0/16 (guessing mask here)

This sounds like what you did before, so not sure why it was blocking traffic.

[futureechos]

Dantro - Thanks for the reply, but I've already done those steps.

This is why I am confused, I have done everything as you have specified but it's not working.

In the AntiSpoof Group defined on that interface is the directly attached network (172.20.0.0/16), so I added the 10.0.0.0/8 to that antispoof group, as this is accessible via the 172.20/16. and thats when the firewalls stopped talking to anything. I had to fw unloadlocal on the firewall and push the policy out again.

I'm thinking maybe its clashing with the DMZ networks as there will be some overlap. I don't want to change all the addressing on the DMZ, but will if I absolutley have to.

thanks.

[futureechos]

Originally Posted by MarioL

Never tried "overlapping" anti-spoofing configurations, but from what you describe, your configuration should look something like this:

DMZ interfaces -- This network (guessing here)
172.20.x.x interface -- Group with 10.0.0.0/8 and 172.20.0.0/16 (guessing mask here)

This sounds like what you did before, so not sure why it was blocking traffic.

Ext Interface - 10.96.x.x (on to ext firewalls)
DMZ interface - 10.96.x.x
Internal - 172.20.x.x ( and 10.0.0.0/8) is routable beyond 172.20.x.x
sync - 192.x.x.x for sync traffic crossover only to other firewall.

I'm not sure why its doing this either. :-(


thanks.

[lammbo]

Originally Posted by futureechos

I'm thinking maybe its clashing with the DMZ networks as there will be some overlap. I don't want to change all the addressing on the DMZ, but will if I absolutley have to.

Overlap? This is quite possibly the issue - I had something similar.

Suggestion - even if this doesn't fix it, this is better to avoid future topology overlap

1) Create network objects that break down your 10.x/8 networks into their real subnets instead of just changing the mask to 1 large super net
2) Assign static routes on your firewall for the individual 10.x.x.x/16 or 24? (whatever) - they will route via the 172.20 interface for your LAN
3) Fix Anti-Spoofing group for your LAN interface to contain those new NET objects you created in step 1
4) Fix your DMZ subnets that are 10.x now, repeat any necessary steps until all 10.x nets are covered by their real net mask
5) Get updated topology from the firewall(s)
6) Push policy to firewalls

Hope this helps, it worked for my situation.

OH - IS this a cluster? Clusters require special care and I almost forgot. If this is a cluster, you will not be able to change the anti-spoofing definition unless you:

1) pull the cluster members out of cluster group
2) change the anti-spoofing definition
3) add back to cluster group

I have never understood why it was like this, it just is.

[futureechos]

Originally Posted by lammbo

Overlap? This is quite possibly the issue - I had something similar.

Suggestion - even if this doesn't fix it, this is better to avoid future topology overlap

1) Create network objects that break down your 10.x/8 networks into their real subnets instead of just changing the mask to 1 large super net
2) Assign static routes on your firewall for the individual 10.x.x.x/16 or 24? (whatever) - they will route via the 172.20 interface for your LAN
3) Fix Anti-Spoofing group for your LAN interface to contain those new NET objects you created in step 1
4) Fix your DMZ subnets that are 10.x now, repeat any necessary steps until all 10.x nets are covered by their real net mask
5) Get updated topology from the firewall(s)
6) Push policy to firewalls

Hope this helps, it worked for my situation.

OH - IS this a cluster? Clusters require special care and I almost forgot. If this is a cluster, you will not be able to change the anti-spoofing definition unless you:

1) pull the cluster members out of cluster group
2) change the anti-spoofing definition
3) add back to cluster group

I have never understood why it was like this, it just is.

Lammbo,

Thanks for the info, I think this is probably the way to go. I'll try both methods and report back.

thanks!

[jacobsen]

we have nearly the same config like futureechos has.
the solution lammbo mentioned might work, but if (like in our scenario) there are too many class C subnets out of 10.0.0.0/8 used on the LAN side (>500),
it's not feasable to create all these network objects and create static route entries.

the only chance would be to avoid having subnets out of 10/8 in the dmz and instead use other rfc1918 addresses (192.168.x.x)


J

[mdiot]

I confirm that the problem you have is normal because you cannot have 10.96.x.x define for antispoofing on a DMZ and at the same time the 10.X.X.X/8 define on your lan. It's mot possible to say to your firewall tou can have 10.96.X.X comming on DMZ adnLAN at the same time. Your 10.X.X.X/8 is too large you ar overlapping 10.96.X.X. So I am quite sure that you don't all the subnet 10/8 that can came from LAN, so you will have to exclude the 10.96 from the antispoofing group define on your lan. You can use different mask or ip range tu surrounf the 10.96.X.X. or you can use group with exclusion (new antispoof group = actual antispoof group (172.20.X.X + 10.X.X.X/8) - other group which contains 10.96.X.X/24)