From: Eddie <stunnel@attglobal.net>
To: George Lucan <boss_geo2005@yahoo.com>,
WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: Centos 7.6 wg-quick not working properly
Date: Tue, 24 Sep 2019 08:29:03 -0700 [thread overview]
Message-ID: <26c139a5-d8a4-528f-d777-937966557699@attglobal.net> (raw)
In-Reply-To: <432951712.5476709.1568659634512@mail.yahoo.com>
[-- Attachment #1.1: Type: text/plain, Size: 3453 bytes --]
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@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@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
[-- Attachment #1.2: Type: text/html, Size: 9816 bytes --]
[-- Attachment #2: Type: text/plain, Size: 148 bytes --]
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
next prev parent reply other threads:[~2019-09-24 15:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1429556426.5086611.1568572361543.ref@mail.yahoo.com>
2019-09-15 18:32 ` Centos 7.6 wg-quick not working properly George Lucan
2019-09-16 18:47 ` George Lucan
2019-09-24 15:29 ` Eddie [this message]
2019-09-24 19:23 ` George Lucan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=26c139a5-d8a4-528f-d777-937966557699@attglobal.net \
--to=stunnel@attglobal.net \
--cc=boss_geo2005@yahoo.com \
--cc=wireguard@lists.zx2c4.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).