Accessing NextJS running on WSL2 over the network - next.js

I want to access my NextJs dev server running on WSL2 on my local network.
I added port 3000 to firewall rules and tested with telnet and it was not immediately accessible.
After some research I found this document: https://learn.microsoft.com/en-us/windows/wsl/networking
So I ran on my WSL2 instance:
cat /etc/resolv.conf
# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
# [network]
# generateResolvConf = false
nameserver 172.23.16.1
I confirmed the WSL2 IP address is correct by pinging from host machine:
ping 172.23.16.1
Pinging 172.23.16.1 with 32 bytes of data:
Reply from 172.23.16.1: bytes=32 time<1ms TTL=128
Reply from 172.23.16.1: bytes=32 time<1ms TTL=128
Reply from 172.23.16.1: bytes=32 time<1ms TTL=128
Reply from 172.23.16.1: bytes=32 time<1ms TTL=128
Then using that IP to run this command on the windows 11 host from an elevated prompt:
netsh interface portproxy add v4tov4 listenport=3000 listenaddress=0.0.0.0 connectport=3000 connectaddress=172.23.16.1
Now I am able to telnet into the windows host on 192.168.0.50:3000 (this is local IP of host) but there is no helo and if I try to access it via web browser I get ERR_EMPTY_RESPONSE
The proxy port appears to be there:
netsh interface portproxy show v4tov4
Listen on ipv4: Connect to ipv4:
Address Port Address Port
--------------- ---------- --------------- ----------
0.0.0.0 3000 172.23.16.1 3000
I tried adding a few more proxy ports
Listen on ipv4: Connect to ipv4:
Address Port Address Port
--------------- ---------- --------------- ----------
0.0.0.0 3000 172.23.16.1 3000
192.168.0.50 3000 172.23.16.1 3000
127.0.0.1 3000 172.23.16.1 3000
Still getting ERR_EMPTY_RESPONSE over the LAN. I can connect via telnet to the port so I'm guessing it's something to do with the WSL2 Ubunto 20.04 installation.
I am not sure why I cant access it. There is no firewall active in WSL2
ufw status
Status: inactive
If I try to access localhost:3000 on host machine it works. If I try to access http://192.169.0.50:3000/ on host machine I get the error so there has to be a binding missing somewhere but I don't know where.
How can I debug this?

The docs seem to be incorrect. ipconfig and the resolv.conf seem to show wrong IP address.
To get the correct IP address I needed to use: wsl hostname -I from powershell

Related

Unable to reach Google Compute over port 9000

I have a google compute running CentOS 7, and I wrote up a quick test to try and communicate with it over port 9000 (from my home PC) - but I'm unexpectedly getting network errors.
This happens both with my test script (which attempts to send a payload) and even with plink.exe (which I'm just using to check the port availability).
>plink.exe -v -raw -P 9000 <external_IP>
Connecting to <external_IP> port 9000
Failed to connect to <external_IP>: Network error: Connection refused
Network error: Connection refused
FATAL ERROR: Network error: Connection refused
I've added my external IP to googles firewall (https://console.cloud.google.com/networking/firewalls) and set to allow ingress traffic over port 9000 (it's the lowest priority, at 1000)
I also updated firewalld in CentOS to allow TCP traffic over the port:
Redirecting to /bin/systemctl start firewalld.service
[foo#bar ~]$ sudo firewall-cmd --zone=public --add-port=9000/tcp --permanent
success
[foo#bar ~]$ sudo firewall-cmd --reload
success
I've confirmed my listener is running on port 9000
[foo#bar ~]$ netstat -npae | grep 9000
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp 0 0 127.0.0.1:9000 0.0.0.0:* LISTEN 1000 18381 1201/python3
By default, CentOS 7 doesn't use iptables (just to be sure, I confirmed it wasn't running)
Am I missing something?
NOTE: Actual external IP replaced with <external_IP> placeholder
Update:
If I nmap my listener over port 9000 from the CentOS 7 compute instance over a local IP, like 127.0.0.1 I get some results. Interestingly, if I make the same nmap call over the servers external IP -- nadda. So this has to be a firewall, right?
external call
[foo#bar~]$ nmap <external_IP> -Pn
Starting Nmap 6.40 ( http://nmap.org ) at 2020-05-25 00:33 UTC
Nmap scan report for <external_IP>.bc.googleusercontent.com (<external_IP>)
Host is up (0.00043s latency).
Not shown: 998 filtered ports
PORT STATE SERVICE
22/tcp open ssh
3389/tcp closed ms-wbt-server
Nmap done: 1 IP address (1 host up) scanned in 4.87 seconds
Internal Call
[foo#bar~]$ nmap 127.0.0.1 -Pn
Starting Nmap 6.40 ( http://nmap.org ) at 2020-05-25 04:36 UTC
Nmap scan report for localhost (127.0.0.1)
Host is up (0.010s latency).
Not shown: 997 closed ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
9000/tcp open cslistener
Nmap done: 1 IP address (1 host up) scanned in 0.10 seconds
In this case software running on the backend VM must be listening any IP (0.0.0.0 or ::), your's is listening to "127.0.0.1:9000" and it should be "0.0.0.0:9000".
The way to fix that it's to change the service config to listen to 0.0.0.0 instead of 127.0.0.1 .
Cheers.

az login returns error "Failed to establish a new connection: [Errno -3] Temporary failure in name resolution"

I was doing az login from WSL of my windows machine. Then it gives an error:
Please ensure you have network connection. Error detail: HTTPSConnectionPool(host='login.microsoftonline.com', port=443): Max retries exceeded with url: /common/oauth2/token (Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection object at 0x7f401d135630>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution',))
I hope this is a DNS issue.
So I checked /etc/resolv.conf of WSL:
# This file was automatically generated by WSL. To stop automatic generation of this file, remove this line.
nameserver 192.168.1.1
nameserver fcc0:0:0:ffff::1
nameserver fcc0:0:0:ffff::2
192.168.1.1 is the default gateway.
There are the results of some commands I tried:
$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=128 time=0.351 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=128 time=0.888 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=128 time=0.883 ms
$ dig 192.168.1.1
; <<>> DiG 9.11.3-1ubuntu1.3-Ubuntu <<>> 192.168.1.1
;; global options: +cmd
;; connection timed out; no servers could be reached
$ nslookup 192.168.1.1
;; connection timed out; no servers could be reached
These commands also give an output that indicates an issue.
Ping google.com
dig google.com
All these commands( or its alternatives) work from the Windows command prompt works correctly.
I found a workaround here:
https://askubuntu.com/questions/91543/apt-get-update-fails-to-fetch-files-temporary-failure-resolving-error
It says that I should add the followinng line to /etc/resolv.conf. If I try it like this, it works.
nameserver 192.168.1.1
nameserver 8.8.8.8
nameserver fcc0:0:0:ffff::1
nameserver fcc0:0:0:ffff::2
After this, the ping google.com and dig google.com works fine. But I can see that the nameserver it uses to resolve is 8.8.8.8.
If I connect to VPN, it adds our own nameservers to /etc/resolv.conf and after that, there is no problem in resolving the URLs. Once the VPN is disconnected, the issue arises again.
Note:
There were no issues like this before.
Last day we changed our router in order to use a new ISP's connection and after that, the issue occurs.
Other machines in the same network don't have this issue.
Why this occurs and How can I properly fix this issue of WSL?
Why only one machine in our network can ping, but can't dig to the default gateway?
Update:
I can see that there are two entries that are marked as default in routing table:
$ ip route show table all | grep default
none default via 192.168.0.1 dev wifi0 proto unspec metric 0
none default via 192.168.1.1 dev eth6 proto unspec metric 0

neo4 WebSocket connection to 'ws://localhost:7687/' failed: Establishing a tunnel via proxy server failed

I have neo4j community server edition 3.4.5 and which will be giving me "WebSocket connection to 'ws://localhost:7687/' failed".
I found some solution to work in firefox, chrome, IE but those are temporary solutions which work. but I don't think that just by passing proxy would be a permanent solution.
It is not working if connected to VPN(office network), otherwise working. What could be a reason for this error within an office network? How to resolve this issue.
Any idea or suggestions, Please
There can be several reasons for this issue and I probably need to know more about your setup before I can pin point the problem.
1 check:
Disconnect from the VPN, and open a command prompt (Windows+R then write cmd and press enter)
Use either telnet or putty ( https://www.putty.org/ ) and connect to 127.0.0.1 port 7687:
telnet 127.0.0.1 7687
See if you a response like this:
GET / HTTP/1.0
2 check:
Go to you proxy settings and see if you have a proxy enabled:
Firefox: Preferences/Options > Advanced > Network > Settings
IE: Tools > Options > Connections > Lan Settings
Suggest to turn off your proxy and do the check in check 1 again.
3 check:
Connect to your VPN and do the check 1 part once again
Check for error messages (that you probably would get) and then write in the command prompt:
route print
It should show a line like this:
127.0.0.0 255.0.0.0 On-link 127.0.0.1 xxx
127.0.0.1 255.255.255.255 On-link 127.0.0.1 xxx
127.255.255.255 255.255.255.255 On-link 127.0.0.1 xxx
This ensure that you still have your loop back up and running (probably is ok).
4 check:
Turn off your local firewall with VPN connected (if allowed) and try the check 1 again.
Some firewall rules change connections to "localhost" while connected to a VPN, since the new connection is "corporate" or "public".
If that worked, you need to create a rule in your firewall to allow connection to port 7687 for all addresses, this will fix your problem.
5 check:
Check your neo4j community server to listen to "127.0.0.1" and not "0.0.0.0"
Check your ports open by using netstat
netstat -a -o
It should state something like this
Proto Local Address Foreign Address State PID
TCP 0.0.0.0:7687 machinename:0 LISTENING xxxx
or
TCP 127.0.0.1:7687 machinename:0 LISTENING xxxx
If the server is like the first line, it might be handled by a corporate firewall, but by using the 127.0.0.1 as address it should always be local.
Hopefully that will get you on the way :)
i had same problem, so Let me tell you what i came out with...
the company has a proxy server for all connections, so i change my request from IP to DNS by typing nslookup IP on command prompt terminal.
from: ws://180......:80/socket/test to: ws://mxjuppro22......:80/socket/test
then error gone and now is working like a charm!!!
hope it helps

SSH connection tunneling refused

I have a virtual machine located inside a private network.
So firstly, I should come in server.com and then come in my-machine.
I want to make ssh-tunnel from my laptop to my-machine.
ssh -v -A -nNT -L 40000:127.0.0.1:40000 login#server.com ssh -v -nNT -L 40000:127.0.0.1:40000 my-machine &
Now I want to test ssh-tunnel with netcat.
I run at my-machine:
nc -l 40000
At my laptop:
~ ❯❯❯ nc 127.0.0.1 40000
But it gives me:
debug1: Connection to port 40000 forwarding to 127.0.0.1 port 40000 requested.
debug1: channel 2: new [direct-tcpip]
channel 2: open failed: connect failed: Connection refused
debug1: channel 2: free: direct-tcpip: listening port 40000 for 127.0.0.1 port 40000, connect from 127.0.0.1 port 49692 to 127.0.0.1 port 40000, nchannels 3
Why this happen and how to fix it? I expected that anything I type in my laptop console will appear in my-machine console.
What last string means? Especially 127.0.0.1 port 49692 why this port is used? I never type it.
debug1: channel 2: free: direct-tcpip: listening port 40000 for 127.0.0.1 port 40000, connect from 127.0.0.1 port 49692 to 127.0.0.1 port 40000, nchannels 3
Every TCP connection is point to point needs two pairs of IP addresses and ports. Reading all the message (not just the part you showed):
connect from 127.0.0.1 port 49692
So indeed you are connecting to the port 40000, but you are connecting from port 49692 (randomly assigned for your netcat or some of the forwarded steps).
How to fix this problem?
This double-jump forwarding does not work, because you need the second established before the first one.
Also you are using -N switch for the first command, which is preventing running the second ssh command.
But I would give it a shot with ProxyCommand, which will make you connect to the destination with single command directly from your host:
ssh -v -nNT -L 40000:127.0.0.1:40000 \
-oProxyCommand="ssh -W %h:%p login#server.com" my-machine &

Steps to share internet with BeagleBone Black using USB from OS X

Already tried:
Connect the BBB with USB to iMac
Share internet with the board from System Preferences->Sharing
ssh to the board and then try to udhcp -i usb0
This is what it says:
udhcpc (v1.20.2) started
Gets stuck and I get and error: Write failed: Broken pipe
ssh exits
Any clues?
After some try-and-erroring, here's what worked for me:
1. Watch this video: http://www.youtube.com/watch?v=Cf9hnscbSK8
2. If your BBB was shipped after November 2013, instead of screen /dev/tty.usb*B 115200 use screen /dev/tty.usb* 115200 and actually you need to go to the /dev directory and check which of the tty.usbXXX is available for your BBB and screen it. In my case it was tty.usb131 for example
3. You continue the steps just like in the video until opkg update which would be the thing you need to do over the internet
And that it's all about it.
Your SSH session is getting stuck because you're connected to usb0 and the udhcpc command changed the IP address for it! At this point there's nothing listening on the other end of your ssh session, so your local computer's ssh client eventually fails with the broken pipe error and exits.
An obvious workaround is to connect via tty.usbserial instead of ssh to the IP address. You'd think the usb port's assigned IP shouldn't be changing though. Read on to understand what's happening.
Most people using a BBB for the first time attach them directly to their Internet connected computer using the supplied USB cable. It's exactly what the BBBs designers intended for you to do, and they've done a fantastic job with the BBBs startup web page.
That host computer shares it connection differently though depending on whether it's Windows, OS X or Linux, and how you do it varies depending on the version of the OS you're running.
Derek Molloy (Exploring BeagleBone) and Jason Kridner (Youtube OS X Beaglebone video) provide some fairly detailed instructions to use host based Internet sharing with your BBB. The Linux and Windows instructions are still good, but they need to update the OS X info for Yosemite - Apple switched their NAT and firewall software to pf from ipfw and natd. If you try running udhcpc like Jason did in his vid it doesn't work the same way as his did.
So back to your BBB SSH problem with OS X Yosemite. Here's how to see what's going on: Connect to the BBB using a serial/FTDI cable, then check the ip config of usb0 for the beaglebone.
beaglebone:~# ifconfig -a usb0
usb0 Link encap:Ethernet HWaddr 0e:be:ff:00:ff:00 inet addr:192.168.7.2
Bcast:192.168.7.3 Mask:255.255.255.252
confirm you can ping the host that's sharing it's Internet connection
beaglebone:~# ping 192.168.7.1
PING 192.168.7.1 (192.168.7.1) 56(84) bytes of data.
64 bytes from 192.168.7.1: icmp_req=1 ttl=64 time=0.681 ms
64 bytes from 192.168.7.1: icmp_req=2 ttl=64 time=0.533 ms
^C
try reaching an Internet IP (google dns)
beaglebone:~# ping 8.8.8.8
connect: Network is unreachable
check routes and confirm there's no default route out, which is why the ping above failed (a USB connected BBB has a 192.168.7.0/30 network setup by default, so it can only reach 192.168.7.0, .1, .2 and .3 addresses).
beaglebone:~# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.7.0 0.0.0.0 255.255.255.252 U 0 0 0 usb0
so if you run udhcpc it will add the missing route for you. you could also just add the route directly, but you need to setup dns as well, and with OS X Internet sharing it won't work without also changing the BBB's IP address - see links at end of this post)
beaglebone:~# udhcpc -i usb0
udhcpc (v1.20.2) started
Sending discover...
Sending discover...
and here is where udhcpc changes the IP instead of just re-using 192.168.7.2. The new IP is compatible with the IP range used by OS X Internet Sharing, so that may be why the DHCP server is returning it.
Sending select for 192.168.2.34...
Lease of 192.168.2.34 obtained, lease time 85536
udhcpc then throws an error because there's no default route to delete
/etc/udhcpc/default.script: Resetting default routes
SIOCDELRT: No such process
udhcpc then adds the default route - note carefully it's an OS X Internet Sharing 192.168.2 address, not the original 192.168.7.
/etc/udhcpc/default.script: Adding DNS 192.168.2.1
everything worked, so you can see the new route and successfully ping an external IP now
beaglebone:~# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 192.168.2.1 0.0.0.0 UG 0 0 0 usb0
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 usb0
beaglebone:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=53 time=4.08 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=53 time=3.59 ms
^C
There are a couple of blog posts that show how to set this up permanently:
Sharing OS X Internet Connection over USB to BeagleBone Black
and
Changing usb0 IP address on the BeagleBone Black

Resources