Can I make Wireguard VPN peers to talk to each other? - networking

I have a server running Wireguard, and I have multiple clients (peers) connected to it up and running. I am not very sure how VPN works, but this is my current setup.
The /etc/wireguard/wg0.conf of my server looks like this.
[Interface]
Address = 172.16.16.1/24
SaveConfig = true
ListenPort = 8999
PrivateKey = XXX
[Peer]
PublicKey = XXX
AllowedIPs = 172.16.16.2/32
[Peer]
PublicKey = XXX
AllowedIPs = 172.16.16.3/32
And the configuration on my clients wg0.conf looks like this.
[Interface]
PrivateKey = XXX
Address = 172.16.16.x/32
[Peer]
PublicKey = XXX
AllowedIPs = 172.16.16.0/24
PersistentKeepalive = 30
With everything up and running, from my client with IP address 172.16.16.2, I am able to ping the server 172.16.16.1. I am able to do the same from my other client with 172.16.16.3, I can ping the server 172.16.16.1.
Interestingly, from my server, I am able to ping all the peers! That is, from within 172.16.16.1, I can ping both 172.16.16.2 and 172.16.16.3. But that is the prime purpose of the setup!
Now, I want my peers to talk to each other, that is, I must be able to ping 172.16.16.2 from my other peer 172.16.16.3 and vice-versa, but this is not working. It says that the network is unreachable.
The idea is, I want it to work like a LAN server, where one server that acts as a gateway, and multiple peers/clients that can talk to each other, and also talk to the server.
Is this possible? If yes, what am I missing?

After the whole evening of searching through the internet, I found some useful links that talks about the same problem that I am facing.
Link: https://lists.zx2c4.com/pipermail/wireguard/2018-August/003250.html
That says, we must enable ip forwarding in the server to make it work like an edge router.
By default, the IPv4 policy in linux kernels disables support for IP forwarding. This prevents machines that run linux server from functioning as dedicated edge routers. To enable IP forwarding, use the following command:
[root#myServer ~ ] # sysctl -w net.ipv4.ip_forward=1
This configuration change is only valid for the current session; it does not persist beyond a reboot or network service restart. To permanently set IP forwarding, edit the /etc/sysctl.conf file as follows:
Locate the following line:
net.ipv4.ip_forward = 0
Edit it to read as follows:
net.ipv4.ip_forward = 1
Use the following command to enable the change to the sysctl.conf file:
[root#myServer ~ ] # sysctl -p /etc/sysctl.conf
Read more: https://docs.fedoraproject.org/en-US/Fedora/18/html/Security_Guide/sect-Security_Guide-Firewalls-FORWARD_and_NAT_Rules.html
With this done, now all my peers are able to talk to each other, and this functions just like a LAN network!

I followed all the steps suggested by Sibidharan but also needed to add an iptables command on the server to forward the wireguard traffic from peer to peer.
iptables -A FORWARD -i wg0 -o wg0 -j ACCEPT
I was then able to connect via ssh from peer to peer.

Just set your interface up on the client to a prefix of /24

Related

How to create TCP tunnels with Pagekite

I am a complete beginner when it comes to networking and I am trying to set up a TCP tunnel on my machine using pagekite. I want to route all traffic from a TCP address to a port on my localhost, let's say 8080. I would then start a handler on localhost:8080 to deal with the incoming traffic. I can get this to work with ngrok simply by doing ngrok tcp 8080, but on a free ngrok plan I cannot reserve tcp addresses and ngrok is rather slow, so I opted to try and use pagekite.
Pagekite normally allows easy tunnelling to an HTTP address, but they have a guide here about how to use PuTTY along with Pagekite to create a TCP tunnel proxied by HTTP.
I followed their guide but could use some help figuring out if it does what I want it to do.
I am working on a Linux VM, so I first set up an SSH server with openssh like this: sudo service ssh start
I then exposed that SSH server using pagekite like this: python3 pagekite.py 22 ssh:user.pagekite.me
I then started PuTTY, and configured the Host Name to be user.pagekite.me on port 22, setup an HTTP proxy with the proxy hostname user.pagekite.me on port 443 and finally created a tunnel from the PuTTY machine with source port 8080 and destination localhost:8080.
Now I am not sure what this actually accomplished. I know that the PuTTY machine connected to the ssh server running on my VM and I am able to use the linux terminal from the PuTTY terminal but has this actually created a TCP tunnel from user.pagekite.me:8080 to localhost:8080? Additionally after doing this, if I try to setup the handler on localhost:8080 I get the following error:
Handler failed to bind to 0.0.0.0:8080
Rex::BindFailed The address is already in use or unavailable: (0.0.0.0:8080).
Again I am completely clueless when it comes to networking so if anyone could explain what it is I'm doing and if it is even possible to do what I want the way that I am doing it, that would be quite helpful.

WebSocket-Sharp doesn't respond to public IP address

I have a problem hosting WebSocket-Sharp on a public internet IP. Locally it works fine.
This problem occurs on Windows and Linux.
I do no receive a timeout or an HTTP status code, the page blocks immediately.
I'm 99% sure I have port forwarding set up correctly; I've tried with an Android modem, VPN and regular NAT router setup.
I've tried the following combinations:
192.168.1.2:80 8080 5000 39393
0.0.0.0: ....
public IP: ....
The problem resides in the HttpServer provided with WebsScketSharp. The pure websocket variant (WebSocketServer.cs), instead of the HttpServer option with Get functionality, has an option to set AllowForwardedRequest to true so will be reachable from non localhost addresses. The HttpServer class doesn't support this.
It is partially a solution as I gave up regular GET functionality, but thats fine by me.
Ok, assuming your server with the public Ip addres is Linux:
Check what ports are listening and what program are listening in those
netstat -tulpn
Check your Firewall rules both in the provider and in the Server
sudo ufw status
See if connections are getting to your Server
sudo tcpdump
You can filter for the port of for origin Ip (if you use a proxy that will be different Ip).
sudo tcpdump | grep "80\|123.45.67.89"
That's the only way to see if the packets are getting into the server.
Let me know if you use Docker as thinks work a bit different.
You can create a tunnel and try like if it was local
ssh -L 80:123.45.67.89:80 ubuntu#yourserver.com
Cheers

gre tunnel issues - one sided communication

I have two machines:
Ubuntu 16.04 server VM (172.18.6.10)
Proxmox VE5 station (192.168.6.30)
they are communicating through a third machine that forwards packets between the two. I want to create a gre tunnel between the two machines and to do that and make it persistent I have edited the /etc/network/interfaces and added a gre interface and tunnel to be made on boot up as the following:
After they were created I have tried to ping one machine from the other to check connectivity, pinging the gre interface IP address (10.10.10.1 and 10.10.10.2). The issue is that when I ping the Proxmox machine from Ubuntu I get no feedback, but when I run tcpdump on gre1 on Porxmox I see that the packets are received and there is a ICMP reply outgoing:
When I run the ping the other way around and check it with tcpdump on the Ubuntu machine I get nothing. I understand that the issue is when packets leave Proxmox to Ubuntu via gre1 and get lost or blocked because Ubuntu can clearly send Proxmox packets but the reply never comes back. How can I fix this?
Check if you have packet forwarding enabled for the kernel of the 3rd machine that you user for the communication of the other 2 machines
Check /etc/sysctl.conf and see if you have this:
net.ipv4.ip_forward = 1
if it's commented (#) uncomment it, save the file and issue a:
sysctl -p
Then try again the pings...

Proxmox with OPNsense as pci-passthrough setup used as Firewall/Router/IPsec/PrivateLAN/MultipleExtIPs

This setup should be based on a proxmox, being behind a opnsense VM hosted on the Proxmox itself which will protect proxmox, offer a firewall, a privat LAN and DHCP/DNS to the VMs and offer a IPsec connection into the LAN to access all VMs/Proxmox which are not NATed.
The server is the typical Hetzner Server, so only on NIC but multiple IPs or/subnets on this NIC.
Proxmox Server with 1 NIC(eth0)
3 Public 1IPs, IP2/3 are routed by MAC in the datacenter (to eth0)
eth0 is PCI-Passthroughed to the OPNsense KVM
A private network on vmbr30, 10.1.7.0/24
An IPsec mobile client connect (172.16.0.0/24) to LAN
To better outline the setup, i create this [drawing][1]: (not sure its perfect, tell me what to improve)
Questions:
How to setup such a scenario using PCI-Passthrough instead of the Bridged Mode.
Follow ups
I) Why i cannot access PROXMOX.2 but access VMEXT.11 (ARP?)
II) is why do i need a from * to * IPSEC chain rule to get ipsec running. That is most probably a very much opnsense related question.
III) I tried to handle the 2 additional external IPs by adding virtual ips in OPNsense, adding a 1:1 nat to the internal LAN ip and opening the firewall for the ports needed ( for each private lan IP ) - but yet i could not get it running. The question is, should each private IP have a seperate MAC or not? What is specifically needed to get a multi-ip setup on WAN
General high level perspective
Adding the pci-passthrough
A bit out of scope, but what you will need is
a serial console/LARA to the proxmox host.
a working LAN connection from opnsense (in my case vmbr30) to proxmox private ( 10.1.7.2 ) and vice versa. You will need this when you only have the tty console and need to reconfigure the opnsense intefaces to add em0 as the new WAN device
You might have a working IPsec connection before or opened WAN ssh/gui for further configuration of opnsense after the passthrough
In general its this guide - in short
vi /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on"
update-grub
vi /etc/modules
vfio
vfio_iommu_type1
vfio_pci
vfio_virqfd
Then reboot and ensure you have a iommu table
find /sys/kernel/iommu_groups/ -type l
/sys/kernel/iommu_groups/0/devices/0000:00:00.0
/sys/kernel/iommu_groups/1/devices/0000:00:01.0
Now find your network card
lspci -nn
in my case
00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection (2) I219-LM [8086:15b7] (rev 31)
After this command, you detach eth0 from proxmox and lose network connection. Ensure you have a tty! Please replace "8086 15b7" and 00:1f.6 with your pci-slot ( see above)
echo "8086 15b7" > /sys/bus/pci/drivers/pci-stub/new_id && echo 0000:00:1f.6 > /sys/bus/pci/devices/0000:00:1f.6/driver/unbind && echo 0000:00:1f.6 > /sys/bus/pci/drivers/pci-stub/bind
Now edit your VM and add the PCI network card:
vim /etc/pve/qemu-server/100.conf
and add ( replace 00:1f.6)
machine: q35
hostpci0: 00:1f.6
Boot opnsense connect using ssh root#10.1.7.1 from your tty proxmox host, edit the interfaces, add em0 as your WAN interface and set it on DHCP - reboot your opnsense instance and it should be up again.
add a serial console to your opnsense
In case you need a fast disaster recovery or your opnsense instance is borked, a CLI based serial is very handy, especially if you connect using LARA/iLO whatever.
Do get this done, add
vim /etc/pve/qemu-server/100.conf
and add
serial0: socket
Now in your opnsense instance
vim /conf/config.xml
and add / change this
<secondaryconsole>serial</secondaryconsole>
<serialspeed>9600</serialspeed>
Be sure you replace the current serialspeed with 9600. No reboot your opnsense vm and then
qm terminal 100
Press Enter again and you should see the login prompt
hint: you can also set your primaryconsole to serial, helps you get into boot prompts and more and debug that.
more on this under https://pve.proxmox.com/wiki/Serial_Terminal
Network interfaces on Proxmox
auto vmbr30
iface vmbr30 inet static
address 10.1.7.2
address 10.1.7.1
netmask 255.255.255.0
bridge_ports none
bridge_stp off
bridge_fd 0
pre-up sleep 2
metric 1
OPNsense
WAN is External-IP1, attached em0 (eth0 pci-passthrough), DHCP
LAN is 10.1.7.1, attached to vmbr30
Multi IP Setup
Yet, i only cover the ExtraIP part, not the extra Subnet-Part. To be able to use the extra IPs, you have to disable seperate MACs for each ip in the robot - so all extra IPs have the same MAC ( IP1,IP2,IP3 )
Then, in OPN, for each extern IP you add a Virtual IP in Firewall-VirtualIPs(For every Extra IP, not the Main IP you bound WAN to). Give each Virtual IP a good description, since it will be in the select box later.
Now you can go to either Firewall->NAT->Forward, for each port
Destination: The ExtIP you want to forward from (IP2/IP3)
Dest port rang: your ports to forward, like ssh
Redirect target IP: your LAN VM/IP to map on, like 10.1.7.52
Set the redirect port, like ssh
Now you have two options, the first one considered the better, but could be more maintenance.
For every domain you access the IP2/IP3 services with, you should define local DNS "overrides" mapping on the actually private IP. This will ensure that you can communicate from the inner to your services and avoids the issues you would have since you used NATing before.
Otherwise you need to care about NAT reflection - otherwise your LAN boxes will not be able to access the external IP2/IP3, which can lead to issues in Web applications at least. Do this setup and activate outbound rules and NAT reflection:
What is working:
OPN can route a]5]5ccess the internet and has the right IP on WAN
OPN can access any client in the LAN ( VMPRIV.151 and VMEXT.11 and PROXMOX.2)
i can connect with a IPSec mobile client to OPNsense, offering access to LAN (10.1.7.0/24) from a virtual ip range 172.16.0.0/24
i can access 10.1.7.1 ( opnsense ) while connected with IPsec
i can access VMEXT using the IPsec client
i can forward ports or 1:1NAT from the extra IP2/IP3 to specific private VMs
Bottom Line
This setup works out a lot better then the alternative with the bridged mode i described. There is no more async-routing anymore, there is no need for a shorewall on proxmox, no need for a complex bridge setup on proxmox and it performs a lot better since we can use checksum offloding again.
Downsides
Disaster recovery
For disaster recovery, you need some more skills and tools. You need a LARA/iPO serial console the the proxmox hv ( since you have no internet connection ) and you will need to configure you opnsense instance to allow serial consoles as mentioned here, so you can access opnsense while you have no VNC connection at all and now SSH connection either ( even from local LAN, since network could be broken ). It works fairly well, but it needs to be trained once to be as fast as the alternatives
Cluster
As far as i can see, this setup is not able to be used in a cluster proxmox env. You can setup a cluster initially, i did by using a tinc-switch setup locally on the proxmox hv using Seperate Cluster Network. Setup the first is easy, no interruption. The second join needs to already taken into LARA/iPO mode since you need to shutdown and remove the VMs for the join ( so the gateway will be down ). You can do so by temporary using the eth0 NIC for internet. But after you joined, moved your VMs in again, you will not be able to start the VMs ( and thus the gateway will not be started). You cannot start the VMS, since you have no quorum - and you have no quorum since you have no internet to join the cluster. So finally a hen-egg issue i cannot see to be overcome. If that should be handled, only by actually a KVM not being part of the proxmox VMs, but rather standalone qemu - not desired by me right now.

arp response received but ICMP packets are not reaching to own host even

My environment has 2 hosts and a VM on each host. NVGRE tunnel is created, as VMs and Hosts belongs to different subnets. I am using Windows server 2012 R2 hosts and same VMs. Hosts are connected back to back. If I put VMs and Hosts in same subnet Ping works.
Both the VMs are receiving ARP requests and responses from each other. ARP cache of each VM is having dynamic entry of other VM.
BUT ICMP request packet from VM is not even seen on its Host.
You cannnot just ping from one host to another host.
To ping provider address from your host, -p option is needed.
Example:
$address = (Get-NetVirtualizationProviderAddress).ProviderAddress
ping -p $address
Please put virtualization lookup records when you need more help.
Run following commands as administrator.
Get-NetVirtualizationLookupRecord
Get-NetVirtualizationCustomerRoute
Also make sure your VM's firewall allows ICMP echo.

Resources