Chrome port forwarding not working for https port - google-chrome

I went through this article to setup port forwarding in chrome.
Though I was able to work it out for non-secure (http) ports, I couldn't get it working for secure (https) ports. In both cases (http and https) the page loads in my laptop. just the https page doesn't load in my android phone.
Here is the configuration for http site.
And here is the configuration for https site.
Can someone please help?

It took me almost a week to find this workaround. You don't need to root your device, or use a proxy with this method.
You just need to port forward on chrome as you did and edit an android hosts file using Virtual Hosts. The apk is available under Virutal hosts releases in case the direct link does not work.
On your device, create a hosts.txt to map IP addresses to host names:
127.0.0.1 domain.com
127.0.0.1 subdomain.domain.com
Select your hosts file and turn it on! Then install certificates on your device.

Related

How to access a localhost website from another computer?

I am building my own website and I want to show my brother on the same network. But localhost is only on my computer... I think at least. Is there a way I ca nhost it on the network instead of my computer?
To access your localhost site from another computer, you can use the IP address of the computer on your local network where the site is located (for example: http://192.168.0.2/) instead of http://localhost/ or http://127.0.0.1/ which is the same thing.
If you are unable to do this due to a 404 or 403 error, check your web server configuration and/or firewall configuration.

Caddy on LAN only

I am trying to setup a reverse proxy with Caddy, I also want to use subdomains to point to my different services, so I bought a domain but the domain can only point to an ip-address, and my routers ip-address is not static so to solve that I registered a subdomain on Duckdns and that subdomain is pointing to my routers ip-address all the time, the subdomains on that I payed for have DNS set to point to Duckdns and I have opened port 80 & 443 on my router to point to my server machine that is running Caddy, the caddyfile simply have the domains I payed for point to localhost services.
It works but only on LAN, outside it does not work
If your public IP address is not the same as nslookup mydomain.duckdns.org; the problem is DNS. check your dynamic DNS
client's configuration file for inaccuracies. Restart your router and trial that it works as expected
If the IP addresses match, but you cannot make access from outside the network, its a port forwarding issue. Check port forwarding rules on your router, and opened ports on your server.
sudo ufw status verbose and sudo ss -ltnp are helpful server commands.
If the IP addresses match, but you cannot make access from inside
the network, hairpin NAT is the issue. This is a router issue. Buy
a more feature complete router from your ISP, or setup a local DNS
server to resolve this minor annoyance.
[Using your phone, enable WiFi for 'inside' type testing; disable WiFi for 'outside' type testing].

Browser tries to upgrade to HTTPS when accessing hosted server (dumb netcat binding) through domain name, but allows HTTP when using direct IP

I recently set up a Digital Ocean droplet and purchased a domain name. I have set up the AAAA record to point to the digital ocean droplet and have verified that the changes have propagated (for example, I can ssh to the server using the DNS name).
There is NO load balancer or firewall set up. The only digital ocean product I have set up is my droplet.
I noticed some bizarre behavior when running some tests.
I have tried several methods of serving HTTP content from the droplet, such as my personal site running in dotnet core and an express.js site.
However for this question I want to focus on the most basic example, to avoid the possibility that the request is being upgraded by a misconfigured server:
nc -l -p 1500 -c 'echo -e "HTTP/1.1 200 OK\n\n HELLO"'
When I navigate to the my droplet through my domain name (http://example.com:1500) , I see the netcat process finish executing in my droplet ssh session, and Chrome tells me:
This site can’t provide a secure connection. example.com sent an invalid response. ERR_SSL_PROTOCOL_ERROR.
I then see that the URL has somehow automatically changed to https//example.com:1500.
When I navigate to the droplet using the IP address (assuming my droplet IP is 12.34.56.78, I go to http://12.34.56.78:1500), I get the expected text "HELLO" displayed in the browser.
This result is the same in all browsers.
Why does making http requests to my droplet attempt upgrading to https, but only when going through the domain? Is this a browser behavior or something to do with Digital Ocean?
Thanks for taking the time to check out this question.
Figured it out. I have a .dev tld and chrome automatically upgrades all .dev tlds to HTTPS!
https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/
This was driving me crazy.

Apache2 Linux GoDaddy

Hi I'm new to website development and I am trying to configure a number of websites from my home based server using Apache2 and Linux Mint.
I have setup three new websites in addition to the 000-default page.I have created the Virtual Host config files in sites-available and have added the sites to Host.conf. Internally(on the server in a browser) they are all working fine - I can access all four sites using localhost or the URLs I've configured them with -tested with and without the www. prefix and all seems fine. The four sites are just basic HTML scripts with different headers and different one line body.
I've added Listen 8090 to Listen 80 on my ports.conf file and have opened port 80 and 8090 on my firewall and have updated Port Forwarding on my router and tested they are open using PortCheckTool. The two ports are open and every other port is locked out so that seems good too.
I've tried to configure a GoDaddy domain name to direct activity to one of these sites. The domain name that works internally (on the server in a browser) is the same as my GoDaddy domain name I've bought. I've been into my GoDaddy account and pointed this domain at my external IP address (tried also adding port to forwarding 8090 as well as leaving port number as default). However when I access this domain from my mobile phone using 3G with WIFI turned off I just get sent to the 000-default homepage.Same using default Port 80 and with Port Forwarding to 8090. I have script for both 80 and 8090 in my site config files in sites-available directory.
So the connection is getting to the server, ports are OK, it's just that apache2 doesn't redirect the GoDaddy traffic but redirects fine locally on the server for the same site!?
Any ideas what I am missing?
Any help would be much appreciated.
Thanks.

Cannot access Google Cloud Compute Instance External IP

I have set up an Google Cloud Compute Instance:
Machine type
n1-standard-1 (1 vCPU, 3.75 GB memory)
CPU platform
Intel Haswell
Zone
us-east1-c
I can ssh in using the external address.
I have installed the vncserver and can access it on port 5901 from localhost as well as the internal IP.
I am trying to access it from the static, external IP address but it is not working.
I have configured the firewall to open to port to 0.0.0.0/0, but it is not reachable.
Can anyone help?
------after further investigation from the tips from the two answers (thanks, both!), I have a partial answer:
The Google Cloud Compute instance was set, by default, to not allow
HTTP traffic. I reset the configuration to allow HTTP traffic. I
then tried the troubleshooting tip to run a small HTTP service in
python. I was able to get a ressponse from the service over the
internet.
The summary of the current situation is as follows:
The external IP address can be reached
It is enabled and working for SSH
It is enabled and working for HTTP
It does not seem to allow traffic from vncserver
Any idea how to configure the compute instance to allow for vncserver traffic?
If you already verified that Google Firewall or your VM are not blocking packets, you must make sure that VNC service is configured to listen on the external IP address.
You can always use a utility like nmap outside Google project to reveal information on the port status.
enable http/https traffic form the firewall as per the need. it will work!!
The Google Cloud Compute instance was set, by default, to not allow HTTP traffic. I reset the configuration to allow HTTP traffic. I then tried the troubleshooting tip to run a small HTTP service in python. I was able to get a response from the service over the internet.
As such, the original question is answered, I can access Google Cloud Compute Instance External IP. My wider issue is still not solved, but I will post a new, more specific question about this issue
TLDR: make sure you are requesting http not https
In my case i was following the link from my CE instance's External Ip property which takes you directly to the https version and i didn't set up https, so that was causing the 'site not found' error.
Create an entry in your local ssh config file as below with mentioned local forward port. In my case its an example of yarn's IP, which I want to access in browser.
Host hadoop
HostName <External-IP>
User <Local-machine-username>
IdentityFile ~/.ssh/<private-key-for-above-user>
LocalForward 8089 <Internal-IP>:8088
In addition to having the firewall rules to allow HTTP traffic in both Google Cloud Platform and within the OS of the instance, make sure you install a web server such as Apache or Nginx.
After installing the web server, you connect to the instance using SSH and verify you do not get a failed connection with the following command:
$ sudo wget http://localhost
If the connection is positive, it means that you can access your external URL:
http://<IP-EXTERNAL-VM>
Usually there are two main things to check.
1. Port
By default, only port 80, 443 and ICMP are exposed. If your server is running on a different port, create a record for the same.
2. Firewall
Make sure you are allowing http and https traffic based on your need.
oua re
For me the problem was that I set up the traffic for the firewall rule to be 'Egress' instead of 'Ingress'.
If anyone already initiated 'https'
just disable it and check again.