I'm trying to make an FTP connection to 3 web sites on the same server via a PHP script. It works fine for 2 of the sites, but the 3rd I get the following error (and it doesn't appear to be temporary):
"Warning: ftp_connect() [function.ftp-connect]: php_network_getaddresses: getaddrinfo failed: This is usually a temporary error during hostname resolution and means that the local server did not receive a response from an authoritative server"
This code snippet is where it fails:
$server = 'ftp.'.$ftp_server;
$conn_id = ftp_connect($server) OR die("<br>unable to establish an FTP connection");
I'm hoping someone can point me in the right direction.
Regards to all
That means the DNS lookup for the ftp server's name (e.g. example.com) failed to resolve and the IP address could not be determined.
This could either be from your remote site's DNS servers being down, or the domain itself is misconfigured and is pointing at non-existing/unreachable DNS servers.
Perhaps the DNS servers for that specific host are down; check whois records for the domain to discover which DNS servers are authoritative, then check each one of them in turn with host to make sure they all resolve.
For example, whois stackoverflow.com:
Name Servers:
ns1.serverfault.com
ns2.serverfault.com
ns3.serverfault.com
Then:
$ host www.stackoverflow.com ns1.serverfault.com
Using domain server:
Name: ns1.serverfault.com
Address: 64.34.119.33#53
Aliases:
www.stackoverflow.com is an alias for stackoverflow.com.
stackoverflow.com has address 64.34.119.12
stackoverflow.com mail is handled by 10 STACKOVERFLOW.COM.S9A1.PSMTP.com.
stackoverflow.com mail is handled by 20 STACKOVERFLOW.COM.S9A2.PSMTP.com.
stackoverflow.com mail is handled by 30 STACKOVERFLOW.COM.S9B1.PSMTP.com.
stackoverflow.com mail is handled by 40 STACKOVERFLOW.COM.S9B2.PSMTP.com.
$ host www.stackoverflow.com ns2.serverfault.com
Using domain server:
Name: ns2.serverfault.com
Address: 64.34.119.34#53
Aliases:
www.stackoverflow.com is an alias for stackoverflow.com.
stackoverflow.com has address 64.34.119.12
stackoverflow.com mail is handled by 30 STACKOVERFLOW.COM.S9B1.PSMTP.com.
stackoverflow.com mail is handled by 40 STACKOVERFLOW.COM.S9B2.PSMTP.com.
stackoverflow.com mail is handled by 10 STACKOVERFLOW.COM.S9A1.PSMTP.com.
stackoverflow.com mail is handled by 20 STACKOVERFLOW.COM.S9A2.PSMTP.com.
$ host www.stackoverflow.com ns3.serverfault.com
Using domain server:
Name: ns3.serverfault.com
Address: 69.59.196.217#53
Aliases:
www.stackoverflow.com is an alias for stackoverflow.com.
stackoverflow.com has address 64.34.119.12
stackoverflow.com mail is handled by 30 STACKOVERFLOW.COM.S9B1.PSMTP.com.
stackoverflow.com mail is handled by 40 STACKOVERFLOW.COM.S9B2.PSMTP.com.
stackoverflow.com mail is handled by 10 STACKOVERFLOW.COM.S9A1.PSMTP.com.
stackoverflow.com mail is handled by 20 STACKOVERFLOW.COM.S9A2.PSMTP.com.
$
All three servers responded to requests for www.stackoverflow.com, so all three servers are functional.
Related
I am using mountebank for mocking responses which is running in Docker on port 2525. Stubs are created on port 443. The response is successful when I use localhost but not with the domain name. The domain names are redirected in hosts file.
OS: Windows 10 Pro
Failed to hit mock with the domain name
Hosts File
Postman console error
Wireshark log for the domain name
Successful localhost logs which uses IPV6 internally
Postman Successful Response
Successful response console details
Wireshark logs for localhost
This issue is resolved by redirecting all domain names to ipv6 address.
Also listening to ipv6 address using netsh command. Referred to Can't access 127.0.0.1
netsh http add iplisten 127.0.0.1
I'm having a hard time to finalize a first working configuration with IPsec.
I want to have a IPsec server that creates a network with its clients, and I want the clients to be able to communicate each other through the server. I'm using Strongswan on both server and clients, and I'll have a few clients with other IPsec implementations.
Problem
So the server is reachable at 10.231.0.1 for every clients and the server can ping the clients. It works well. But the clients cannot reach each other.
Here is an output of tcpdump when I try to ping 10.231.0.2 from 10.231.0.3
# tcpdump -n host 10.231.0.3
[..]
21:28:49.099653 ARP, Request who-has 10.231.0.2 tell 10.231.0.3, length 28
21:28:50.123649 ARP, Request who-has 10.231.0.2 tell 10.231.0.3, length 28
I thought of farp plugin, mentionned here : https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling but the ARP request is not making its way to the server, it stays local.
Information
Server ipsec.conf
config setup
charondebug="ike 1, knl 1, cfg 0"
uniqueids=no
conn ikev2-vpn
auto=add
compress=no
type=tunnel
keyexchange=ikev2
fragmentation=yes
forceencaps=yes
dpdaction=clear
dpddelay=300s
esp=aes256-sha256-modp4096!
ike=aes256-sha256-modp4096!
rekey=no
left=%any
leftid=%any
leftcert=server.crt
leftsendcert=always
leftsourceip=10.231.0.1
leftauth=pubkey
leftsubnet=10.231.0.0/16
right=%any
rightid=%any
rightauth=pubkey
rightsourceip=10.231.0.2-10.231.254.254
rightsubnet=10.231.0.0/16
Client ipsec.conf
config setup
charondebug="ike 1, knl 1, cfg 0"
uniqueids=no
conn ikev2-vpn
auto=route
compress=no
type=tunnel
keyexchange=ikev2
fragmentation=yes
forceencaps=yes
dpdaction=clear
dpddelay=60s
esp=aes256-sha256-modp4096!
ike=aes256-sha256-modp4096!
rekey=no
right=server.url
rightid=%any
rightauth=pubkey
rightsubnet=10.231.0.1/32
left=%defaultroute
leftid=%any
leftauth=pubkey
leftcert=client.crt
leftsendcert=always
leftsourceip=10.231.0.3
leftsubnet=10.231.0.3/32
There should be nothing special or relevant in Strongswan's & charon's configuration file, but I can provide them if you think that could be usefull.
I've taken a few shortcuts in the configuration : I'm using VirtualIP but I'm not using a DHCP plugin or anything to distribute the IP. I'm setting the IP address manually on the clients like so :
ip address add 10.231.0.3/16 dev eth0
And here is a routing table on the client's side (automatically set like that by adding the IP and by Strongswann for the table 220) :
# ip route list | grep 231
10.231.0.0/16 dev eth0 proto kernel scope link src 10.231.0.3
# ip route list table 220
10.231.0.1 via 192.168.88.1 dev eth0 proto static src 10.231.0.3
I've also played with iptables and this rule
iptables -t nat -I POSTROUTING -m policy --pol ipsec --dir out -j ACCEPT
On both client and server, because I understood that could be a problem if I have MASQUERADE rules already set, but that did not changed anything.
I've also set those kernel parameters through sysctl on both client and server side :
sysctl net.ipv4.conf.default.accept_redirects=0
sysctl net.ipv4.conf.default.send_redirects=0
sysctl net.ipv4.conf.default.rp_filter=0
sysctl net.ipv4.conf.eth0.accept_redirects=0
sysctl net.ipv4.conf.eth0.send_redirects=0
sysctl net.ipv4.conf.eth0.rp_filter=0
sysctl net.ipv4.conf.all.proxy_arp=1
sysctl net.ipv4.conf.eth0.proxy_arp=1
sysctl net.ipv4.ip_forward=1
Lead 1
This could be related to my subnets declared in /32 in my client's configurations. At first I declared the subnet in /16 but I could not connect two clients with this configuration. The second client was taking the whole traffic for itself. So I understood I should limit the traffic selectors and this is how I did it but maybe I'm wrong.
Lead 2
This could be related to my way of assigning IP manually, and the mess it can introduce in the routing table. When I play with the routing table manually assigning gateway (like the public IP of the client as a gateway) then the ARP in TCPdump disappear and I see the ICMP request. But absolutely nothing on the server.
Any thoughts on what I've done wrong ?
Thanks
I am trying to generate certificate for my domain. I can ping my domain but still getting error. I have added inbound firewall rule to my digital ocean server to accept port 80 on ipv4 and ipv6 as well. Not sure what is wrong. [Note: my nginx server is not running as I cannot get the certificate]
https://community.letsencrypt.org/t/invalid-response-404-nginx-docker-container/102525
My domain is: www.1040nra.com
I ran this command: sudo certbot certonly --staging --webroot -w /root/dt-app-data/ -d 1040nra.com -d www.1040nra.com
It produced this output:
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for 1040nra.com
http-01 challenge for www.1040nra.com
Using the webroot path /root/dt-app-data for all unmatched domains.
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. 1040nra.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://1040nra.com/.well-known/acme-challenge/22AD-KFmF62z373CPiUKzk6dlr-0s5wMOmnmrziMqd4: Connection refused, www.1040nra.com (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://www.1040nra.com/.well-known/acme-challenge/ba-jjDhBUZJ9fHLofGfDYSVV5a-ETlX26A64A-2Yu0s: Connection refused
IMPORTANT NOTES:
The following errors were reported by the server:
Domain: 1040nra.com
Type: connection
Detail: Fetching
http://1040nra.com/.well-known/acme-challenge/22AD-KFmF62z373CPiUKzk6dlr-0s5wMOmnmrziMqd4:
Connection refused
Domain: www.1040nra.com
Type: connection
Detail: Fetching
http://www.1040nra.com/.well-known/acme-challenge/ba-jjDhBUZJ9fHLofGfDYSVV5a-ETlX26A64A-2Yu0s:
Connection refused
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A/AAAA record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you’re using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
My web server is (include version):
The operating system my web server runs on is (include version): ubuntu 18.04
You seem to have solved the problem yourself.
This is because the certbot domain cannot verify the DNS A record.
Make sure your domain address is directed to your server's ip address.
If you made the dns change 'recently', it may take some time to delete the old ip address.
https://www.whatsmydns.net/
Check here, there should only be one IP address and this should be your server's IP address.
Make sure ports 80 and 443 are open by running the command below:
sudo ufw status
If port 443 is not open, then run the command bellow to allow port 443:
sudo ufw allow https
Issue: The issue is your domain might be not pointing to your Cloud host IP and DNS setup
Solution:
You have to map your domain and IP in-network option tab A
Once you did the mapping then you have to setup DNS on where you have purchased the domain website.
Then check by entering your domain name on this web site www.whatsmydns.net showing your IP address or not
If Yes then you create the certificate
Go to the https://www.whatsmydns.net/
Enter your host name
You set the type A
Make sure that there is the same IP everywhere
You set the type AAAA
Make sure there are no AAAA entries
AAAA are IPv6 entries.
If the addresses for AAAA are present, make a request to this IPv6 address
#example curl [43ff:0c89:eb10:4c06:c90e:4b7d:64e5:fbe1]
curl [your IPv6]
If you get an error, then the address does not point to your site. Accordingly, there is a difference between IPv4 and IPv6.
Solution: delete the domain zone type AAAA
So I got a problem regarding access to my website. Whenever I run traceroute on my computer it returns the correct traceroute to the correct site. However when I run it on someone elses pc it gives a completely different traceroute but wrong traceroute (an old one).
Some info that might help:
- My PC: Windows
- His PC: Mac
We both loaded the sites a few times before and he is still on the old traceroute from a couple of months back.
I already tried clearing the DNS server of Mac OS X, Rebooting it, Clearing browser cache (even a full reset of the browsers) and still it is not loading in any of the browsers.
if IP address of remote website is different, try to manually set DNS server to check if it solves the problem
static DNS can be changed with nslookup (windows, maybe on mac also)
you can set manual DNS by the 'server' command in nslookup prompt :
C:\Users\me>nslookup
Default Server: nfdns.bezeqint.net
Address: 192.117.235.235
> www.stackoverflow.com
# this is my dns
Server: nfdns.bezeqint.net
Address: 192.117.235.235
Non-authoritative answer:
Name: stackoverflow.com
Addresses: 104.16.37.249
# changing dns server
> server 1.2.3.4
Default Server: [1.2.3.4]
Address: 1.2.3.4
# now can check again with the new dns
> www.stackoverflow.com
Just found it, I overlooked the /etc/hosts file, so there was still an error in it. Thanks for helping!
This is a very basic Amazon EC2 question, but I'm stumped so here goes.
I want to launch an Amazon EC2 instance and allow access to HTTP on ports 80 and 8888
from anywhere. So far I can't even allow the instance to connect to on those ports using
its own IP address (but it will connect to localhost).
I configured the "default" security group for HTTP using the standard HTTP option on the management console (and also SSH).
I launched my instance in the default security group.
I connected to the instance on SSH port 22 twice and in one window launch an HTTP server
on port 80. In the other window I verify that I can connect to HTTP using the "localhost".
However when I try to access HTTP from the instance (or anywhere else) using either the public DNS or the Private IP address I het "connection refused".
What am I doing wrong, please?
Below is a console fragment showing the wget that succeeds and the two that fail run from the instance itself.
--2012-03-07 15:43:31-- http://localhost/
Resolving localhost... 127.0.0.1
Connecting to localhost|127.0.0.1|:80... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: /__whiff_directory_listing__ [following]
--2012-03-07 15:43:31-- http://localhost/__whiff_directory_listing__
Connecting to localhost|127.0.0.1|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: “__whiff_directory_listing__”
[ <=>
] 7,512 --.-K/s in 0.03s
2012-03-07 15:43:31 (263 KB/s) - “__whiff_directory_listing__” saved [7512]
[ec2-user#ip-10-195-205-30 tmp]$ wget http://ec2-50-17-2-174.compute-1.amazonaws.com/
--2012-03-07 15:44:17-- http://ec2-50-17-2-174.compute-1.amazonaws.com/
Resolving ec2-50-17-2-174.compute-1.amazonaws.com... 10.195.205.30
Connecting to ec2-50-17-2-174.compute-1.amazonaws.com|10.195.205.30|:80... failed:
Connection refused.
[ec2-user#ip-10-195-205-30 tmp]$ wget http://10.195.205.30/
--2012-03-07 15:46:08-- http://10.195.205.30/
Connecting to 10.195.205.30:80... failed: Connection refused.
[ec2-user#ip-10-195-205-30 tmp]$
The standard tcp sockets interface requires that you bind to a particular IP address when you send or listen. There are a couple of somewhat special addresses: localhost (which you're probably familiar with) which is 127.0.0.1. There's also a special address, 0.0.0.0 or INADDR_ANY (internet protocol, special shorthand for ANY ADDRESS). It's a way to listen on ANY or more commonly, ALL addresses on the host. This is a way to tell the kernel/stack that you're not interested in a particular IP address.
So, when you're setting up a server that listens to "localhost" you're telling the service that you want to use the special reserved address that can only be reached by users of this host, and while it exists on every host, making a connection to localhost will only ever reach the host you're making the request from.
When you want a service to be reachable everywhere (on a local host, on all interfaces, etc.) you can specify 0.0.0.0.
(0) It's silly but the first thing you need to do is to make sure that your web server is running.
(1) You need to edit your Security Group to let incoming HTTP packets access your website. If your website is listening on port 80, you need to edit the Security Group to open access to port 80 as mentioned above. If your website is listening on some other port, then you need to edit the Security Group to access that other port.
(2) If you are running a Linux instance, the iptables firewall may be running by default. You can check that this firewall is active by running
sudo service iptables status
on the command line. If you get output, then the iptables firewall is running. If you get a message "Firewall not running", that's pretty self-explanatory. In general, the iptables firewall is running by default.
You have two options: knock out the firewall or edit the firewall's configuration to let HTTP traffic through. I opted to knock out the firewall as the simpler option (for me).
sudo service iptables stop
There is no real security risk in shutting down iptables because iptables, if active, merely duplicates the functionality of Amazon's firewall, which is using the Security Group to generate its configuration file. We are assuming here that Amazon AWS doesn't misconfigure its firewalls - a very safe assumption.
(3) Now, you can access the URL from your browser.
(4) The Microsoft Windows Servers also run their personal firewalls by default and you'll need to fix the Windows Server's personal firewall, too.
Correction: by AWS default, AWS does not fire up server firewalls such iptables (Centos) or UAF (Ubuntu) when you are ordering the creation of new EC2 instances - That's why EC2 instances that are in the same VPC can ssh into each other and you can "see" the web server that you fired up from another EC2 instance in the same VPC.
Just make sure that your RESTful API is listening on all interfaces i.e. 0.0.0.0:portID
As you are getting connection refused (packets are being rejected) I bet it is iptables causing the problem. Try to run
iptables -I INPUT -p tcp --dport 80 -j ACCEPT
iptables -I INPUT -p tcp --dport 8888 -j ACCEPT
and test the connection.
You will also need to add those rules permanently which you can do by adding the above lines into ie. /etc/sysconfig/iptables if you are running Red Hat.
Apparently I was "binding to localhost" whereas I needed to bind to 0.0.0.0 to respond to port 80 for the all incoming TCP interfaces (?). This is a subtlety of TCP/IP that I don't fully understand yet, but it fixed the problem.
Had to do the following:
1) Enable HTTP access on the instance config, it wasn't on by default only SSH
2) Tried to do nodejs server, so port was bound to 80 -> 3000 did the following commands to fix that
iptables -F
iptables -I INPUT -p tcp --dport 80 -j ACCEPT
sudo service iptables-persistent flush
Amazon support answered it and it worked instantly:
I replicated the issue on my end on a test Ubuntu instance and was able to solve it. The issue was that in order to run Tomcat on a port below 1024 in Ubuntu/Unix, the service needs root privileges which is generally not recommended as running a process on port 80 with root privileges is an unnecessary security risk.
What we recommend is to use a port redirection via iptables :-
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
I hope the above information helps.