How to expose my behind-the-NAT web-server via Wireguard on public VPS - nat

I have a web server with a few TBs of data at the computer behind NAT.
I want to expose it to Internet via VPS I have at Azure.
So, I thought WireGuard would be a great tool for that, but I can't figure out the config on how to do that.
Here is wg0.conf on that behind-NAT server:
[Interface]
PrivateKey = OBUNhf6***
Address = 192.168.10.2/24
[Peer]
PublicKey = sUukxiqVNJQpcUVLYu/+fmHH+K9qD7Ol9CipOdlOc3c=
AllowedIPs = 192.168.10.1/24
Endpoint = 13.66.155.255:8101
PersistentKeepalive = 25
Running curl on the same computer, show that web server works fine on port 9000:
$ curl -s http://192.168.10.2:9000/
<html><head>
<title>Welcome to nginx!</title>
...
That 13.66.155.255 endpoint - is IP of the VPS.
So, now, I'm configuring my Ubuntu 19.10 VPS on Azure. So wg0.conf:
[Interface]
PrivateKey = sDH1wvnyRKE***
ListenPort = 8101
Address = 192.168.10.1/24
Table = 1234
PostUp = ip rule add ipproto tcp dport 9000 table 1234
PreDown = ip rule delete ipproto tcp dport 9000 table 1234
[Peer]
PublicKey = cnHwqyRLukwYoYw8nl+PH57ZsCKnMmStmXBAZSRNfx0=
AllowedIPs = 192.168.10.0/24
I started WireGuard on both computers.
It looks like KeepAlive packets transmitted successfully (I see transfer increasing).
I can open that web-server from within VPS like this:
VPS# curl 192.168.10.2:9000
<html><head>
<title>Welcome to nginx!</title>
...
But I can't open that webserver from outside of VPS:
% curl http://13.66.155.255:9000/
curl: (7) Failed to connect to 13.66.155.255 port 9000: Connection refused
My Azure firewall (NSG) has ports 8101 and 9000 open.
My Ubuntu firewall disabled.
Kernel PF enabled: net.ipv4.ip_forward=1
What am I missing?
Should I have some kind of iptables configuration on top of that?

Related

Accessing NextJS running on WSL2 over the network

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

Wireguard can't ping client or server, other WAN traffic unaffected

I'm a total newbie with Wireguard so please be patient with me.
I'm trying to get a peer-to-peer connection between a Windows 10 machine and a Linux (Debian) machine through a Wireguard VPN, which I'm hosting on a separate Linux server. My current setup allows me to remotely connect from an external network to my Wireguard server as a peer and access the internet through it.
However, I cannot ping my server from a peer, my peers from the server or peers from other peers. I've been following this guide. And my server-side configuration (wg0.conf) looks like this:
[Interface]
## Private IP address for the wg0 interface ##
Address = 10.0.0.1/24
## VPN server listening port ##
ListenPort = 51820
## VPN server private key ##
PrivateKey = <snip>
[Peer]
## Client public key ##
PublicKey = <snip>
## Client IP address ##
AllowedIPs = 10.0.0.3/32
[Peer]
## Client public key ##
PublicKey = <snip>
## Client IP address ##
AllowedIPs = 10.0.0.4/32
My Windows 10 peer configuration:
[Interface]
PrivateKey = <snip>
Address = 10.0.0.3/24
DNS = 1.1.1.1, 1.0.0.1
[Peer]
PublicKey = <snip>
AllowedIPs = 10.0.0.1/24
Endpoint = <My server's WAN address>:51820
And my Debian peer configuration:
[Interface]
PrivateKey = <snip>
Address = 10.0.0.4/24
DNS = 1.1.1.1, 1.0.0.1
[Peer]
PublicKey = <snip>
AllowedIPs = 10.0.0.1/24
Endpoint = <My server's WAN address>:51820
I have forwarded the port in question on my server's network for both outbound and inbound traffic. I have also tried additional firewall rules on my server:
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o ens3 -j MASQUERADE
With no effect. In this case "ens3" being my network interface's name on my server's network.
Running wg show on my server gives me:
interface: wg0
public key: <server's pub key>
private key: (hidden)
listening port: 51820
peer: <WIN10 peer pub key>
allowed ips: 10.0.0.3/32
peer: <DEB11 peer pub key>
allowed ips: 10.0.0.4/32
And pinging any of the network members fails with a 100% packet loss.
I've obviously omitted my keys and public WAN addresses from these snippets.

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.

How to get port forwarding working with Jelastic to connect to REPL of running Clojure web app?

I've deployed a simple Clojure web app to Jelastic in a Tomcat container. The Clojure app starts a REPL on port 7001. I have Jelastic SSH Gate set up and working. I SSH into the tomcat node with port forwarding by running this in the terminal on my local machine (where XXX are numbers):
ssh -L 7001:localhost:7001 XXXXX-XXXX#gate.paas.massivegrid.com -p 3022 -N -vv
Then on my local machine I run
lein repl :connect 7001
On the local machine I see:
Connecting to nREPL at 127.0.0.1:7001
ConnectException Connection refused (Connection refused)
On the tomcat node terminal window I see
debug1: Connection to port 7001 forwarding to localhost port 7001 requested.
debug2: fd 10 setting TCP_NODELAY
debug1: channel 2: new [direct-tcpip]
channel 2: open failed: connect failed: Connection refused
debug2: channel 2: zombie
debug2: channel 2: garbage collecting
debug1: channel 2: free: direct-tcpip: listening port 7001 for localhost port 7001, connect from 127.0.0.1 port 57311 to 127.0.0.1 port 7001, nchannels 3
What am I doing wrong? Is this something to do with the way that Jelastic manages ports?
=====================
EDIT: Actually port forwarding works fine
The problem was with the app.
For reference, here's how to check that port forwarding is working on Jelastic. The Jelastic node doesn't have netcat installed so you can't just run netcat -l 7001. However, it does have perl installed, so you can write a perl script to create a listener socket and then run that script on the Jelastic server:
(EDIT 2019_04_06: Instead of using perl script below, just use python -m SimpleHTTPServer 7001 - see comments)
use IO::Socket::INET;
# auto-flush on socket
$| = 1;
# creating a listening socket
my $socket = new IO::Socket::INET (
LocalHost => '0.0.0.0',
LocalPort => '7001',
Proto => 'tcp',
Listen => 5,
Reuse => 1
);
die "cannot create socket $!\n" unless $socket;
print "server waiting for client connection on port 7777\n";
while(1)
{
# waiting for a new client connection
my $client_socket = $socket->accept();
# get information about a newly connected client
my $client_address = $client_socket->peerhost();
my $client_port = $client_socket->peerport();
print "connection from $client_address:$client_port\n";
# read up to 1024 characters from the connected client
my $data = "";
$client_socket->recv($data, 1024);
print "received data: $data\n";
# write response data to the connected client
$data = "ok";
$client_socket->send($data);
# notify client that response has been sent
shutdown($client_socket, 1);
}
$socket->close();
(script from here).
Use nano to write the above into a script listener.pl on the Jelastic node then run perl listener.pl on that node.
On your local machine run
ssh -L 7001:localhost:7001 XXXXX-XXXX#gate.paas.massivegrid.com -p 3022
Then on local machine try curl localhost:7001 and in the terminal for the Jelastic node you should see something like
received data: GET / HTTP/1.1
Host: localhost:7777
User-Agent: curl/7.54.0
Accept: */*

HTTP request to VM

I have a jetty server running under port 8080 on VM. VM in its turn runs on remote server under port 10000. Is it legit to address it as http://someremote.org:10000:8080/request? Or should I use SSH somehow?
What I was looking for is called ssh tunneling. You make a tunnel from your port to remote's machine port like that:
ssh -p 10000 -L 18080:localhost:8080 user#remote.host.org
18080 here is port, that you use on your local machine in order to get to remote's 8080 port.

Resources