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