Hi Eddie, Thanks for the response, I figured is was something with either the kernel or iproute and I guess either the kernel does not support it or the iproute2 version does not "completely support it" or has a bug. On your note about updating the kernel, the funny thing is initially I tried this on Oracle Linux (that comes with 4.14.35-1902.3.1.el7uek.x86_64) by default and when I was ending up in kernel panics, so I though it might be because the kernel is too new or something. For the moment I resolved my problem installing a Ubuntu that works without any issue. I still have the Oracle Linux machine (4.14.35-1902.3.1.el7uek.x86_64) so if anyone want to me to do any debug and provide the response, I am happy to do it. Although it might or not be relevant all are Virtual Machine in Hyper-v, both the ubuntu one(working) and the Centos(failing one) and the Oracle Linux(kernel panics one) Thanks George On Tuesday, 24 September 2019, 06:29:07 pm GMT+3, Eddie wrote: I'll just repeat verbatim the response I got from Silvan (thank you) when I reported the same issue previously: The main problem is that the current standard kernel of CentOS simple does not support the handling of "suppress_prefixlength". Iproute2 supports it since it does not return any error while adding so it had to be the kernel causing problems. In essence Red Hats official answer was "It isn't a bug, RHEL7 simple does not support it". If you sill want to fix your problem just upgrade your kernel to long-term or mainline. Cheers. On 9/16/2019 11:47 AM, George Lucan wrote: Hello, Some further investigations have revealed that actually the "second main" table gets created by the last command executed by wg-quick "ip -4 rule add table main suppress_prefixlength 0". Will try to figure out what is happening further. George On Sunday, 15 September 2019, 9:32:41 pm GMT+3, George Lucan wrote: Hello, I have been trying for several days to setup a wireguard vpn and send all the traffic from a VM to another site (redirect gateway scenario). Site A OS is Centos 7.6 installed with docker and wireguard installed Site B OS is a Opensense 19.7.4 with wireguard installed from the plugin and a bunch of other things on it I believe the issue is within Ip route on Centos 7.6 but I am reaching out for maybe different opinions. On the Centos VM I am using wireguard installed from the repos on the website and using systemd to bring up the tunnel. Everything seem to be brought up correctly except that the traffic does not go through the tunnel. Further investigating I noticed something unusual (in my opinion). Before the tunnel is up: #ip rule show 0: from all lookup local 32766: from all lookup main 32767: from all lookup default After the tunnel is up: #ip rule show 0: from all lookup local 32764: from all lookup main 32765: not from all fwmark 0xca6c lookup 51820 32766: from all lookup main 32767: from all lookup default To me is seems like somehow there are 2 tables named "main" one after the new table created by wg-quick (looking at the priority it seems it is the same one that was present previously) and another one that gets create out of thin air before the wireguard created one named 51820. Ping works through the tunnel for IP to the other end of the tunnel #wg interface: wg0 public key: 8JXLXfl1W2xZd1T+zaCKSNB+FhUbb1IquIHvHhY7/iY= private key: (hidden) listening port: 34559 fwmark: 0xca6c peer: 04kTPSrh08X5uOCmL5aM1iCm8UqFHGtJDsrsPReafS8= endpoint: 188.27.172.68:1300 allowed ips: 0.0.0.0/0 latest handshake: 1 minute, 41 seconds ago transfer: 87.85 KiB received, 415.61 KiB sent persistent keepalive: every 15 seconds# ping 192.168.249.1 PING 192.168.249.1 (192.168.249.1) 56(84) bytes of data. 64 bytes from 192.168.249.1: icmp_seq=1 ttl=64 time=89.2 ms 64 bytes from 192.168.249.1: icmp_seq=2 ttl=64 time=89.5 ms Is there any step that I might have missed or any kernel feature that would explain the behaviour? Worth mentioning it is a home env so I can test whatever is needed to get to the bottom of it. Thanks George _______________________________________________ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard