Forwarding rule misrouted at times

Gemini3

Hello,

we have a Http-Paket filter rule forwarding traffic on one of our public IP addresses to an internal server on port 80 (static NAT).
For one customer it happens at times that the request is misrouted and leads to the Firebox SSLVPN Login website which causes an error. He says he always use the same URL http://xxx.yyy... The SSLVPN Login website is available on the same IP but only over https.
In the Dimenson Log Search there is traffic from that customer stopping exact at that time when he receives error. Traffic of other customers go on.
I can't see where the routing is that lead him to the SSLVPN Login site.

greggmh123

My guess would be that he is using Chrome. Google wants to force everything to HTTPS, and even though your site is HTTP-only, Chrome may force a change. I have had that happen on multiple sites, including from my LAN just trying to get to the http://Firebox-IP-Address:4126 cert portal page. Chrome keeps forcing it to HTTPS and there is nothing there. I open Internet Explorer and go to the same http://Firebox-IP-Address:4126 and the cert portal page loads normally.

I have to clear Chrome's history to get it to stop.

I don't know if it would help, but you could put your port 80 rule above your SSLVPN rule and try it.

james.carson

Hi @Gemini3

The SSLVPN will only respond on the port that it's listening on (by default port 443/tcp, but this can be changed.)

Most modern browsers assume https unless http://example is typed out -- it could be that the browser is simply assuming the customer meant https. If you have logging enabled for your policies, you should be able to see what port the request came in on.

You can see an example log line here:
2020-09-28 08:34:50 Allow sourceIP destinationIP https/tcp 64572 443 External-0 Firebox Allowed 44 64 (WatchGuard SSLVPN-00) proc_id="firewall" rc="100" msg_id="3000-0148" dst_port_nat="4137" tcp_info="offset 6 S 75552453 win 64240"

The portion that says "64572 443" denotes the source, then destination port. If the destination port is 443, the client is making their request on port 443, and it's not intermittently responding on port 80.

Gemini3

Hi Gregg and James,

Thanks your suggestions.
I forgot to mention that the connections don't come from a browser but from a Java application.
The requesting URL is explicitly http://aaa.bbb....
Strange thing that all other customers don't report errors. Requests from that one customer are successful but suddenly fails for a while. I put a separate rule for his IP above other rules but no change.
If the requests fail there are no entries in the logs.
I'll dig in the logs tomorrow.

Gemini3

Took some time testing but still the same so far.

The requests from that customer work fine, but suddenly there is ab period of time alls requests fail.

I then put a second rule natting https-traffic to the destination on port 80, hoping that this will solve the issue.
The logs show, that https-traffic come is forwardet to the internal server on port 80. This was successful for a while but suddenly fails.
How ever, the customer insist that all requests are http.

Subsequent 3 lines from the logs which are successfull, regardless if http or https.
In the period 08:31:10 to 08:37:02 all requests from that customer fail while requests from other customers are successfull.
2020-10-02 08:31:10 FWAllow, Allowed, pri=4, disp=Allow, policy=HTTP.1-xxxxxx-00, protocol=http/tcp, src_ip=CustomerIP, src_port=42200, dst_ip=OurPublicIP, dst_port=80, dst_ip_nat=OurInternalIP, src_intf=0-External M-net LWL, dst_intf=500-Transfer, rc=100, pckt_len=60, ttl=56, pr_info=offset 10 S 2783462957 win 42340, 3000-0148
2020-10-02 08:37:02 FWAllow, Allowed, pri=4, disp=Allow, policy=HTTPS.1-xxxxxx-00, protocol=https/tcp, src_ip=CustomerIP, src_port=48510, dst_ip=OurPublicIP, dst_port=443, dst_ip_nat=OurInternalIP, dst_port_nat=80, src_intf=0-External M-net LWL, dst_intf=500-Transfer, rc=100, pckt_len=60, ttl=56, pr_info=offset 10 S 3767002128 win 14600, 3000-0148
2020-10-02 08:37:58 FWAllow, Allowed, pri=4, disp=Allow, policy=HTTP.1-xxxxxx-00, protocol=http/tcp, src_ip=CustomerIP, src_port=42834, dst_ip=OurPublicIP, dst_port=80, dst_ip_nat=OurInternalIP, src_intf=0-External M-net LWL, dst_intf=500-Transfer, rc=100, pckt_len=60, ttl=56, pr_info=offset 10 S 881825747 win 42340, 3000-0148

Here an example for a failed request (from a period of consecutive 8 Minutes of failed requests):
2020-10-02 11:33:02 FWAllow, Allowed, pri=4, disp=Allow, policy=HTTPS.1-xxxxxx-00, protocol=https/tcp, src_ip=CustomerIP, src_port=60642, dst_ip=OurPublicIP, dst_port=443, dst_ip_nat=OurInternalIP, dst_port_nat=80, src_intf=0-External M-net LWL, dst_intf=500-Transfer, rc=100, pckt_len=60, ttl=56, pr_info=offset 10 S 3185455728 win 14600, 3000-0148

Can it be that this is a wrong treatment of the Firebox (under certain conditions)?

Bruce_Briggs

dst_port=443 indicates that this incoming packet is HTTPS not HTTP.

Gemini3

Accidentally deleted the post :-(

Yes, but the customer insists that all requests are http Port 80.
After setting up the https-rule, the requests are successfull before they fail for a while.
This is the same behavior like before. Requests on port 80 for a single Customer are successful, then fail for a period of time, then are successfull again.

Gemini3

Set up a 2nd rule to forward https-traffic to the internal server on port 80.
The result is still the same. The Logs show http- and https-traffic, but the Customerinsists that all requests are http.

Three lines that show successfull request on both http- and https.
2020-10-02 08:31:10 FWAllow, Allowed, pri=4, disp=Allow, policy=HTTP.1-xxxxxx-00, protocol=http/tcp, src_ip=CustomerIP, src_port=42200, dst_ip=OurPublicIP, dst_port=80, dst_ip_nat=OurInternalIP, src_intf=0-External M-net LWL, dst_intf=500-Transfer, rc=100, pckt_len=60, ttl=56, pr_info=offset 10 S 2783462957 win 42340, 3000-0148
2020-10-02 08:37:02 FWAllow, Allowed, pri=4, disp=Allow, policy=HTTPS.1-xxxxxx-00, protocol=https/tcp, src_ip=CustomerIP, src_port=48510, dst_ip=OurPublicIP, dst_port=443, dst_ip_nat=OurInternalIP, dst_port_nat=80, src_intf=0-External M-net LWL, dst_intf=500-Transfer, rc=100, pckt_len=60, ttl=56, pr_info=offset 10 S 3767002128 win 14600, 3000-0148
2020-10-02 08:37:58 FWAllow, Allowed, pri=4, disp=Allow, policy=HTTP.1-xxxxxx-00, protocol=http/tcp, src_ip=CustomerIP, src_port=42834, dst_ip=OurPublicIP, dst_port=80, dst_ip_nat=OurInternalIP, src_intf=0-External M-net LWL, dst_intf=500-Transfer, rc=100, pckt_len=60, ttl=56, pr_info=offset 10 S 881825747 win 42340, 3000-0148

A line that show a failed request on https.
2020-10-02 11:33:02 FWAllow, Allowed, pri=4, disp=Allow, policy=HTTPS.1-xxxxxx-00, protocol=https/tcp, src_ip=CustomerIP, src_port=60642, dst_ip=OurPublicIP, dst_port=443, dst_ip_nat=OurInternalIP, dst_port_nat=80, src_intf=0-External M-net LWL, dst_intf=500-Transfer, rc=100, pckt_len=60, ttl=56, pr_info=offset 10 S 3185455728 win 14600, 3000-0148

Can it be that the Firebox treat, under certain conditions, traffic wrongly?

Bruce_Briggs

You can do packet captures on external using TCPDUMP.
With the advanced option, you can specify the source IP addr for the packet captures.
If the packet captures show that packet are in fact coming in as HTTPS - then the issue is with that client's setup somehow.

Gemini3

Thank you for pointing to TCPDump.
I have started it. However there might be not much to dump until next working day.

What is confusing to me, how can an identical request be sucessfull sometime and sometime fail.

Bruce_Briggs

If somehow the client PC starts sending HTTPS instead of HTTP, then one needs to find out how that is happening.
What is the web browser in use on this client, and are the others using the same web browser? A place to look.

Gemini3

Bruce, there is no client PC, the requests come automatically from an ERP system.

Gemini3

The cause was wrong requests from the other side.
After hours of investigation the sender conceded the requests has been sent wrongly.