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
Related
I have docker and docker-compose installed on a VM with ubuntu22.04 where I run a container for nginx-proxy-manager with ipv6 working. I can add Proxy Host with an ipv4 and works fine, but if I add a proxy host with an ipv6. it doesn't work and only gives me 500 Internal Server Error. I can open the IPV6 to my browser and will see the content of the host, as well as pointing a domain to that ipv6 directly in cloudflare without any problem. does nginx-proxy-manager support ipv6 or is there a config that I needed to add. Also I can ping from my docker host to the ipv6 IP of webserver that I want to load
I have a create-react-app app running on localhost:3000 and a proxy server running on localhost:4000 that redirects some of my request to port 3000.
Requesting localhost:3000/ correctly returns index.html file,
Requesting localhost:4000/ returns connect ECONNREFUSED ::1:3000 with 502 code.
The exact same setup works properly on Ubuntu (returns index.html from localhost:4000) and Windows so I am sure proxy works fine.
Proxy is built using https://www.npmjs.com/package/http-proxy but i was unable to find any solution to this in documentation.
My question is: Does mac require changing some extra settings to allow this kind of traffic?
One solution is to edit /etc/hosts and remove ::1 localhost mapping or change it to ::1 ip6-localhost (default setting on ubuntu)
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
I wrote a simple http server in Go language as below:
http.ListenAndServe(":8888", http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
w.Write([]byte("hello"))
}))
When I test it on certain machine runs Windows 7, I found client can't connect to the server.
telnet 127.0.0.1 8888
connecting 127.0.0.1… can't open connection to the host. on port 8888: connect failed. (I translate it from Chinese.)
Then I got the results of other test case:
ping localhost and 127.0.0.1, successful.
telnet localhost 8888, successful.
telnet ::1 8888, successful.
netstat -ano | find "8888", the server has listened 0.0.0.0:8888 and :::8888.
Check the hosts file of OS, it's default configuration (nothing else).
Check the Network Adapter, it doesn't open IPV6 adapter.
The machine is in domain network.
The IP Security Policy is an empty list.
When I opened the MMC(Microsoft Management Console), I got a warning like this:
message box
It mean's:
Can't find resource "$(string.SiteDiscoveryEnableWMI)" (references in property displayName)
. File C:\windows\PolicyDefinitions\inetres.admx, line 64620, row 235
Anyone can tell me what's going on?
If XAMPP is running in your machine, the local server sometimes uses 127.0.0.1 as the default.
This could be the reason that ping localhost is working but telnet is not.
Otherwise check other network services or localservers you have running for any conflicts.
Cheers!
I've created SSH tunnels in the past, but I'm having trouble on OSX. I'm looking to take a website's port 80, and direct it to my localhost:8080. When I run this command
ssh -L 8080:<cloud_ip_address>:80 root#<cloud_ip_address> -N
I get the default apache 'it works!' page.
Why am I not getting the port 80 of the remote machine (which is running a web app)?
UPDATE
I still do not have a solution yet, but I have some more information. The page I am getting is the default page in /var/www/html but I am serving a Flask app which does not have static pages.
Because HTTP protocol contains not only the IP address, but also the hostname (the URL you type into your browser), which differs between the <cloud_hostname> and localhost. The easiest way to trick it is to create /etc/hosts (there will be some OSX alternative -- search ...) entry redirecting the hostname of your remote machine to localhost.
127.0.0.1 <cloud_hostname>
But note that in this case you will not be able to access the remote machine using the hostname!