CSF/LFD blocking Authorize.net Relay URL

[severy]

We are using a reservations system on a new web site. The payment processing in that system uses a hosted payment form at Authorize.net, and when the payment is successfully completed Authorize.net submits a POST back to the reservation system to confirm the payment and retrieves a "Thank You" page from our web site and displays it to the customer. When the CSF/LFD firewall on the server is disabled, this process works exactly as advertised (the initial request is the retrieval of the transaction information to redirect to Authorize.net):

69.136.239.247 - - [20/Apr/2019:10:36:53 -0400] "GET /reservations/index.php?controller=pjFrontPublic&action=pjActionGetPaymentForm&locale=1&hide=0&index=7911&booking_id=79&payment_method=authorize HTTP/1.1" 200 631
198.241.206.38 - - [20/Apr/2019:10:37:22 -0400] "POST /reservations/index.php?controller=pjFrontEnd&action=pjActionConfirmAuthorize HTTP/1.1" 303 - "-" "-"
198.241.206.38 - - [20/Apr/2019:10:37:33 -0400] "GET /thank-you.html HTTP/1.1" 200 21870 "-" "-"

When the CSF/LFD firewall on the server is enabled , however, the POST request shows up in the log file 60 seconds after the payment is processed, and the "GET /thank-you.html" request is never received (and Authorize.net shows a timeout error 30 seconds after the payment is processed):

69.136.239.247 - - [20/Apr/2019:10:33:24 -0400] "GET /reservations/index.php?controller=pjFrontPublic&action=pjActionGetPaymentForm&locale=1&hide=0&index=5392&booking_id=78&payment_method=authorize HTTP/1.1" 200 630
198.241.206.38 - - [20/Apr/2019:10:33:46 -0400] "POST /reservations/index.php?controller=pjFrontEnd&action=pjActionConfirmAuthorize HTTP/1.1" 303 - "-" "-"

I have tried everything I can think of to troubleshoot this issue, with no success. I have added the "198.241.206.38" IP address to both csf.allow and csf.ignore and restarted CSF/LFD, with no success. There are also no entries in any log file related to blocks of that IP address.

What else could CSF/LFD be doing that would block those requests without recording any entry of that action anywhere?

Best Regards,

Randall Severy

[sawbuck]

Try whitelisting the IPs shown here:

https://support.authorize.net/s/article ... -Addresses

Other possibility is to confirm with authorize.net if any specific ports need to be opened.

[severy]

sawbuck,

Thank you for the response. Unfortunately, I have already whitelisted both of the IP addresses that Authorize.net lists in that page, and have also verified that those are the IP addresses that the requests come from when the firewall is turned off and the response is successful. The URL being requested is a standard https URL, and I have verified that it works properly when loaded manually in my browser,

Best Regards,

Randall

[severy]

I contacted Authorize.net and they confirmed that only access to port 443 is needed and that I was whitelisting the correct IP addresses. They did, however, supply the following URL for possible reasons the response was timing out:

https://support.authorize.net/s/article ... he-Request

The problem is that I can't identify any of those reasons as applying only when the CSF/LFD firewall is running. If there is a problem with one of them, it should also apply when the firewall is disabled, but it doesn't, the response is received just fine when the firewall is disabled. Does the CSF/LFD firewall care about User Agent headers? That's the only one I can think of that might apply.

Best Regards,

Randall

[severy]

In reviewing the possible reasons supplied by Authorize.net in more detail, I see the item listed as "Your domain's TLS certificate does not use Server Name Indication (SNI). Authorize.Net is unable to validate SNI certificates at this time." and determined that the site *is* using SNI. But I would think if that was causing the problem it wouldn't matter if the firewall was running or not, as that shouldn't affect the SSL certificate, or would it? Is there something in CSF/LFD that would prevent Authorize.net from validating the SSL certificate when the firewall is running, but the certificate would validate properly when the firewall is disabled?

Best Regards,

Randall