cancel
Showing results for 
Search instead for 
Did you mean: 
Create a Post
Danny
Pearl

Re: One-liner for Address Spoofing Troubleshooting

I see. I added the quotes your mentioned plus a check to verify that $vsname is not empty.

[[ ! -z '$vsname' ]]
0 Kudos

Re: One-liner for Address Spoofing Troubleshooting

These are both actually the same test:

 

[[ -n '$vsname' ]] && [[ ! -z '$vsname' ]]

 

Only one should be needed. Either should be true in case of VSX with $vsname set.
 
Either should also be false in case of non-VSX or my apparently-weird VSX boxes. I will have to dig into bash startup some time to figure out what my system is doing differently.
 
Deeper in the script, there appears to be another problem which I don't yet have a good idea how to solve. After the modifications to the tests, I'm able to get the expected output on one cluster member, but the other outputs the data for both members. That seems suboptimal, and it's what I was researching just before I posted to the other thread and had to work on other tasks.
 
The problem is the schema for the local.set file is private, so Check Point could change the ordering of the key(value) pairs within a given nesting level at any time. Or the process which generates the file could just spit them out differently due to a race. The obvious solution would be to work based on the nesting level, but like I said in the other thread, my awk-fu is weak. I'm not sure how to end the pattern space after the second closing parenthesis alone on a line.
0 Kudos
Danny
Pearl

Re: One-liner for Address Spoofing Troubleshooting

Thanks for testing. I remove the obsolete check and I'm glad that it works now for you.

As for the output of both cluster members on your other cluster node, the One-liner already tries to avoid that by deleting all ifindex entries from local.set except the one of the current system. To further optimize the check please send me the relevant local.set privately, so I can have a look.

0 Kudos

Re: One-liner for Address Spoofing Troubleshooting

More weirdness. Turns out $vsname needs to be in quotes in the test. Apostrophes aren't enough:

if [[ -n "$vsname" ]] && [[ $vsname != *'unavail'* ]]

Not sure if the second test should also be quotes.

I should be able to send the relevant chunks of the local.set soon.

0 Kudos
Danny
Pearl

Re: One-liner for Address Spoofing Troubleshooting

Thanks, code was improved.

Re: One-liner for Address Spoofing Troubleshooting

I can confirm the current version definitely works on my all-the-edge-cases R77.30 firewall. It also works for the current VS on my VSX R77.30 and VSX R80.10 firewalls.

0 Kudos
Highlighted
Sven_Glock
Silver

Re: One-liner for Address Spoofing Troubleshooting

Thanks for this cool one-liner,  Danny!

I found one gateway where the script is not running:

 

It is a non-vsx gateway running R80.10 JHF 203.

All the output I get is:

 

Interface Topology > firewall
--------------------------------------------------------------------------------

I hope I will find some time for investigation...

 

Cheers

Sven

 

0 Kudos
Hadi
Ivory

Re: One-liner for Address Spoofing Troubleshooting

Thanks Danny, Could you please post final revision?
0 Kudos
Danny
Pearl

Re: One-liner for Address Spoofing Troubleshooting

@Hadi , you can always find the latest revision of my one-liner in my initial post of this thread.

0 Kudos

Re: One-liner for Address Spoofing Troubleshooting

Ran into a bizarre issue. It seems in some environments, the main IP in the firewall object and the IP listed in the hosts file can be different. The IP in the hosts file aligns with the IP on the interface fed to 

set management interface <interfaceName>

Meanwhile, the main IP can be any address. Technically, it doesn't even have to be an address the firewall has on an interface (though it's a really bad idea to use a main IP it doesn't own).

The script gets the anti spoofing configuration from the file local.set, which lists it under the main IP of the firewall object. Thus, the script as it is will fail in such environments. This is probably expected behavior. If you have this situation on your firewalls, you can work around it by replacing

$(if [[ -n "$vsname" ]] && [[ $vsname != *'unavail'* ]] && [[ $INSTANCE_VSID != '0' ]]; then echo $vsname; else grep `hostname` /etc/hosts | cut -f1 -d' '; fi)

with what you have set as the firewall's main IP. It will then work only on that firewall.

This is a workaround for administrative misconfiguration.

0 Kudos
Sven_Glock
Silver

Re: One-liner for Address Spoofing Troubleshooting

I have trouble with the same part of the oneliner, but your solution is not working for me. I will try to investigate...

0 Kudos
Danny
Pearl

Re: One-liner for Address Spoofing Troubleshooting

Thanks @Bob_Zimmerman ,

I just added an error message for these situations to the one-liner.

0 Kudos

Re: One-liner for Address Spoofing Troubleshooting

Congratulations to @Danny on winning the award for this. I saw this mentioned in the Checkpoints email and tried it out. On the couple of VSX boxes I've used this on, I get "Main IP of myboxname-ch01-01 doesn`t match it`s management interface IP!". I spent a couple of minutes looking at the script to see what it's trying to check for but it wasn't obvious (to me). Could some kind soul let me know what the likely issue is so that I can investigate? Thanks.

Danny
Pearl

Re: One-liner for Address Spoofing Troubleshooting

HI @David_Kozinn ,

the main IP of your VS gateways is shown in SmartConsole under Gateways and Servers.

grafik.png

This should be the same IP that is configured within /etc/hosts for the specific VS. In your case this doesn't seem to match.

0 Kudos