URL Redirection being blocked?

[r1der]

Good morning,

We have a spam filter, which rewrites any URL in an email.

Today, we encountered an issue with that, possible due the the string being too long is my guess. Under an account that is allowed any external, I was able to reach the redirect and the sites they go to.

An example of my issue is below, except with this example, the redirection is working. I am thinking because it isn't as long as the one I am having an issue with. The URL I am having with is double this lenght, which I am thinking might be the issue.

E.g. this is how the URL would look like.

https://urldefense.com/v3/__https:/www.checkpoint.com/eLearning__;!!FKv5UbzFF59DNjfn2A!XqhrfMzFM9UVp...

This is where it goes.

https://www.checkpoint.com/eLearning/. 

I've identified what rule is stopping it under my Security layer, however I'm not sure what kind of exception to make for this. 
As 

The destination is not showing as Drop or Reject (urldefense.com/sched.com). So not sure what exactly I should be allowing through if I can reach the destinations directly. just not when it has the URL rewritten by the spam filter.

I tried searching but possibly not using the right terms. Can anyone help lead me in the right direction?

Thank you,

[PhoneBoy]

Screenshots of the block rule and the log card that's stopping it would be helpful.
Also version/JHF level used.
I assume HTTPS Inspection is also used here.

[r1der]

Thanks and sorry for the late reply! I should have mentioned we are on R80.40 JHF - 91, HTTPS Inspection is not Enabled. 

Further support with CheckPoint introduced me to the command to find the rule that was dropping it, but I could not find or see the traffic/logs that show that it was actually dropping it, even after filtering my logs  to the src computer/user unable to reach the site.

Great command btw - "fw ctl zdebug + drop | grep <IP of the test user or, of the website>"

As a work around, since I was able to get to the site, I provided the URL that it redirected to. So the user didn't have to use the urldefense URL above, and just went directly to the site.

I will have to test this out further the next time we come around this issue again.

Thanks!

[Cyber_Serge]

From the look of it and based on my experience, it's the vendor's URL rewrite causing issue.

Since it is one off, I'd suggest google "<that vendor>'s URL rewrite decoder", visit the decode site, copy&paste to decode and get the actual URL, then send it to user.

[r1der]

I thought it was the vendor's URL rewrite too, but I could click on it myself and get there. I did end up giving the URL to her directly after it was able to decode on my computer. Thanks!