web site times out when going through firewall

[flachance]

Hi,

One of those issues where a web site isn’t reachable from our network going through the firewall but trying on an outside device we can access it no problem.

Most of the time it’s https inspection that causes these issues but in this case we just can’t find why.

In the browser the error is “This site can’t be reached” “ERR_CONNECTION_TIMED_OUT” with Chrome and “can’t reach this page” “took too long to respond” in Edge.

We’ve set https inspection bypass rule and we can see it’s being bypassed in the logs. Don’t see any drops trying to reach the site.

We were seeing “Connection terminated before the Security Gateway was able to make a decision with the following details”

At the top of our application rule base we created a rule to allow any from a test workstation.

When trying from that test workstation we don’t see the “Connection terminated before the Security Gateway was able to make a decision with the following details” anymore but we still can’t get to that website

The gateway is running R81.20 JHF take 127

We're not to sure where else to look. any suggestions?

thanks

Francis

[Lesley]

Application control / URL filtering needs a bit of data to identify the traffic. A firewall rule to be hit a SYN packet is enough. app / URL needs 3 way handshake and some data.

This error just states that the firewall cannot determine the URL because it was not shown in the data flow. So either there is no 3 way hand shake. or SYN packets does not even arrive at destination. Could be routing, incorrect NAT etc. So packet does not reach destination or it blocked on the destination itself. 

[flachance]

Thanks for this. I ran a capture on the gateway and it looks like all outgoing are malformed packets which could be why they're possibly rejecting it. What could be causing that on the gateway? 

[the_rock]

I know that log you posted in the screenshot usually indicate an issue on the other end, not the firewall, though it says connection terminated.

[Lesley]

Malformed is not a firewall issue. That is how wireshark sees the packet. Also notice in the fw monitor packet is already malformed in the small i (inbound) so it comes in the firewall like that. If it is truly malformed, what I don’t expect 

Common Causes & Scenarios

• Fragmentation: The packet is split across multiple frames and Wireshark cannot reassemble it.
• Truncation/Corruption: The packet was damaged during transit, or the capture tool didn't capture the full payload.
• Malfunctioning Sender: The device sending the traffic is generating incorrect headers or payload lengths.
• Dissector Bug/Misinterpretation: Wireshark's dissector is incomplete, or it is trying to decode non-protocol data (like random TCP payloads) as a specific protocol.

[simonemantovani]

Hello

Dumb question: NAT for outbound connections is correctly applied? How is performed? Do you use automatic or manual NAT? As a NAT IP address are you using the WAN IP address of the firewall?

[flachance]

Hi,

The NAT is applied on the network object representing the clients subnet. It is automatic, Hide. For that subnet we don't use Hide behind the gateway. We use Hide behind IP address (the gateway external IP is .100 and the clients hide behind .10).

When viewed from outside we wanted to differentiate traffic from the clients.

From the other answers, I'm getting that the issue would be with the remote site but since it's accessible when not going through our gateway it's hard to give the client a satisfactory answer.

[simonemantovani]

Did you also tried to use the IP .100 for the automatic NAT instead of the .10, to see if the behaviour changes?

I suppose that if you perform a tcpdump on the WAN interface of the firewall, filtering for the .10, you should see packets going to the Internet with no replies, am I right? 

[flachance]

I tried to change the automatic NAT to Hide behind gateway for a test client and I'm getting the same results. That's right, if I do a capture I see packets going out but no replies.

[simonemantovani]

Ok, so it doesn't seems to be a firewall issue; if there is only one site not reachable, probably is something related to Internet Providers, or for some reason the remote site is blocking your connections; if the sites are more than one, maybe you should involve your provider.

[Lesley]

Then you are done, show the wireshark capture, fw monitor capture and screenshot of traffic log that shows allowed / NAT traffic. That is all the prove you can send.