Specific Software - ICPR will not license when behind Checkpoint

[Terri_Hawkins]

We are a local government using Checkpoint R80.30 on a 15400 cluster.  Our Stormwater Division wants to use ICPR Software. They said this is a widely used mapping program for engineering firms and governments for utilities and mapping. When I try to license the software behind the firewall it does not work. When Checkpoint put a rule on the firewall to bypass packet inspection for this traffic it does work (not https inspection, just the typical inspection). Checkpoint can replicate this on their side as the program does not open for them either.

My question for anyone who uses this software - does it work for you behind a checkpoint firewall? If not, and you had to make the special rule, is this typical or even advisable?

Right now our department users are using an aircard to connect to the vendor and get the license ok'ed then switching back to our network to get it to work.

Any responses are very appreciated!

[PhoneBoy]

Can you provide some details of exactly what you see when it's not working in terms of logs as well as precisely what you configure to make it work?

[Terri_Hawkins]

The program is an executable. When you double click it the program calls out to the licensing server in the cloud, verifies the license is good, then a big mapping page opens. This works off our network on my laptop. When I put my laptop behind our firewall (including directly behind so no network involvement), it calls out to the license server, My laptop is not the issue as it works off network.  I see the license transaction go through, we receive a 200 from the remote server, and I see traffic going back and forth and then it just stops and the program does not open. This is all on port 80 but I added an https bypass exception also just in case.

I put in a rule in our policy which allows this particular desktop to go anywhere on any port (wasn't going to keep it there, just for testing), we also added a global exception for any IPS, AV or AB. No luck.

Checkpoint added a rule through the CLI directly on the gateway so that even the basic packet inspection would not occur. I apologize but I don't know exactly what it was, and that worked. It was some kind of acceleration, but we have SecureXL on, this was in addition to that. Also, SecureXL had to be on for the rule to work, when he turned it off the program stopped working again. The rule also just allowed the workstation to go anywhere on any port without any packet inspection at all.

The firewall logs all show the traffic going through and being accepted on port 80. On the pcap where it works you see the last traffic comes from the vendor. On the pcap where it does not you see our desktop calling out again and no response. Checkpoint says the last call does not work with the basic inspection and they need to discuss it with the vendor to find out why. I appreciate that they are willing to do that and I am trying to get an IT number there so I can get a conference call going. 

I am really just trying to find out if this indeed an issue with this particular program. We are getting ready to move ~4000 employees to this firewall for internet traffic. I only have about 30 going through now. I am worried if this is not a one-off, and if it is an issue with the firewall, I am really going to have my hands full when we move everyone. 😞

Any insight or thoughts you have are greatly appreciated.

Thanks

terri

[Daniel_Taney]

I'm guessing maybe they used the fast_accel feature of SecureXL to force the traffic into the SXL path. As I understand it, doing this basically foregoes almost all Firewall inspections. 

If you wanted, fw ctl fast_accel show_table would likely confirm if this was the "fix". 

Beyond doing a packet capture, do you know if TAC did any other captures? Like kernel debugs looking for drops inside the FW Kernel. I've definitely seen a lot of circumstances where the packet capture doesn't tell the whole story. 

In its least refined form, you could always do fw ctl zdebug + drop | grep <src IP address> or fw ctl zdebug + drop | grep <dst IP address> (probably more preferable if you know the destination IP for sure). This would likely give you a better reason why the traffic is being dropped by the GW.

[PhoneBoy]

The only thing I can think of is something in the traffic is not RFC compliant, thus it's getting dropped at a relatively low level.
You should see some evidence of this in your gateway logs and/or with fw ctl zdebug as Daniel suggests.

[Terri_Hawkins]

Thank you for your insights. That was the rule they set up to make it work. I am setting up a meeting with the vendor, checkpoint, and myself to see if we can determine what the traffic is doing that it cannot have just basic firewall inspection. I will post the results of the meeting in case anyone is interested or has the same problem I did.

Thank you again!

terri

[Terri_Hawkins]

So the problem has been found. In the pcap it shows the vendor application says it is going to send 2685 content-length it it actually sends 2687, which is non-compliant. The GW tries to repair the connection which breaks the application. Apparently since it is trying to repair it it does not drop it which is why we are not seeing drops in the logs or debugs.  I have sent this info to the vendor to see if they can correct it.  

Thank you again for taking the time to respond and share your knowledge with me!

terri