connection table questions

[Daniel_Kavan]

Hi,

This has been a crazy week.   We had two customers (both on the same subnet)  that couldn't get to their web page behind the Check Point firewall R81 JHF 36.  Externally, we couldn't get to the web server, internally we could.  Anyone who came in externally could NOT get to the site.  We all tried from home.    In the logs, I noticed some SYN-ACK outbound drop from the private IP of the server to whatever external IP was trying to hit at the time.   I ended up with 'fwaccl off' .   to get things working again, actually on 2 sites in the same subnet.   Is it possible the connection table was stuck on the NAT routable IP that's why outbound traffic was stuck and not internal?    I'm trying to guess as to what reasons could cause this and explain it to the customer.  And to keep it from happening again.   Next time I plan to clear the connection of the IPs having trouble and keeping 'fwaccl on'.

[HeikoAnkenbrand]

Hi @Daniel_Kavan,

Could you  provide a "fw monitor" of the affected connection?

In an emergency situation, I would disable SecureXL for certain IP addresses only.
Disable SecureXL for specific IP addresse:

sk104468 - How to disable SecureXL for specific IP addresses

[Daniel_Kavan]

No, I don't have a fw monitor capture.

In theory though if your web server has a private IP and a static NAT, will the outbound connection in the connection table be on the public (static NAT) IP?  I'm trying to explain in theory how we were able to access the server internally, but from external no one that tried to access it could see it.   It was dropping us all, until fwaccel off, even new connections all of us coming from unique public IPs.

[Daniel_Kavan]

Also, what can cause a connection to get stuck in the acceleration table?

[Timothy_Hall]

When you say internal users could get to the web server, were they going to the server's real internal address or the outside NAT address?  If the internal address that is very different from trying to hit the NAT address from the inside.

If your web server initiates a connection it will use its own static NAT address for that by default and no Hide NAT rules will be used if you employed Automatic NAT setup.

Once the first packet of a new connection is received and accepted, the needed NAT rule(s) are matched and the NATting for that connection cannot change even if the relevant NAT configuration is modified and policy reinstalled.  New connections will of course use the new NAT configuration, I think this is part of what happened to you.  My guess is that Accept and NAT templates were formed in SecureXL for some kind of prior incorrect NAT configuration for the webserver and the inbound traffic to your web server had minimal inspection so it was fully accelerated by SecureXL and still using the incorrect configuration.  Your outbound traffic was probably subject to more inspection (APCL/URLF, TP, etc.) and either Accept templates could not be formed or the traffic could not be fully accelerated for some other reason so it hit the updated rule config in F2F and worked.

When you ran fwaccel off Accept/NAT templates were disabled and any new inbound connections then ran through the updated NAT rule base and started working.  However keep in mind that when you run fwaccel off in R80.20+ it only applies to NEW connections; similar to the situation I mentioned above involving NAT rules existing connections will continue to be handled by SecureXL. 

This is particularly problematic with web browsers who love to keep speculative connections open to web servers you have visited recently, and are not opening actual new connections when you refresh that will be subject to your new configuration or bypass SecureXL.  When testing something like this, always be sure to close all browser windows (or better yet switch to a completely different browser type) to ensure all speculative connections are closed as this can cause some really flaky-looking behavior.