no traffic #211
Replies: 26 comments
-
Can you show what your client config file looks like? |
Beta Was this translation helpful? Give feedback.
-
[Interface] [Peer] |
Beta Was this translation helpful? Give feedback.
-
I have a same issue. |
Beta Was this translation helpful? Give feedback.
-
join, does not work. Instagram only loads, the rest of the sites used are not. |
Beta Was this translation helpful? Give feedback.
-
I spun up an Ubuntu 20.04 LTS EC2 instance with nothing else on it, ran updates, and ran this script. It looks like it's generating perfectly valid configuration files, which is great, but then traffic is not routing appropriately. I put in 60064 as the listening port on the server and verified that traffic is allowed through both TCP and UDP on its security group. Running Some output that may help in debugging: # I downloaded the config file and renamed it to make my life easier
# If that breaks things, I can generate a new one and keep the name
$ sudo wg-quick up ./mark.conf
[#] ip link add mark type wireguard
[#] wg setconf mark /dev/fd/63
[#] ip -4 address add 10.66.66.2/32 dev mark
[#] ip -6 address add fd42:42:42::2/128 dev mark
[#] ip link set mtu 1420 up dev mark
[#] resolvconf -a mark -m 0 -x
[#] wg set mark fwmark 51820
[#] ip -6 route add ::/0 dev mark table 51820
[#] ip -6 rule add not fwmark 51820 table 51820
[#] ip -6 rule add table main suppress_prefixlength 0
[#] ip6tables-restore -n
[#] ip -4 route add 0.0.0.0/0 dev mark table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0
[#] sysctl -q net.ipv4.conf.all.src_valid_mark=1
[#] iptables-restore -n
$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp0s20f0u2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 00:0e:c6:d7:0b:01 brd ff:ff:ff:ff:ff:ff
3: gpd0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 500
link/none
4: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
link/ether 9c:30:5b:b5:ab:5b brd ff:ff:ff:ff:ff:ff
5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
link/ether 02:42:09:9b:15:80 brd ff:ff:ff:ff:ff:ff
24: mark: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/none
# This is the interesting part - absolutely no routes related to the interface here
$ ip route
default via 192.168.1.1 dev enp0s20f0u2 proto dhcp src 192.168.1.35 metric 202
default via 192.168.1.1 dev wlp2s0 proto dhcp src 192.168.1.22 metric 304
SERVER_ID_REDACTED via 192.168.1.1 dev enp0s20f0u2
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
192.168.1.0/24 dev enp0s20f0u2 proto kernel scope link src 192.168.1.35 metric 100
192.168.1.0/24 dev enp0s20f0u2 proto dhcp scope link src 192.168.1.35 metric 202
192.168.1.0/24 dev wlp2s0 proto dhcp scope link src 192.168.1.22 metric 304
# Tried curl/ping a few times, all timed out and hung
$ curl 1.1.1.1
^C
$ sudo wg show
interface: mark
public key: # Redacted
private key: (hidden)
listening port: 33047
fwmark: 0xca6c
peer: # Redacted
preshared key: (hidden)
endpoint: # SUPER redacted
allowed ips: 0.0.0.0/0, ::/0
transfer: 0 B received, 2.60 KiB sent |
Beta Was this translation helpful? Give feedback.
-
I am n00b |
Beta Was this translation helpful? Give feedback.
-
There's no fix in that comment, I was just providing some debugging context that I thought might be helpful for @angristan |
Beta Was this translation helpful? Give feedback.
-
FIX(!) |
Beta Was this translation helpful? Give feedback.
-
Changing the MTU has had no effect for me, unfortunately. |
Beta Was this translation helpful? Give feedback.
-
me too |
Beta Was this translation helpful? Give feedback.
-
Okay, for anybody that's been banging their head against the wall - if you're hosting this server in AWS, make sure that your VPC Network ACL allows UDP traffic. It does not by default. I'm not particularly good at writing instructions for this kind of stuff, but - Go to your AWS dashboard, search for VPC in the "services" dropdown, and go there. Click on the VPC you're using (you probably only have 1), and then click on the Network ACL in the bottom panel that opens up. Right click the network ACL in the top panel, choose "edit inbound rules," and create a new rule that allows all UDP traffic from everywhere. Make sure you also have UFW either disabled or configured properly, it comes by default on AWS's Ubuntu images. If you're not on AWS, double check whatever provider or firewall you're using. When in doubt, use That solved my networking problem. That combined with some other changes in recent commits has actually resolved this issue completely for me. I'm not OP, but @angristan you have my sincere apologies for generating notifications unrelated to your code. Hopefully this comment helps other people get their connection sorted out! |
Beta Was this translation helpful? Give feedback.
-
@markrawls This fixed my issue! |
Beta Was this translation helpful? Give feedback.
-
@markrawls This explains why you wouldn't receive any traffic at all. Thanks for finding the issue and providing steps to solve it!
@vahidx4r4x you are using the script before refactoring where there is a subnet mask bug fixed in 0d65a00. I'd suggest to delete |
Beta Was this translation helpful? Give feedback.
-
that line of code was correct, problem still persists |
Beta Was this translation helpful? Give feedback.
-
Can you fix my problem? |
Beta Was this translation helpful? Give feedback.
-
Since your screenshot shows you received 0 packets from your server, check again its firewall and open ports. |
Beta Was this translation helpful? Give feedback.
-
It seems more of a server problem. The wireguard kernel module isn't getting loaded after script setup completion. On the server run this command
if this is what you are getting in output
then, the next step is to make sure the wireguard kernel module is loaded or, not.
if this returns an error, then reboot and see if it works, or, check what's blocking wireguard kernel mod from loading. Since you have no incoming traffic, its a server issue, and can be solved by checking the wireguard logs |
Beta Was this translation helpful? Give feedback.
-
still 0 bytes received ... |
Beta Was this translation helpful? Give feedback.
-
Add in wg0.conf : |
Beta Was this translation helpful? Give feedback.
-
FYI: i also had issues. But, after a reboot, all worked like a charm. |
Beta Was this translation helpful? Give feedback.
-
Enable UDP traffic in your server:
or if you use
|
Beta Was this translation helpful? Give feedback.
-
Bro, the watchdog or watchcat isn't working properly. I make connection successfully but when I power off the router at night and power on in the morning, it does not get the handshake until I ssh to the VPS running wireguard. So WG falls asleep when nothing is connected, I just have to ssh to it and it starts working again. I'm curious why this issue hasn't been fixed yet. |
Beta Was this translation helpful? Give feedback.
-
@xavupkt I faced this issue and reboot server fixes it. |
Beta Was this translation helpful? Give feedback.
-
Rebooted server, Still, 0 bytes received, any other solution? |
Beta Was this translation helpful? Give feedback.
-
Whats your linux dist? |
Beta Was this translation helpful? Give feedback.
-
Same issue here on Ubuntu 18 64-bit
There is a link and handshake. No internet |
Beta Was this translation helpful? Give feedback.
-
hi i just used your script and its running
but i want to connect to vpn server using wiregaurd on windows
i can connect to vpn server but there is no inbound traffic at all, i cant do anything!
whats the fix?
Beta Was this translation helpful? Give feedback.
All reactions