(7) could not connect to host, but CURL is okay

[isaiah36]

I checked the dedicated IP of the site here

http://whatismyipaddress.com/blacklist-check

and here

http://www.mxtoolbox.com/blacklists.aspx

came up clean both places

[isaiah36]

Norton says the site is safe

http://safeweb.norton.com/report/sho...aheadwraps.com

and also AVG

http://www.avgthreatlabs.com/siterep...aheadwraps.com

nothing else for me to do except wait for the client to get an answer from Paypal.

[DrByte]

Hosting support says the Paypal IPs are reachable, no blocks on the firewall

root@s307 [/home/nilajah/public_html]# csf -g 216.113.188.10

Chain num pkts bytes target prot opt in out source destination
No matches found for 216.113.188.10 in iptables
root@s307 [/home/nilajah/public_html]# csf -g 66.211.168.126

Chain num pkts bytes target prot opt in out source destination
No matches found for 66.211.168.126 in iptables

Where they are resolving the name

paypal.com. 300 IN A 66.211.169.66
paypal.com. 300 IN A 66.211.169.3

It's too bad they aren't looking at the error details you've been posting, which clearly states that the URL your store needs to connect to is https://api-3t.paypal.com/nvp ... which won't the same address as the generic paypal.com

The csf / iptables check is only the firewall. It's nothing about name lookups.

[RodG]

Hosting support says the Paypal IPs are reachable, no blocks on the firewall

Where they are resolving the name

----------------------------------------------------------
paypal.com. 300 IN A 66.211.169.66
paypal.com. 300 IN A 66.211.169.3
--------------------------------------------------------

That's fine if you were using a webbrowser to go to the PayPal website. The thing is, that's not where your problem is.

(live transaction) --> https://api-3t.paypal.com/nvp

api-3t.paypal.com has address 173.0.88.69
api-3t.paypal.com has address 173.0.88.101
api-3t.paypal.com has address 173.0.84.69
api-3t.paypal.com has address 173.0.84.101

Go back and get 'em to check again.

[DrByte]

There are even more possible addresses than what RodG mentioned:
https://ppmts.custhelp.com/app/answers/detail/a_id/92

From http://www.zen-cart.com/wiki/index.php/PayPal

[DrByte]

It's important to note that a properly configured host wouldn't normally need ANY entries for PayPal as far as outbound communication is concerned.
And, for incoming, well, your site is a webserver, so you probably want incoming traffic from pretty much everywhere, except addresses which have proven themselves untrustworthy.

That is to say, if your host truly has no firewall addresses (in or out) for PayPal, then it starts suggesting what I mentioned before: that it's a namelookup / resolv problem, where the server's own ability to properly resolve names to addresses is broken or outdated because caching is foobar'd.

[RodG]

There are even more possible addresses than what RodG mentioned:

True, but api-3t.paypal.com only uses the 4 listed.... At least according to the DNS :)

I thought I'd give the OP's host a fighting chance... <g>

Curiously (not important for the OP or his host to know) the following two IP's
66.211.168.126
66.211.168.194
are listed by PayPal as also being used by api-3t.paypal.com, but they don't (or no longer) have a DNS entry for them.

That is to say, if your host truly has no firewall addresses (in or out) for PayPal, then it starts suggesting what I mentioned before: that it's a namelookup / resolv problem, where the server's own ability to properly resolve names to addresses is broken or outdated because caching is foobar'd.

I tend to agree...... Hmmm, depending on when the 66.211.x.x addresses got dropped by the DNS it is possible that this is when the OP's problems started (just thinking out loud).

Cheers
Rod.

[isaiah36]

# ping -c5 173.0.88.69
PING 173.0.88.69 (173.0.88.69) 56(84) bytes of data.

--- 173.0.88.69 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4000ms

root@s307 [~]# ping -c5 173.0.88.101
PING 173.0.88.101 (173.0.88.101) 56(84) bytes of data.

--- 173.0.88.101 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4000ms

root@s307 [~]# ping -c5 173.0.84.69
PING 173.0.84.69 (173.0.84.69) 56(84) bytes of data.

--- 173.0.84.69 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 3999ms

root@s307 [~]# ping -c5 173.0.84.101
PING 173.0.84.101 (173.0.84.101) 56(84) bytes of data.

--- 173.0.84.101 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1000ms

[RodG]

# ping -c5 173.0.88.69
PING 173.0.88.69 (173.0.88.69) 56(84) bytes of data.

--- 173.0.88.69 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4000ms

This doesn't really tell us anything useful.

Cheers
Rod

[RodG]

isaiah36

Q. Under your configuration->My_store settings, do you have an entry that reads: "cURL Proxy Status"? If so, make sure it is set to "False".

If this entry doesn't exist, try running the following SQL command
UPDATE `configuration` SET `configuration_value`= 'FALSE' WHERE `configuration_key` = 'CURL_PROXY_REQUIRED' ;

It has been a long time since ZenCart needed to use the proxy option (and then only for one particular host).
Current versions of zencart have removed this as an option because the host that shall be nameless removed the need for it. However, it has been noted that some auto-install scripts incorrectly set this value to 'true' and the only way to to set it back to false is via the SQL update command.

I make no guarantee that this will work, and I'm pretty much clutching at straws. It has been about a year since I've seen this 'fix' actually work, but it *is* a possibility that is pretty easy to eliminate.

Cheers
Rod