I know there are a lot of questions with this specific issue but believe me I have tried everything that I got my hands on. After connecting to Wireguard and having established a successful handshake I do not have internet connection. I will describe everything I have tried so far with no luck.
I am using a Virtual Machine in Google Cloud and a physical Windows machine as client.
Here is how my server configuration (Google Cloud VM) looks like:
[Interface]
Address = 10.100.100.1/24
SaveConfig = true
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
ListenPort = 51820
PrivateKey = PRIVATE_KEY
[Peer]
PublicKey = CLIENTS_PUBLIC_KEY
AllowedIPs = 10.100.100.2/32
Here is how my client side connection look like:
[Interface]
PrivateKey = CLIENTS_PRIVATE_KEY
Address = 10.100.100.2/32
[Peer]
PublicKey = SERVER_PUBLIC_KEY
AllowedIPs = 0.0.0.0/0
Endpoint = BASTION_SERVER_PUBLIC_IP:51820
I have enabled IPV4 Forwarding in the cloud VM modifying /etc/sysctl.conf file and uncommenting the following line:
net.ipv4.ip_forward=1
Since this is a cloud environment with external firewall and all I manually added rule to the cloud's firewall for port 51820. After that point I can make a handshake successfully but there is no internet in the client side.
I have checked if the server itself has internet access, which it does.
Disabled my whole firewall on the client side since I thought it might interfere with something.
I have read in another post someone suggesting to add MTU value explicitly. Google uses MTU value of 1460 which apparently is different from Wireguard's default one. I have added this to both client and server configuration with no luck.
Explicitly stated the DNS record in the client's configuration. Still no luck.
Enabled the UFW and explicitly put the port required by Wireguard - 51820.
Is there something that I am missing regarding all of this? I have tried everything I can get my hands on but still there is no internet connection from the client after the handshake.
Thank you in advance!
Update 1
I have enabled IP Forwarding as suggested:
After this configuration I can see in the server side that the handshake is successful:
peer: PUBLIC_KEY
endpoint: CLIENT_IP:56507
allowed ips: 10.100.100.2/32
latest handshake: 4 minutes, 11 seconds ago
transfer: 52.60 KiB received, 344 B sent
Also it shows that it receives 52.60 KiB of data. This was not here before.
However the problem still persists. I still have no access to the internet from client side.
By default, Google Cloud performs strict source and destination
checking for packets so that:
VM instances can only send packets whose sources are set to match an internal IP address of its interface in the network.
Packets are only delivered to an instance if their destinations match the IP address of the instance's interface in the network.
When creating a VM, you must enable IP Forwarding. This cannot be changed after a VM is created.
Enabling IP forwarding for instances
Related
I'm running the community OpenVPN server (on a CIS Level 1 RHEL 7) instance, which I can connect from my laptop without any issue. Whilst connected, I can SSH to the OpenVPN server instance using the private IP but not anything else at all. Not even a different instance in the same sub-net. Say my VPN server in: 10.100.0.0/28 subnet, VPN client subnet is: 192.168.10.0/24 and I want SSH to an instance in 10.100.0.16/28. This is the part I have in the server config:
push "redirect-gateway def1 bypass-dhcp"
push "route 10.100.0.16 255.255.255.240"
push "route 10.100.0.32 255.255.255.240"
;push "route 10.100.0.0 255.255.240.0"
route 10.100.0.16 255.255.255.240
route 10.100.0.32 255.255.255.240
;route 10.100.0.0 255.255.240.0
server 192.168.10.0 255.255.255.0
I have added these iptables rules to allow the VPN traffic:
## allow udp 1194
iptables -A INPUT -p udp -m udp --dport 1194 -m state --state NEW -j ACCEPT -i eth0
## Allow TUN interface
iptables -A INPUT -i tun+ -j ACCEPT
## Allow TUN connections to be forwarded
iptables -A FORWARD -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth0 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT
## NAT the VPN client traffic to the Internet
iptables -t nat -A POSTROUTING -s 192.168.10.0/24 -o eth0 -j MASQUERADE
## default TUN OUTPUT
iptables -A OUTPUT -o tun+ -j ACCEPT
apart from that also,
added net.ipv4.ip_forward = 1 to /etc/sysctl.conf
Disabled source/destination check on the VPN instance
added a static route to VPC route table with Destination: 192.168.10.0/24, Targeting the ENI that attached to the VPN instance
added ingress rule in the target instances' SG to allow vpn-client subnet on port 22
There is no NACL involved yet (but have to enable that at some point)
What else didn't do or did wrong?? I'm really stuck and know I'm missing some thing really silly. Could anyone shade some light or point me to right direction please?
-S
Figured out why it was not working. These two lines:
route 10.100.0.16 255.255.255.240
route 10.100.0.32 255.255.255.240
in the config file were causing the issue. Without those, it forwarding the traffic downstream without any issue. I'm a bit confused though from the OpenVPN documentation on route ... and push "route ..., so not really sure why those two lines were causing connection issue. So, if anyone can shade some light on that will be very much appreciated.
I'm trying to find out if GCP supports the ability to forward ALL ports to a single one.
Currently I'm "manually" setting firewall rules on each instance using the following iptable rule.
iptables -t nat -A PREROUTING -p tcp --dport 1:65535 -j REDIRECT --to-ports 10000
This is not fun to manage because I'm using docker and don't want to manage the VM directly.
The flow I'm trying to implement is as follows:
Received TCP request (Ingres)
Load balance request (GCP TCP-LB)
Redirect ALL requests to port 10000 (???)
Docker container listening on port 10000
You can use one of these two options:
1.- Using a VM instance as a bastion host and be used as NAT gateway for your other instances.
2.- Use Cloud NAT directly or with protocol forwarding that will be something similar to what you are trying to implement.
I have an EC2 instance in which I am running a Flask server on port 8080.
* Running on http://0.0.0.0:8080/ (Press CTRL+C to quit)
I can run curl and get the response from my EC2 instance.
$ curl -X GET '0.0.0.0:8080/fbeac'
However, I cannot use the public IP/DNS to get the response and running
$ curl -X GET '3.135.62.118:8080/fbeac'
results in curl: (7) Failed to connect to 3.135.62.118 port 8080: Connection refused. I get the same error when I try to curl using my local machine.
My application is listening on port 8080, which I checked by running netstat.
$ netstat -an | grep 8080
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN
Moreover, I have ensured the Security Groups are set up correctly. I have experimented with just custom TCP port 8080, all TCP ports, and (currently) all traffic. I have also opened up HTTP/HTTPS ports on the side just in case, but with no luck.
This leads me to believe it might be a firewall issue but I am on an Amazon Linux machine and the default policy seems to be to ACCEPT, which I checked by running iptables.
$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Is there some other thing I should be checking or button I should be flipping?
My AWS Instance ID is i-0080c730c4287ca3c.
I would suggest checking what access rules are defined in your EC2 instance security groups. You might need to open up port 8080.
Also, as a side note, consider not using flask development server in production like that. It's fine for testing, but you really should be using something like uwsgi for production workloads.
Just in case anyone is having this problem too, make sure that you have a Gateway configured
According this AWS doc: Scenario 2: VPC with Public and Private Subnets (NAT) I have my own VPC with two subnets: private and public. In public subnet I have deployed an Ubuntu 16.04 Instance with assigned EIP. It also has next security group inbound rules:
Type Protocol Port Range Source Description
SSH TCP 22 xx.xx.xx.xx/32 Home IP
and outbound accordingly:
Type Protocol Port Range Source Description
SSH TCP 22 sg-xxprivatexx Security group ID for instance in private subnet
Looks nice, I can ssh it externally from my home. No problem.
In private subnet I have deployed another one Ubuntu 16.04 machine with next security group (inbound rules):
Type Protocol Port Range Source Description
HTTP TCP 80 sg-xxpublicxxx Security Group ID for bastion instance in public subnet
SSH TCP 22 sg-xxpublicxxx -
and no outbound rules (actually it has 80, 443 outbound ports opened, but its not an interesting part as I guess). And I still can reach this virtual machine using ssh from my bastion.
Right now I just want to make only one simple thing - run ssh port forwarding so I can run localhost:8080 on my home PC browser and see the webpage I published on my private instance. If I understand it correctly from here and here (and from here as well) I have to run something like:
ssh -N -v -L 8080:10.0.1.112:80 ubuntu#3.121.46.99
Which as I guess basically means: just forward a traffic from private subnet instance with IP 10.0.1.112:80 to my localhost:8080 through my bastion VM with username ubuntu hosted on EIP 3.121.46.99.
Debug ends with lines:
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:ZyVHgnF8z5vE5gfNr1S2JDfjhdydZVTNevPRgJZ+sRA /home/matterai/.ssh/key.pem
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/matterai/.ssh/id_rsa
debug1: Trying private key: /home/matterai/.ssh/id_dsa
debug1: Trying private key: /home/matterai/.ssh/id_ecdsa
debug1: Trying private key: /home/matterai/.ssh/id_ed25519
debug1: No more authentication methods to try.
matterai#3.121.46.99: Permission denied (publickey).
I am playing around it few days and I still can't get what am I doing wrong. Its so strange: I can ssh -A (to allow forwarding) to my bastion, I can ssh to my private instance from bastion. But I cant establish SSH tunnel to see my webpage (in the future it will be mongodb) without an error. Need some advice or point to the right direction, please! Thank you.
UPD#1
Ok then. If I make manual forwarding using my local machine and my bastion, I get an expected result. Basically it means run this command on bastion:
ubuntu#bastion: ssh -v -N -L 5000:localhost:8000 ubuntu#10.0.1.68
After that runs command on local/home machine:
matterai#homepc: ssh -v -N -L 5000:localhost:5000 ubuntu#3.121.46.99
When I make a request to localhost:5000 on my local machine, I can see the result page. May I and how if it's possible to combine this two commands? (spoiler: yes, it's possible: see the answer!)
Ok, it's easy. Hope my answer will help somebody.
You need to use ssh -J option to connect through your bastion virtual machine:
-J [user#]host[:port]
Connect to the target host by first making a ssh connection to
the jump host and then establishing a TCP forwarding to the ulti‐
mate destination from there. Multiple jump hops may be specified
separated by comma characters. This is a shortcut to specify a
ProxyJump configuration directive.
Then you need to forward traffic from your destination virtual machine port (:8000) where the app (or database) started to your localhost port (:5001) using ssh -L:
-L [bind_address:]port:host:hostport
-L [bind_address:]port:remote_socket
-L local_socket:host:hostport
-L local_socket:remote_socket
Specifies that connections to the given TCP port or Unix socket
on the local (client) host are to be forwarded to the given host
and port, or Unix socket, on the remote side. This works by
allocating a socket to listen to either a TCP port on the local
side, optionally bound to the specified bind_address, or to a
Unix socket. Whenever a connection is made to the local port or
socket, the connection is forwarded over the secure channel, and
a connection is made to either host port hostport, or the Unix
socket remote_socket, from the remote machine.
Port forwardings can also be specified in the configuration file.
Only the superuser can forward privileged ports. IPv6 addresses
can be specified by enclosing the address in square brackets.
By default, the local port is bound in accordance with the
GatewayPorts setting. However, an explicit bind_address may be
used to bind the connection to a specific address. The
bind_address of “localhost” indicates that the listening port be
bound for local use only, while an empty address or ‘*’ indicates
that the port should be available from all interfaces.
Full ssh command will look like:
matterai#homepc: ssh -v -N -A -J ubuntu#3.121.46.99 -L 5001:localhost:8000 ubuntu#10.0.1.112
UPD: Also you can simplify a bit your command. In ~/.ssh/config you can add your jumphost (bastion) and your final destination VM IP:
Host bastion
HostName 3.121.46.99
User ubuntu
Port 22
IdentityFile ~/.ssh/secret.pem
ForwardAgent yes
Host server
HostName 10.0.1.112
User ubuntu
Port 22
IdentityFile ~/.ssh/secret.pem
ProxyJump bastion
Now, you can run command:
ssh -v -N -A -J bastion -L 80:localhost:8000 server
Looks much better. Also you can just simply connect via ssh using ssh server.
You seem to have things correctly configured, but the error is saying that it can't find a private key to use for the connection.
To test the port forwarding, start by using the ssh command that logs into your public instance.
Then, take that exact command, and simply add: -L 8080:10.0.1.112:80
If it works for 'normal' ssh, then it will work with port forwarding too.
By the way, in general you should never need to modify the outbound rules of a security group. The default settings permit all outbound traffic. This 'trusts' the apps running on the instance and allows them to communicate outwards to anywhere. You would only need to restrict such rules where you wish to enforce a high-security environment.
I'm configuring a NAT instance that should redirect all incoming requests on port 2222 to port 22 of a server in a private subnet on my virtual private cloud, so I can connect with SSH straight to my private instance. I have opened port 2222 on the NAT Instance's security group and 22 on my private instance's security group, as well as added on
/etc/ssh/sshd_config
the following lines:
Port 22
Port 2222
nmap on NAT instance shows that port 2222 is open:
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
111/tcp open rpcbind
2222/tcp open EtherNet/IP-1
I also added this following iptables rule on my NAT instance, hence any packages that comes on port 2222 should be redirected to 10.0.2.18:22 (10.0.2.18 is the private instance IP):
sudo iptables -t nat -A PREROUTING -p tcp --dport 2222 -j DNAT --to-destination 10.0.2.18:22
The problem is that I can't reach port 2222 of my NAT instance, if I try this:
ssh -p 2222 -i mykey.pem ec2-user#my_nat_ip
or this:
nc -zv my_nat_ip 2222
I get a connection time out.
Thanks in advance any help.
A few things for you to check out (assuming you have already ruled out Security Groups):
Check if you haven't denied traffic on your Network ACLs (NACL).
Check if the Route Table for your private subnet is sending traffic to the NAT instance.
Check if you have disabled the Source/Destination Check on your NAT instance.
Also, you might want to enable VPC Flow Logs on your VPC to help you find where those packets might be getting dropped.
And then, another suggestion: you might want to consider an alternative to port forwarding, as this is basically exposing your instance in the private subnet to the dangerous internet. A common approach is to have what is commonly referred to as a Bastion Host. Or a Jump Host. Some people use a NAT instance for this purpose. A few ways to do this would include: (1) use SSH local port forwarding; (2) use SSH dynamic proxy; (3) use the ProxyCommand option on your SSH client. There are plenty of answered questions about all these subjects on StackOverflow and other StackExchange sites, you'll definitely find many ways to do it!