Comments
-
The cause was wrong requests from the other side. After hours of investigation the sender conceded the requests has been sent wrongly.
-
Reboot helped. Thank you Bruce. Yes, dump to file might be a better choice.
-
Bruce, there is no client PC, the requests come automatically from an ERP system.
-
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.
-
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,…
-
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,…
-
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…
-
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…
-
LDAP signing and LDAPS are different. LDAPS requires certificates. Using it entails a siew of changes (CA etc.). Activating LDAPS in AD settings leads to authentication failure.
-
Bruce, you're absolutely right. Got wrong IP from the Service Provider :/ Now it works like a charm.
-
I just add our SSLVPN 192.168.113.0/24 even the range is already include in 192.168.0.0/16.
-
It seems to work. We can test more tomorrow. Thank you! The SSLVPN net was not in the DNAT settings.