Centos 7.6 wg-quick not working properly

[Eddie]

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 
> <boss_geo2005 at yahoo.com> 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 at lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20190924/7faa4d5b/attachment.html>