Come on TAC you can do better

[HristoGrigorov]

So, I opened SR that following two rules are not blocking traffic at all. 

operation=add uid=<5fc4795c,00000000,98c0a8c0,00005f8d> target=all timeout=none action=drop log=regular source=cidr:1.2.3.0/24 pkt-rate=0 service=any
operation=add uid=<5fc47a0d,00000000,98c0a8c0,00007701> target=all timeout=none action=drop log=regular source=cidr:4.5.6.0/24 pkt-rate=0 service=any

These are the questions TAC asked me:

1) what are you trying to achieve?
2) which syntax did you use for this rule?
3) What is the business impact ?
4) Are you trying to block IP's or hosts in SecureXL level using dos mitigation?

My answers here:

1. Trying to block network in SecureXL apparently ?

2. Syntax is evident from rule dump

3. Security is compromised, what should be the business impact ?

4. That question I am not going to answer at all.

At the moment I am really hesitating to close this SR and do it some other way.

[PhoneBoy]

PM me the SR

[_Val_]

Could you please explain the goal of this post? I totally miss the point, unless you just want to vent.

[HristoGrigorov]

Guess I wanted to vent. Sorry 😉

[_Val_]

It's absolutely okay. We will be happy to assist you with anything. Just let us know

[SharonElmashaly]

Hristo,

I've reviewed the SR with my team, and my conclusion is that this is a miscommunication rather than a knowledge/approach issue.

The assigned engineer tried calling you first thing in order to get a full and clear understanding of the request, so he could provide quick and effective help. However, he used the office number shown in the SR and could not get through. 

If you have any feedback about TAC and our service, you are more than welcome to approach TAC management, as described in our Escalation Path: https://www.checkpoint.com/support-services/check-point-tac-support-escalation-path/ . It will quicker and more effective than posting it here.

Please expect a call from the SR owner.

Thank you for your cooperation and understanding.

Regards,

Sharon Elmashaly

VP, Customer Support

[HristoGrigorov]

Thanx Sharon, appreciate your response. 

Are you trying to say that next time I shall not provide any tech info upon opening SR and it is better to wait for a call to avoid such miscommunications ?

I already mailed to SR owner and waiting for him to call me.

[SharonElmashaly]

Not really...

There are cases where there is a need for further clarification, it's natural. 

[HristoGrigorov]

All right, let's not go deep into this. Just remember your customers time is also valuable and should be respected. 

[_Val_]

@HristoGrigorov I believe this goes both ways.

Also, it is part of the TAC engineer job description, to collect as much info as possible. It helps with speeding up the process, and works towards saving your precious time, as I see it. Been on both sides of this calls, talking from experience 🙂

[HristoGrigorov]

I posted it here for two reasons.

One was I was frustrated and wanted to vent some heat 😁

Other one was I believed I tried to save mostly TAC engineer time by providing some initial tech info and then I was asked something that was already there.

And you know a very similar problem was discussed recently here.

I did not wanted to escalate it officially before I talk to SR owner after all. I did not answer first time indeed but that was not a reason to send me some "typical" questions after that rather than to just  "call me back when possible for you". If these things can be sorted by mail only why the call at all ?

Anyway, now I got the impression I am totally wrong to share here opinions about your support, being them reasonable or not. Let other fellas here judge me on that.

[_Val_]

@HristoGrigorov @all the good reasons. Do not get me wrong, we do appreciate transparency and open discussions in the community. 

Communication is the key. Within my 10+ years working as a support partner, I always tried calling my TAC counterpart proactively, to explain the actual issue in hands over a phone, regardless of amount of information provided through the case.

I think they call it "knowledge paradox". More you know about something, less effectively you explain it. It is part of being human.

TAC is here to help. You are also in the position to help them helping you. Works both ways, as already said.

[HristoGrigorov]

Just talked to SR owner and we are now on the same page. Even kind of became "friends" and had some good lough over this situation. I was about to tell him, he is now famous on CheckMates 😁

Seriously, think of that "not enough info, we need to talk" is better that asking this and that over e-mail. Unless things are already in sync of course.  

[_Val_]

My personal rule always was, call TAC guy even if he does not ask anything yet. Works magic, I promise you. It is even part of recommendations in our "Issue Resolution Best Practices" session with CheckMates Live.

[HristoGrigorov]

Where can I read about these best practices ?

[_Val_]

I am not sure if we have any of these session published, but I can invite you to the next one, definitely. 

[HristoGrigorov]

Thanx, appreciated.

[HristoGrigorov]

Quick update... We found an issue with SecureXL and it will likely be fixed in a further JHF package. Once we skipped initial mumbo-jumbo it was actually fun to do it.  So, happy end... 😁