Cloudflare is offering us more and more features especially for WordPress, be it APO (Automatic Platform Optimization for WordPress), the fastest DNS or the very interesting video on demand (Cloudflare Stream) at a great price (I will soon try it for a project, instead of Vimeo).
But if we have Cloudflare activated as a CDN proxy to take advantage of more benefits than those of its very fast DNS, among other features, we have the Firewall, where for example we can create an interesting rule to block attempts to access to xmlrpc.php before they reach our server, which as we can see, are many every day.
In addition to many other features of page rules, blocking by country, when we are under attack, etc., but the reason for this article is another, since detailing the features of Cloudflare would give for a full course.
The thing is that when we enable Cloudflare on our website with WooCommerce, in which we also use the Redsys payment method (use the excellent plugin from Conti), we do not receive notifications of paid order.
Here we could also go into a multitude of settings, such as having the SSL in Cloudflare set to “Full (strict)”, but let’s look at the main blockage that occurs from the Cloudflare Firewall and the easiest and quickest way to fix it.
If we go to Firewall -> General Information, we will see the Firewall Events window where we can see the blocking of the Redsys request. But if there are hundreds of records it will be difficult to locate, so we will hit the Add filter button, where we will select ASN -> equals -> 31627 (here is the quiz of the question):
And in the filtered results, we should see the blocked Redsys request, which by displaying its content will give us the clue to avoid future blockages:
As we can see in the action performed, this request has been blocked, so it has not reached our server and WooCommerce has not been able to find out that the payment has been made correctly.
We see that the user agent is Java/1.7.0, be careful with blocking this user agent in .htaccess, something that I have seen in several hostings to avoid visits of some robots, but we will also be blocking the request of Redsys.
This user agent a priori is suspicious for the Cloudflare Firewall and as we see in the following checked box, under Service, it does not pass the “Browser Integrity Check” so the request has been blocked.
But we still have one more piece of information and that is the Autonomous System Number or ASN “AS31627 SERMEPA-EN-AS”that if we make an inquiry https://dnschecker.org/asn-whois-lookup.php?query=31627 we will see that you belong to Redsys, or more precisely to the Redsys organization. “Servicios Para Medios De Pago S.A.” (defunct, formerly www.sermepa.es and now Redsys).
Well, we have finished, haven’t we, well, although at this point it is already very obvious, let’s look at the rule.
Click on Firewall -> Firewall rules -> button “Create a firewall rule”.
And in the new rule we give it the identifying name that we want (here I have used “AS31627 Redsys”).
In the section “When incoming requests match…” in “Field” we select “AS Num”, in “Operator” we select “is equal to” and finally in “Value” we write the ASN number which is “31627”.
Then, under “Select an action” we choose “Skip” and under “Choose a function” “Browser integrity check“.
With the creation of this rule, what we do is to check that if the ASN of the request is 31627, then we skip the browser integrity check.
Now we will have to make another test payment and see that we should indeed receive confirmation of the payment and that the request has not been blocked by Cloudflare.
Obviously if the Redsys ASN changes, we should update the rule, but this is not something that changes frequently (this ASN was created in 2004). We could also identify the request by IP (but it is easier to vary), by some string in the route (like the notificacion-redsys in the example), but identifying the request by the ASN is fast and reliable.
Another option would be to go to Firewall -> Settings and disable “Browser Integrity Check”, but we would be disabling it for all requests and it is much more appropriate to perform this selective disabling only in the case of Redsys.
