Issue Something is blocking PayPal IPN requests

[CHE]

Server operating system version

Ubuntu 18.04.6 LTS

Plesk version and microupdate number

18.0.59

Hello,

we use a plugin for WordPress that processes IPN requests from PayPal to enable the payment process.
Unfortunately, something is blocking these requests from PayPal, so the plugin doesn't work correctly.
Does anyone have experience with PayPal IPN and Plesk?
We use Plesk Obsidian 18.0.59 on Ubuntu 18.04.6 LTS.

I have already tried the following settings:
- Disabling Firewall
- Disabling Fail2Ban
- Disabling Nginx redirects

It is a dedicated root server from strato and the strange thing is, on my private virtual server with Ubuntu 20.04 also from strato it works without any problems.

Maybe anyone knows this problem and how to fix it.

Best regards

Lucas

 

[Martin Dias]

Did you check mod security too?

 

[WebHostingAce]

Have you set up the IPN URL in PayPal?

I'm not sure if you can request the IPN from Paypal. IPN is send by the Paypal to the website.

 

[CHE]

Did you check mod security too?

I don't know that we use that. I checked if there is an module for apache installed, but it doesn't.

 

[CHE]

Have you set up the IPN URL in PayPal?

I'm not sure if you can request the IPN from Paypal. IPN is send by the Paypal to the website.

No, it is all configured in the WordPress plugin and as i said, on another server it runs with the same code. It has to be a server or network problem.

 

[Bitpalast]

What's logged to access_ssl_log and error_log when the IPN is sent?

 

[CHE]

What's logged to access_ssl_log and error_log when the IPN is sent?

There nothing about this in access_ssl_log, or error_log. It seems to be, that the request is never reaching the server. On the other server the POST request is logged in proxy_access_ssl_log as following:

173.0.80.116 - - [03/May/2024:10:24:05 +0200] "POST /index.php?rtec-listener=IPN HTTP/1.1" 200 5 "-" "PayPal IPN ( https://www.paypal.com/ipn )"

I've read something about that the connection for IPN has to be always over TLS Version 1.2. Could it be something to do with that? I don't really know how to check this.

 

[Bitpalast]

Is the URL in Paypal configured correctly? They should show a log, too.

 

[CHE]

Is the URL in Paypal configured correctly? They should show a log, too.

Yes, everything is correct. It will try to request 8 times and end up without any status code. Extremely strange.

 

[Bitpalast]

What's the output of
grep 173.0 /var/log/fail2ban.log
and
iptables --list -n | grep 173.0.
?

 

[CHE]

What's the output of
grep 173.0 /var/log/fail2ban.log
and
iptables --list -n | grep 173.0.
?

Unfortunately nothing.

 

[Bitpalast]

Did you verify that the URL resolves to the correct server?

 

[CHE]

Did you verify that the URL resolves to the correct server?

Yes, i did. The URL is correct.

Isn't it the case that the request definitely have to be listed in the access log file when it arrived on the server? Independent of any apps and configurations on the server?
To me it looks like the problem is already in front of the server. I just opened a thread in the PayPal forum.

 

[WebHostingAce]

Yes, everything is correct. It will try to request 8 times and end up without any status code. Extremely strange.

On a browser, try to access the complete URL mentioned on the image you have provided then check the access log for this subscription.

Also you can use the website such as Postman to POST to this URL and see if there are any errors occurs.

 

[CHE]

Via browser the access log shows up the following:


Via postman send as POST-request and with message in body it says this:



And for comparison on the other server where it works:

 

[NetVicious]

Try disabling HTTP2 just for testing.

On Apache I needed to add "ProtocolsHonorOrder Off" because Paypal connects within HTTP 1.1 to your website. I don't know how to allow http2 but not enforce it to clients with only HTTP1.1 like Paypal.

 

[mow]

Try tcpdump port 443 and net 173.0 while PayPal is supposed to connect.
If that doesn't output anything, you know that the packets don't even reach your server, and you should ask Strato.