Loopback Connections not Enabeled

[MichaelT]

We have recently spun up an unmanaged VPS over at 20i. We have used dedicated servers before from another provider UKFAST.

On transferring our wordpress sites we are finding that background processing seems to having some problems, and its become apparent that this is due to loopback connections not being enabled at server level?

I have scoured the internet and have so far been unable to find out how to enable this, all documentation points the host resolving it, though in this case 20i have told us its something we would have to fix.

We have full root access and SSH has been set up for the server. is this something that can be enabled through WHM/Cpanel?

 

[cPRex]

Hey there - thanks for joining the forums!

You are correct that this needs to be setup or resolved by the hosting provider, as this operates at a level deeper than the cPanel & WHM software. We do have some additional details on that here, including a test you can perform if the system is using a NAT networking configuration:

Loopback NAT on this IP address appears to be defective

Symptoms You might see the following error in AutoSSL, or other errors or timeouts when trying to connect to your server's public IP address using curl, dig, or other software. Typically when this ...

support.cpanel.net

It might be helpful to direct the hosting provider to that article to see if they can offer any additional tweaks on their end for you.

 

[MichaelT]

Hi Rex,


Thanks for the fast reply!
We've actually sent a link to this thread to the host and two testing sites and they have come back with this: >>>

We've tested the loopbacks on the server and all seems to be fine:


[[email protected] ~]# ifconfig lo
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
packets 616373 bytes 337503341 (321.8 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 616373 bytes 337503341 (321.8 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0


is there anything else we can change or another setting we could be missing?

 

[cPRex]

I actually don't think that is related at all. There will always be a loopback interface that shows up in ifconfig. What happens if you run this command on the system?

dig @1.2.3.4 . NS

In this example, 1.2.3.4 is your server's public IP address.

 

[MichaelT]

I've just realised that the loopback connections are working on http connections - but not the https?

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7 <<>> 185.151.29.194 . NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 53167
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;185.151.29.194. IN A

;; AUTHORITY SECTION:
. 86393 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2020111300 1800 900 604800 86400

;; Query time: 14 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Nov 13 15:16:17 GMT 2020
;; MSG SIZE rcvd: 118

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23425
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;. IN NS

;; ANSWER SECTION:
. 84110 IN NS a.root-servers.net.
. 84110 IN NS b.root-servers.net.
. 84110 IN NS c.root-servers.net.
. 84110 IN NS d.root-servers.net.
. 84110 IN NS e.root-servers.net.
. 84110 IN NS f.root-servers.net.
. 84110 IN NS g.root-servers.net.
. 84110 IN NS h.root-servers.net.
. 84110 IN NS i.root-servers.net.
. 84110 IN NS j.root-servers.net.
. 84110 IN NS k.root-servers.net.
. 84110 IN NS l.root-servers.net.
. 84110 IN NS m.root-servers.net.

;; Query time: 3 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Nov 13 15:16:17 GMT 2020
;; MSG SIZE rcvd: 239

[[email protected] ~]# ^C
[[email protected] ~]#

 

[cPRex]

That's interesting as that does seem to work according to that output. It might be time to submit a ticket to our team so we can examine the system directly and see what's going on. If you do submit that ticket, please paste the number here so we can let everyone know what the ultimate resolution was.