ipv6 multicast peer ?

[nicolas prochazka]

Hello,
On a "server side" I've for example these peers, and i want to send a
ipv6 multicast group
ff02::1
How can I do that with peer / allowed-ips routing ?

Regards
Nicolas

interface: wg0
  public key: **
  private key: (hidden)
  listening port: 6081

peer: 
  preshared key: (hidden)
  endpoint: x.x.130.134:6081
  allowed ips: fd00:0:222d:0:f64d:30ff:fe6e:222d/128
  latest handshake: 52 seconds ago
  transfer: 56.96 MiB received, 1.96 GiB sent

peer: **
  preshared key: (hidden)
  endpoint: x.x.x.x:6081
  allowed ips: fd00::8e2:97ff:fe2e:3/128,
fd00:0:2836:0:1e69:7aff:fe01:2836/128,
fd00:0:3340:0:a00:27ff:fe5a:3340/128
  latest handshake: 1 minute, 54 seconds ago
  transfer: 513.17 MiB received, 6.27 GiB sent
  persistent keepalive: every 25 seconds

peer: *
  preshared key: (hidden)
  endpoint: x.x.x.x:6081
  allowed ips: fd00::/32, fd00::8e2:97ff:fe2e:0/112,
fd00::8e2:97ff:fe2e:/128
  latest handshake: 1 minute, 59 seconds ago
  transfer: 2.70 MiB received, 6.69 MiB sent
  persistent keepalive: every 25 seconds

peer: **
  preshared key: (hidden)
  endpoint: x.x.100.142:6081
  allowed ips: fd00:0:ec58:0:b26e:bfff:fe1e:2d5a/128
  latest handshake: 2 minutes, 5 seconds ago
  transfer: 195.00 MiB received, 2.19 GiB sent

Re: Question about origin of packet relative to peer

[nicolas prochazka]

Yes, I can mark the  wireguard packet  allowedips but i cannot attach
to the associated peer.In my configuration, ip from wireguard (
alllowedip) can come from different peer ( because i'm using different
mask for allowedips and multiple tunnel).
My issue is that a packet can be used by a peer and come back by an
other one ( the packet is routing by allowed-ips, not by it's peer
entry

Example :

On server side S1
Peer A (client peer)
allowedips 192.168.1.0/24

Peer B  ( an other "wireguard server"  S2  )
allowedIps 192.168.1.100/32

On client Side, allowedIp is set on s2 and if s2 down , set to s1
peer s1 ==> server S1
peer s2 ==> server S2 ==> server S1

Of course it does not work, packet routing does not work
client ==> S2 ==>  S1 (peer A)  ==>  then response route to peer (B)

Regards,
Nicolas




Le mer. 27 mai 2020 à 13:46, Arti Zirk  a écrit :
>
> On K, 2020-05-27 at 11:01 +0200, nicolas prochazka wrote:
> > How can i know that a packet come from peer X ?
> You can check which peers allowed ips list covers the received packets
> source ip
>
> > Is is possible to mark packet not a level interface (wg0) but at peer
> > level ?
> Its probably possible to generate iptables rules from peer allowed ips
> list that marks packets with different ids
>

Question about origin of packet relative to peer

[nicolas prochazka]

Hello,
Using one wireguard Interface, with multiple peer
How can i know that a packet come from peer X ?
Is is possible to mark packet not a level interface (wg0) but at peer level ?
I can dump packet at wg0 but i lost the peer origin.

Thanks,
Nicolas

interface: wg0
  public key: A
  private key: (hidden)
  listening port: 6081

peer: B
  preshared key: (hidden)
  endpoint: ipb
  allowed ips:
  latest handshake: 1 minute, 27 seconds ago
  transfer: 1.61 MiB received, 6.20 MiB sent
  persistent keepalive: every 25 seconds

peer:C
  preshared key: (hidden)
  endpoint: ipc
  allowed ips:
  latest handshake: 1 minute, 38 seconds ago
  transfer: 24.75 KiB received, 309.71 KiB sent
  persistent keepalive: every 25 seconds

Wireguard, allowed-ips, ipv6 and multicast

[nicolas prochazka]

Hello,
I'm trying to use vxlan encapsulated into Wireguard tunnel, with a
multicast group for announcement.
Ex :
ip -6 link add vxlan100 type vxlan id 100 dstport 4789  local
`wg0Ip6_lock`  group ff05::100 dev wg0 ttl 5

All works very well when i set wg tunnel with ::/0  as allowed-ips,
but if i'm trying to be more restrictive, as ff05::/32  for example,
it does not work.
Is a specific interaction between allowed-ips and multicast group in ipv6 ?

Regards,
Nicolas Prochazka.

Usage Add/Remove Allowed-ip

[nicolas prochazka]

Hello,
Is it possible to add/remove Allowed-ip in peer description without
modify configuration file or using wg set command,
I think about wg peer add|remove allowed-ip

Regards,
Nicolas Prochazka
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

about wireguard-go

[nicolas prochazka]

Hello,
We need to compile wireguard-go on linux, because we are using a closed
linux, under we cannot compile module,
how can we do ? make on wireguard-go tells us that is not recommend on linux

Regards,
Nicolas Prochazka
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Reflections on WireGuard Design Goals

[nicolas prochazka]

hello,
just to say you, as a simple end user
we are using wireguard since one year for our product,
we have 10K tunnels deployed ,
wireguard is perfect for us, very simple, we can develop our specific
code on top of if ( key management , )
so +1 for jason vision
thanks for this piece of code
Regards,
Nicolas

Le jeu. 9 août 2018 à 23:52, Jason A. Donenfeld  a écrit :
>
> Hey list,
>
> For whatever reason, in the last several weeks, WireGuard been receiving a
> considerable amount of attention, and with that comes various parties
> interested in the project moving in this direction or in that direction. And
> more generally, over the last year or so, we've seen a decent amount of
> interest from different folks wanting to do different things with the project
> and with the protocol. This inevitably leads to the question: what do we
> actually want WireGuard to be, as a project, as a protocol, as a set of
> implementations, as a design methodology, and so forth? I've had a pretty
> clear idea about that, but I don't think I've ever tried to communicate
> aspects of it in this context, so I thought here I'd highlight two important
> design goals that motivate us.
>
> Firstly, WireGuard intends on continuing to have a minimal core, without a lot
> of options and wild features and support for weird networking paradigms. Sure,
> we want the core to be sufficiently flexible that you can build interesting
> and complex things on top of it, but we don't want WireGuard itself to be
> complicated. We enjoy our small understandable configuration files, an
> interface that appears to be mostly stateless, and general ease of use. Even
> from a cryptography and implementation perspective, the protocol is designed
> to be implementable using simple algorithms and coding techniques.
>
> With that kind of minimalism naturally comes the temptation to add things.
> Simply from the perspective of an interested engineer, it's appealing to
> extend and hack on small manageable codebases and projects, since adding a
> single feature here or there just isn't that hard. And after all, if you're
> *just* adding *one* feature, it's only one, and that's not so bad, right? And
> what about one more? This kind of temptation applies equally to features
> inside implementations as it does to features inside the protocol. And I think
> this temptation is a little bit dangerous, both because it's an obvious
> slippery slope to bloat ("just one more feature can't hurt, right guys?"), and
> because while individual features or protocol enhancements might be well
> thought-out, it's often hard to think through them in the context of a fuller
> system.
>
> Secondly, WireGuard is engineered slowly and carefully. It is a conservative
> project. Programming is fun, and so I understand the appeal to, "move fast and
> break things," or to ship new code hastily. Personally I've written plenty of
> such codebases, and that's usually fun and exciting. Except WireGuard is
> deeply security-oriented. Of course there will inevitably be scary bugs we
> weren't able to prevent, but we're moving slow and carefully to try to
> mitigate those to the fullest extent we can. We want each of the
> implementations released by the WireGuard project to be secure, high assurance
> software.
>
> This means that although you can probably get something mostly "working" in a
> fairly short amount of time (an initial version of WireGuard took me
> essentially a weekend), we're trying very hard not to throw junk over the
> fence. Rather, we're doing pretty regular code reviews and have received some
> great feedback from some scary-talented security researchers, and we expect
> for this to continue. But indeed not all programmers share this perspective –
> for a wide variety of motivations, both benign and opportunistic – and so we
> definitely will (and have, in fact, already) see folks making things related
> to WireGuard who don't share this type of methodology.
>
> Now I don't think these two motivating principles are particularly unique or
> innovative. Other security-focused projects, like OpenBSD for example, seem to
> be made of a somewhat similar mold. But these also certainly are not the
> _norm_ for most projects out there. And as WireGuard accelerates in usage, I
> expect we'll be facing this from a few angles:
>
> - Attempts at commercialization: There are many businesses who want to embrace
>   WireGuard and extend it in some particular direction or another, in order to
>   build products or sell services or the usual array of business
>   opportunities. Engineers working in these contexts often times are tempted
>   to extend minimal things in grotesque ways, and to push them to market with
>   deadlines unfavorable to high assurance methodologies. It's naturally and
>   understandably in the interest of businesses to attempt to steer the
>   WireGuard project in directions aligned with their goals, or even directly
>   hire WireGuard developers away 

Re: about high availibity

[nicolas prochazka]

ok and thanks
nicolas 

  https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail;
target="_blank">https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif;
alt="" width="46" height="29" style="width: 46px; height: 29px;"
/>
Garanti sans virus. https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail;
target="_blank" style="color: #4453ea;">www.avast.com   




2017-11-23 12:52 GMT+01:00 Jason A. Donenfeld :
> Hi Nicolas,
>
> You can't change that parameter, and I won't ever add that option.
> This isn't negotiable.
>
> However, I'll at some point be adding netlink event notifications, so
> that you learn when WireGuard itself has detected connectivity
> problems (usually in about 15 seconds), and react accordingly.
>
> Jason
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: [wireguard-dev] Ability to use one udp port for multiple wg interfaces

[nicolas prochazka]

Ok,
To be more precise, the uses cases are :
services ( as daemon ) are listening on specifiq interface/Ipv6
address to secure and active service by client, with only one
interface, it is not possible, aliasing seems to be not relevant.
However i can understand that is not the problem of wireguard ,
perhaps can you tell us if an internal dev is possible or if the
nature of wireguard forbid this ?

Regards,
Nicolas
Ps : sorry for the prefix

2017-09-21 13:55 GMT+02:00 Jason A. Donenfeld :
> Please do not prefix your email subjects with [wireguard-dev].
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: [wireguard-dev] Ability to use one udp port for multiple wg interfaces

[nicolas prochazka]

Hello,
i known, but we are using one interface by customer, each interface
manages multiple peers ( > 500 )
as
wg_interface0 = client 0  = 500 peers
wf_interfacen= client n = 500 peers

at this moment, only one interface wg0  manage all peers and all
customers , it's very complicating for the administrive tasks , qos,
client separation 

Regards,
NIcolas

2017-09-21 13:25 GMT+02:00 Jason A. Donenfeld :
> I'd recommend you use multiple peers per interface. The strong binding
> with allowed-ips enables you to use qos, network analysis, security,
> and iptables rules in a very straightforward way.
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

[wireguard-dev] Ability to use one udp port for multiple wg interfaces

[nicolas prochazka]

Hello,
this question have alreadry be post in the past, but i need some help.
We want create one wireguard interface by client, because at this
moment, we are using one interface for all our client, and it's
becomes very difficult to manage in term of Qos , network analyse ,
security , iptables ..
With mutliple interface, all is good in term of performance with the
last release , but each interface must have it's own port, that  is
not possible to manage ( different port by client )
Is there a solution ?
Regards,
Nicolas Prochazka
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: [wireguard-dev] Help about configuration

[nicolas prochazka]

hello,
you're right, sorry , it's just a old nat rule .
regards,
Nicolas

2017-09-20 17:21 GMT+02:00 Jason A. Donenfeld <ja...@zx2c4.com>:
> Seems likely the wrong source IP is being used for sending the ping. Use
> tcpdump on the initiating computer to make sure the source IP of the ping
> packet matches the allowed-ips of the other machine.
>
> --
> Sent from my telephone.
>
> On Sep 20, 2017 17:11, "nicolas prochazka" <prochazka.nico...@gmail.com>
> wrote:
>
> Hello, can somebody tells me what I do wrong :
> I can ping from server 1 --> client 1  ( ping fd00:14::8b5:8aff:fe85:f3ee )
> .
> but not from client 1 --> server1  ( ping fd00:14::8b5:8aff:fe85:f3ec )
>
> we can notice
> RX packets:230 errors:1112 dropped:0 overruns:0 frame:1112
> on server side  seems strange
>
> wireguard : v0.0.20170918]
> kernel : 4.9.23 on client1
> kernel : 4.4.0 on server 1
>
>
> Regards,
> Nicolas Prochazka
>
> Server 1 :
> ifconfig neocoretech_rd
> neocoretech_rd Link encap:UNSPEC  HWaddr
> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
>   inet6 addr: fd00:14::8b5:8aff:fe85:f3ec/32 Scope:Global
>   UP POINTOPOINT RUNNING NOARP  MTU:1420  Metric:1
>   RX packets:230 errors:1112 dropped:0 overruns:0 frame:1112
>   TX packets:390 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1
>   RX bytes:24672 (24.6 KB)  TX bytes:39104 (39.1 KB)
>
>
> [52.209.226.5]~/resources/tunnelHelper>wg showconf neocoretech_rd
> [Interface]
> ListenPort = 6081
> PrivateKey = mNHgDu3Nbusb3Xd8tI8imBkFgvnUSCjKGVP5qT8pi2Q=
>
> [Peer]
> PublicKey = 5zSx+CxgcjLKE2shpkTrLFgCHNOPM6r7TcuZ5cSx2AA=
> AllowedIPs = fd00:14::8b5:8aff:fe85:f3ee/128
> Endpoint = 77.156.254.18:25813
>
> wg show neocoretech_rd
> interface: neocoretech_rd
>   public key: lrJtbn/Jfdb1NyIP78ls11uqAzjcWzDuD+x05RxFk20=
>   private key: (hidden)
>   listening port: 6081
>
> peer: 5zSx+CxgcjLKE2shpkTrLFgCHNOPM6r7TcuZ5cSx2AA=
>   endpoint: 77.156.254.18:25813
>   allowed ips: fd00:14::8b5:8aff:fe85:f3ee/128
>   latest handshake: 1 minute, 10 seconds ago
>   transfer: 23.95 KiB received, 36.07 KiB sent
>
>
>
> Client 1 :
> ifconfig wg0
> wg0   Link encap:UNSPEC  HWaddr
> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
>   inet6 addr: fd00:14::8b5:8aff:fe85:f3ee/8 Scope:Global
>   UP POINTOPOINT RUNNING NOARP  MTU:1420  Metric:1
>   RX packets:230 errors:0 dropped:0 overruns:0 frame:0
>   TX packets:1366 errors:0 dropped:0 overruns:0 carrier:0
>   collisions:0 txqueuelen:1
>   RX bytes:23632 (23.0 KiB)  TX bytes:230352 (224.9 KiB)
>
>
> [optimizer] wg showconf wg0
> [Interface]
> ListenPort = 6081
> PrivateKey = IM0tv9xWcVBPhD7+Tny7LHnYu1YHBGCJbBr6fgCdZns=
>
> [Peer]
> PublicKey = lrJtbn/Jfdb1NyIP78ls11uqAzjcWzDuD+x05RxFk20=
> AllowedIPs = ::/0
> Endpoint = 52.209.226.5:6081
> PersistentKeepalive = 25
>
> wg show wg0
> interface: wg0
>   public key: 5zSx+CxgcjLKE2shpkTrLFgCHNOPM6r7TcuZ5cSx2AA=
>   private key: (hidden)
>   listening port: 6081
>
> peer: lrJtbn/Jfdb1NyIP78ls11uqAzjcWzDuD+x05RxFk20=
>   endpoint: 52.209.226.5:6081
>   allowed ips: ::/0
>   latest handshake: 37 seconds ago
>   transfer: 22.99 KiB received, 215.96 KiB sent
>   persistent keepalive: every 25 seconds
> ___
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>
>
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

[wireguard-dev] Help about configuration

[nicolas prochazka]

Hello, can somebody tells me what I do wrong :
I can ping from server 1 --> client 1  ( ping fd00:14::8b5:8aff:fe85:f3ee ) .
but not from client 1 --> server1  ( ping fd00:14::8b5:8aff:fe85:f3ec )

we can notice
RX packets:230 errors:1112 dropped:0 overruns:0 frame:1112
on server side  seems strange

wireguard : v0.0.20170918]
kernel : 4.9.23 on client1
kernel : 4.4.0 on server 1


Regards,
Nicolas Prochazka

Server 1 :
ifconfig neocoretech_rd
neocoretech_rd Link encap:UNSPEC  HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
  inet6 addr: fd00:14::8b5:8aff:fe85:f3ec/32 Scope:Global
  UP POINTOPOINT RUNNING NOARP  MTU:1420  Metric:1
  RX packets:230 errors:1112 dropped:0 overruns:0 frame:1112
  TX packets:390 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1
  RX bytes:24672 (24.6 KB)  TX bytes:39104 (39.1 KB)


[52.209.226.5]~/resources/tunnelHelper>wg showconf neocoretech_rd
[Interface]
ListenPort = 6081
PrivateKey = mNHgDu3Nbusb3Xd8tI8imBkFgvnUSCjKGVP5qT8pi2Q=

[Peer]
PublicKey = 5zSx+CxgcjLKE2shpkTrLFgCHNOPM6r7TcuZ5cSx2AA=
AllowedIPs = fd00:14::8b5:8aff:fe85:f3ee/128
Endpoint = 77.156.254.18:25813

wg show neocoretech_rd
interface: neocoretech_rd
  public key: lrJtbn/Jfdb1NyIP78ls11uqAzjcWzDuD+x05RxFk20=
  private key: (hidden)
  listening port: 6081

peer: 5zSx+CxgcjLKE2shpkTrLFgCHNOPM6r7TcuZ5cSx2AA=
  endpoint: 77.156.254.18:25813
  allowed ips: fd00:14::8b5:8aff:fe85:f3ee/128
  latest handshake: 1 minute, 10 seconds ago
  transfer: 23.95 KiB received, 36.07 KiB sent



Client 1 :
ifconfig wg0
wg0   Link encap:UNSPEC  HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
  inet6 addr: fd00:14::8b5:8aff:fe85:f3ee/8 Scope:Global
  UP POINTOPOINT RUNNING NOARP  MTU:1420  Metric:1
  RX packets:230 errors:0 dropped:0 overruns:0 frame:0
  TX packets:1366 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1
  RX bytes:23632 (23.0 KiB)  TX bytes:230352 (224.9 KiB)


[optimizer] wg showconf wg0
[Interface]
ListenPort = 6081
PrivateKey = IM0tv9xWcVBPhD7+Tny7LHnYu1YHBGCJbBr6fgCdZns=

[Peer]
PublicKey = lrJtbn/Jfdb1NyIP78ls11uqAzjcWzDuD+x05RxFk20=
AllowedIPs = ::/0
Endpoint = 52.209.226.5:6081
PersistentKeepalive = 25

wg show wg0
interface: wg0
  public key: 5zSx+CxgcjLKE2shpkTrLFgCHNOPM6r7TcuZ5cSx2AA=
  private key: (hidden)
  listening port: 6081

peer: lrJtbn/Jfdb1NyIP78ls11uqAzjcWzDuD+x05RxFk20=
  endpoint: 52.209.226.5:6081
  allowed ips: ::/0
  latest handshake: 37 seconds ago
  transfer: 22.99 KiB received, 215.96 KiB sent
  persistent keepalive: every 25 seconds
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: multiple wireguard interface and kworker ressources

[nicolas prochazka]

hello,
one interface = one public key
with multiples interfaces we can manage mutliples ip without aliasing,
it's more confortable to bind some specific service .
statisitiques informations ( bp, error) is more easily to manage with
differents interfaces

we are talking about ~ 1000 wireguard interfaces with 500 tunnels
(peer) for each .

Nicolas

2017-06-14 16:15 GMT+02:00 Jason A. Donenfeld <ja...@zx2c4.com>:
> On Wed, Jun 14, 2017 at 3:50 PM, nicolas prochazka
> <prochazka.nico...@gmail.com> wrote:
>> At this moment, we are using  3000 wg tunnel on a single wireguard
>> interface, but now
>> we want divide the tunnels by interface and by group of our client, to
>> manage qos by wireguard interface, and some other tasks.
>> So on in a single interface, it's working well, but test with 3000
>> interface causes some trouble about cpu / load average , performance
>> of vm.
>
> This seems like a bad idea. Everything will be much better if you
> continue to use one tunnel. If you want to do QoS or any other type of
> management, you can safely do this per-IP, since the allowed IPs
> concept gives strong binding between public key and IP address.
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: multiple wireguard interface and kworker ressources

[nicolas prochazka]

hello,
after create of wg interface, kworker thread does not return to a
normal state in my case,
kernel thread continues to consume a lot of cpu .
I must delete wireguard interface to kworker decrease.

Nicolas

2017-06-13 23:47 GMT+02:00 Jason A. Donenfeld :
> Hi Nicolas,
>
> It looks to me like some resources are indeed expended in adding those
> interfaces. Not that much that would be problematic -- are you seeing
> a problematic case? -- but still a non-trivial amount.
>
> I tracked it down to WireGuard's instantiation of xt_hashlimit, which
> does some ugly vmalloc, and it's call into the power state
> notification system, which uses a naive O(n) algorithm for insertion.
> I might have a way of amortizing on module insertion, which would
> speed things up. But I wonder -- what is the practical detriment of
> spending a few extra cycles on `ip link add`? What's your use case
> where this would actually be a problem?
>
> Thanks,
> Jason
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: multiple wireguard interface and kworker ressources

[nicolas prochazka]

Hello again,
with 0.0.20170613  , i can reproduce a big kworker cpu time consumption
Regards,
nicolas

2017-06-13 14:48 GMT+02:00 Jason A. Donenfeld :
> Hi Nicolas,
>
> I'll look into this. However, you need to update WireGuard to the
> latest version, which is 0.0.20170613. I can't provide help for
> outdated versions.
>
> Jason
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: [wireguard-devel ] traffic shapping

[Nicolas Prochazka]

in doubt i add all ipv6 kernel options ...
and i'm using tc filter , not iptables fwmark.

Regards,
Nicolas

2017-03-08 17:00 GMT+01:00 Baptiste Jonglez <bapti...@bitsofnetworks.org>:

> Hi Nicolas,
>
> For posterity, can you be more specific about how you solved your issue?
> You were simply missing traffic shaping support for IPv6 in your kernel?
> Which symbols were needed?
>
> Thanks,
> Baptiste
>
> On Wed, Mar 08, 2017 at 02:39:23PM +0100, Nicolas Prochazka wrote:
> > hello,
> > to close, it's working perfectly well in ipv4 and then when i correctly
> > configure my kernel, perfectly well for ipv6.
> > Regards,
> > Nicolas
> >
> > 2017-03-08 12:26 GMT+01:00 Nicolas Prochazka <
> nicolas.procha...@gmail.com>:
> >
> > > Hello again,
> > > So i verify my configuration,
> > > - on a virtual tap , traffic shaping is ok with same configuration
> > > - on physical card, traffic shaping is ok
> > > - on wg0 , all traffic are going to default queue,filter seems to be
> not
> > > applied ,  tcpdump on wg0 is ok with my queue definition, only
> difference
> > > is wg0 is configured as ipv6 tunnel.
> > >
> > >
> > > Regards,
> > > NIcolas
> > >
> > >
> > >
> > > 2017-03-06 18:40 GMT+01:00 Nicolas Prochazka <
> nicolas.procha...@gmail.com>
> > > :
> > >
> > >> Hello,
> > >> is there an incompatibilty between wireguard and traffic shaping or i
> > >> misconfig something  ?
> > >>
> > >> After configuring Qos , I need to add filter to flow
> > >>
> > >> If i'm trying with simple tc command :
> > >> tc filter add dev wg0 protocol ip parent 1: prio 10 u32 match ip
> dport 80
> > >> 0x flowid 1:10
> > >>
> > >> or If i'm trying with tc + iptables,
> > >>
> > >> tc filter add dev wg0 protocol ip parent 1: prio 1 handle 6 fw flowid
> 1:10
> > >> and iptables mark rules,
> > >>
> > >> traffic seems to be not "apply" to queue .
> > >>
> > >> Regards,
> > >> Nicolas Prochazka.
> > >>
> > >> -
> > >> Example :  after this configuration, traffic on wg0 on port
> 80,443,8080
> > >> are going to 1:30 ,not to 1:10
> > >> _trafficShappingMaxRate=15
> > >>
> > >> tc qdisc del dev wg0 root
> > >>
> > >> tc qdisc add dev wg0 root handle 1: htb default 30
> > >>
> > >> # Base
> > >> tc class add dev wg0 parent 1: classid 1:1 htb rate
> > >> ${_trafficShappingMaxRate}mbit burst 15k
> > >>
> > >> # http/https
> > >>
> > >> # Class 1:10,
> > >> tc class add dev wg0 parent 1:1 classid 1:10 htb rate
> > >> ${_trafficShappingMaxRate}mbit ceil ${_trafficShappingMaxRate} burst
> 15k
> > >>
> > >> # Class 1:20,
> > >> tc class add dev wg0 parent 1:1 classid 1:20 htb rate
> > >> ${_trafficShappingMaxRate}mbit ceil ${_trafficShappingMaxRate}mbit
> burst 15k
> > >>
> > >> # Class 1:30, which has a rate of 1kbit. This one is the default
> class.
> > >> tc class add dev wg0 parent 1:1 classid 1:30 htb rate 10kbit ceil
> 1mbit
> > >> burst 15k
> > >>
> > >> tc qdisc add dev wg0 parent 1:10 handle 10: fq_codel quantum 300 noecn
> > >> tc qdisc add dev wg0 parent 1:20 handle 20: fq_codel quantum 300 noecn
> > >> tc qdisc add dev wg0 parent 1:30 handle 30: fq_codel quantum 300 noecn
> > >>
> > >> # --- associate queue with traffic
> > >>
> > >> #tc filter add dev wg0 protocol ipv6 parent 1: prio 1 handle 6 fw
> flowid
> > >> 1:10
> > >> # http/https
> > >> tc filter add dev wg0 protocol ipv6 parent 1: prio 10 u32 match ip
> dport
> > >> 80 0x flowid 1:10
> > >> tc filter add dev wg0 protocol ipv6 parent 1: prio 10 u32 match ip
> dport
> > >> 443 0x flowid 1:10
> > >> tc filter add dev wg0 protocol ipv6 parent 1: prio 10 u32 match ip
> dport
> > >> 8080 0x flowid 1:10
> > >> # ncfs
> > >> tc filter add dev wg0 parent 1: protocol ipv6 prio 5 u32 match ip
> dport
> > >> 16379 0x flowid 1:20
> > >> # icmp
> > >> tc filter add dev wg0 parent 1: protocol ip prio 1 u32 match  ip
> protocol
> > >> 1 0xff flowid 1:30
> > >>
> > >> tc -s qdisc ls dev wg0
> > >>
> > >>
> > >
>
> > ___
> > WireGuard mailing list
> > WireGuard@lists.zx2c4.com
> > https://lists.zx2c4.com/mailman/listinfo/wireguard
>
>
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: [wireguard-devel ] traffic shapping

[Nicolas Prochazka]

Hello again,
So i verify my configuration,
- on a virtual tap , traffic shaping is ok with same configuration
- on physical card, traffic shaping is ok
- on wg0 , all traffic are going to default queue,filter seems to be not
applied ,  tcpdump on wg0 is ok with my queue definition, only difference
is wg0 is configured as ipv6 tunnel.


Regards,
NIcolas



2017-03-06 18:40 GMT+01:00 Nicolas Prochazka <nicolas.procha...@gmail.com>:

> Hello,
> is there an incompatibilty between wireguard and traffic shaping or i
> misconfig something  ?
>
> After configuring Qos , I need to add filter to flow
>
> If i'm trying with simple tc command :
> tc filter add dev wg0 protocol ip parent 1: prio 10 u32 match ip dport 80
> 0x flowid 1:10
>
> or If i'm trying with tc + iptables,
>
> tc filter add dev wg0 protocol ip parent 1: prio 1 handle 6 fw flowid 1:10
> and iptables mark rules,
>
> traffic seems to be not "apply" to queue .
>
> Regards,
> Nicolas Prochazka.
>
> -
> Example :  after this configuration, traffic on wg0 on port 80,443,8080
> are going to 1:30 ,not to 1:10
> _trafficShappingMaxRate=15
>
> tc qdisc del dev wg0 root
>
> tc qdisc add dev wg0 root handle 1: htb default 30
>
> # Base
> tc class add dev wg0 parent 1: classid 1:1 htb rate
> ${_trafficShappingMaxRate}mbit burst 15k
>
> # http/https
>
> # Class 1:10,
> tc class add dev wg0 parent 1:1 classid 1:10 htb rate
> ${_trafficShappingMaxRate}mbit ceil ${_trafficShappingMaxRate} burst 15k
>
> # Class 1:20,
> tc class add dev wg0 parent 1:1 classid 1:20 htb rate
> ${_trafficShappingMaxRate}mbit ceil ${_trafficShappingMaxRate}mbit burst 15k
>
> # Class 1:30, which has a rate of 1kbit. This one is the default class.
> tc class add dev wg0 parent 1:1 classid 1:30 htb rate 10kbit ceil 1mbit
> burst 15k
>
> tc qdisc add dev wg0 parent 1:10 handle 10: fq_codel quantum 300 noecn
> tc qdisc add dev wg0 parent 1:20 handle 20: fq_codel quantum 300 noecn
> tc qdisc add dev wg0 parent 1:30 handle 30: fq_codel quantum 300 noecn
>
> # --- associate queue with traffic
>
> #tc filter add dev wg0 protocol ipv6 parent 1: prio 1 handle 6 fw flowid
> 1:10
> # http/https
> tc filter add dev wg0 protocol ipv6 parent 1: prio 10 u32 match ip dport
> 80 0x flowid 1:10
> tc filter add dev wg0 protocol ipv6 parent 1: prio 10 u32 match ip dport
> 443 0x flowid 1:10
> tc filter add dev wg0 protocol ipv6 parent 1: prio 10 u32 match ip dport
> 8080 0x flowid 1:10
> # ncfs
> tc filter add dev wg0 parent 1: protocol ipv6 prio 5 u32 match ip dport
> 16379 0x flowid 1:20
> # icmp
> tc filter add dev wg0 parent 1: protocol ip prio 1 u32 match  ip protocol
> 1 0xff flowid 1:30
>
> tc -s qdisc ls dev wg0
>
>
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

[wireguard-devel ] traffic shapping

[Nicolas Prochazka]

Hello,
is there an incompatibilty between wireguard and traffic shaping or i
misconfig something  ?

After configuring Qos , I need to add filter to flow

If i'm trying with simple tc command :
tc filter add dev wg0 protocol ip parent 1: prio 10 u32 match ip dport 80
0x flowid 1:10

or If i'm trying with tc + iptables,

tc filter add dev wg0 protocol ip parent 1: prio 1 handle 6 fw flowid 1:10
and iptables mark rules,

traffic seems to be not "apply" to queue .

Regards,
Nicolas Prochazka.

-
Example :  after this configuration, traffic on wg0 on port 80,443,8080 are
going to 1:30 ,not to 1:10
_trafficShappingMaxRate=15

tc qdisc del dev wg0 root

tc qdisc add dev wg0 root handle 1: htb default 30

# Base
tc class add dev wg0 parent 1: classid 1:1 htb rate
${_trafficShappingMaxRate}mbit burst 15k

# http/https

# Class 1:10,
tc class add dev wg0 parent 1:1 classid 1:10 htb rate
${_trafficShappingMaxRate}mbit ceil ${_trafficShappingMaxRate} burst 15k

# Class 1:20,
tc class add dev wg0 parent 1:1 classid 1:20 htb rate
${_trafficShappingMaxRate}mbit ceil ${_trafficShappingMaxRate}mbit burst 15k

# Class 1:30, which has a rate of 1kbit. This one is the default class.
tc class add dev wg0 parent 1:1 classid 1:30 htb rate 10kbit ceil 1mbit
burst 15k

tc qdisc add dev wg0 parent 1:10 handle 10: fq_codel quantum 300 noecn
tc qdisc add dev wg0 parent 1:20 handle 20: fq_codel quantum 300 noecn
tc qdisc add dev wg0 parent 1:30 handle 30: fq_codel quantum 300 noecn

# --- associate queue with traffic

#tc filter add dev wg0 protocol ipv6 parent 1: prio 1 handle 6 fw flowid
1:10
# http/https
tc filter add dev wg0 protocol ipv6 parent 1: prio 10 u32 match ip dport 80
0x flowid 1:10
tc filter add dev wg0 protocol ipv6 parent 1: prio 10 u32 match ip dport
443 0x flowid 1:10
tc filter add dev wg0 protocol ipv6 parent 1: prio 10 u32 match ip dport
8080 0x flowid 1:10
# ncfs
tc filter add dev wg0 parent 1: protocol ipv6 prio 5 u32 match ip dport
16379 0x flowid 1:20
# icmp
tc filter add dev wg0 parent 1: protocol ip prio 1 u32 match  ip protocol 1
0xff flowid 1:30

tc -s qdisc ls dev wg0
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

[ wireguard-devel] Purge old peer

[Nicolas Prochazka]

Hello,
we hare using wireguard with a lot of client, with a lot of dynamically
generated peer key.
So we have, server side, a lot of peers that are become obsoletes
At this time, we delete peer , based on latest handshake > delta time ,
with wg command.
Is the best thing to do ? is it possible to implement an auto purge of old
peer ?

Regards,
Nicolas Prochazka.
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: [ wireguard-dev ] About configuring allowedip

[Nicolas Prochazka]

ok thanks,
what is confusing me it that allowed ip is for :
- authorized source packet
- routing outgoing packet
and we can set allowedips with a lot of ip / netmask
Regards,
Nicolas

2017-02-24 14:10 GMT+01:00 Dan Lüdtke <m...@danrl.com>:

> Nicolas,
>
> I draw your network including the allowed_ips restrictions.
>
> > ping peer3 --peer1--->peer2 : not ok .
>
> This can not work! Peer 2 does not accept the source address from Peer 3.
> Please review your allowed_ips settings. Draw the things on paper, make
> PostIt notes representing the packets including their destination address
> and source address. Draw a little "firewall" on the tunnels (whitelist is
> allowed_ips, all the rest gets dropped!) and see if the PostIt can make it
> through with it's source address. Yes, this sounds like child play, but it
> works. I have taught complex firewalling and VPN setups to lawyers and law
> makers this way. It helps understanding, if a simple diagram does not cut
> it.
>
> Allowed IPs is probably the most complex thing WireGuard has to offer from
> a user perspective. Rename it to Allowed Source Addrresses in your head it
> becomes clearer.
>
> HTH
>
> Dan
>
> > On 24 Feb 2017, at 11:41, Nicolas Prochazka <nicolas.procha...@gmail.com>
> wrote:
> >
> > hello again,
> > my configuration ,
> > ping peer 1-->peer 2  : ok   ( on ipv6 wg0 )
> > ping peer 3 --> peer 1 : ok
> > ping peer3 --peer1--->peer2 : not ok .
> >
> >
> > On peer 1 , forwarding is setting
> > net.ipv6.conf.all.forwarding = 1
> > net.ipv4.conf.all.forwarding = 1
> >
> >
> > Peer 1 : wg configuration
> >
> > interface: wg0
> >   public key: q5ypTBI7bN0vPGzvlGYyF6pCqYgrDsEjO827duAwjX4=
> >   private key: (hidden)
> >   listening port: 6081
> >
> > peer: dOXT9AvlEt9KSl3ricE12GuVa+U4XB0s1c92s8W+9VA=
> >   endpoint: 52.49.x.x:6081
> >   allowed ips: ::/0
> >   latest handshake: 8 seconds ago
> >   transfer: 71.29 KiB received, 60.28 KiB sent
> >   persistent keepalive: every 25 seconds
> >
> > peer: bqwiLTe/hr0JJMz3IvnDXqS5nOT6u/WL75dasmTE/ko=
> >   endpoint: 10.10.0.69:6081
> >   allowed ips: fd00::baae:edff:fe72:5094/128
> >   latest handshake: 45 seconds ago
> >   transfer: 5.49 KiB received, 6.36 KiB sent
> >
> >
> > Peer 3 :
> >
> >
> > interface: wg0
> >   public key: bqwiLTe/hr0JJMz3IvnDXqS5nOT6u/WL75dasmTE/ko=
> >   private key: (hidden)
> >   listening port: 6081
> >
> > peer: q5ypTBI7bN0vPGzvlGYyF6pCqYgrDsEjO827duAwjX4=
> >   endpoint: 10.10.99.230:6081
> >   allowed ips: ::/0
> >   latest handshake: 33 seconds ago
> >   transfer: 4.92 KiB received, 7.55 KiB sent
> >   persistent keepalive: every 25 seconds
> >
> >
> > Peer 2 :
> >
> > interface: wg0
> >   public key: dOXT9AvlEt9KSl3ricE12GuVa+U4XB0s1c92s8W+9VA=
> >   private key: (hidden)
> >   listening port: 6081
> >
> > peer: q5ypTBI7bN0vPGzvlGYyF6pCqYgrDsEjO827duAwjX4=
> >   endpoint: 77.156.x.x:58943
> >   allowed ips: fd00::eea8:6bff:fef9:23bc/128
> >   latest handshake: 1 minute, 43 seconds ago
> >   transfer: 52.59 KiB received, 79.01 KiB sent
> >
> >
> > 2017-02-23 14:41 GMT+01:00 Dan Lüdtke <m...@danrl.com>:
> > Nicolas: Could you provide the configuration files? Because from your
> little graphic or schema I can not even derive what you are configuring. I
> guess there is something overlapping prefixes maybe?
> >
> > Jason: I think we are approaching the point in time when there will be a
> -dev and a -users ML :)
> >
> >
> > > On 23 Feb 2017, at 14:03, Nicolas Prochazka <
> nicolas.procha...@gmail.com> wrote:
> > >
> > > Hello, i'm trying to do this with wireguard, withtout success :
> > >
> > > peer1 ---> peer2   : config ok , works
> > > peer3 ---> peer1  : config ok , works
> > > peer3 --->peer1 ---> peer2  : not ok .
> > >
> > > I suspect allowed-ip configuration, but all my tests does not works.
> > > perhaps I must create two wireguard interface on peer 1 and do
> forwarding/routing ?
> > > i'm using ipv6 as internal ip.
> > >
> > > so my question is :
> > > - two interface ?
> > > - specifiq magic allowedip ?
> > > ( allowed ip is confusing for, it is using for routing and for
> evicting paquet ? )
> > >
> > > Regards,
> > > Nicolas
> > > ___
> > > WireGuard mailing list
> > > WireGuard@lists.zx2c4.com
> > > https://lists.zx2c4.com/mailman/listinfo/wireguard
> >
> >
>
>
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: [ wireguard-dev ] dmesg when using ipv6

[Nicolas Prochazka]

you are right, sorry.
I do a lot of tests  and sometime it seems  wireguard is in  a "strange"
state, I'm trying to reproduce.

A question :
When I've the dmesg, "could not create ipv4 socket", i cannot rmmod
wireguard from kernel.
I'm trying
ip link del dev wg0  ,
rmmod wireguard
there's no wireguard interface, however, i cannot remove wireguard module,
system tells module is used.

When wireguard works well, i can remove module without problem.

Regards,
Nicolas






2017-02-23 18:32 GMT+01:00 Jason A. Donenfeld :

> Hello,
>
> For the second time today, please provide more debugging information
> than that. Full dmesg output, full configs, exactly what you're doing.
> Otherwise nobody can help you.
>
> Jason
>
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

[ wireguard-dev ] About configuring allowedip

[Nicolas Prochazka]

Hello, i'm trying to do this with wireguard, withtout success :

peer1 ---> peer2   : config ok , works
peer3 ---> peer1  : config ok , works
peer3 --->peer1 ---> peer2  : not ok .

I suspect allowed-ip configuration, but all my tests does not works.
perhaps I must create two wireguard interface on peer 1 and do
forwarding/routing ?
i'm using ipv6 as internal ip.

so my question is :
- two interface ?
- specifiq magic allowedip ?
( allowed ip is confusing for, it is using for routing and for evicting
paquet ? )

Regards,
Nicolas
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: [wireguard-devel] About ip management

[nicolas prochazka]

Thanks
These are good ideas to explore
Regards,
Nicolas

2017-02-20 13:48 GMT+01:00 Dan Lüdtke <m...@danrl.com>:

> Hi Nicolas,
>
>
> > On 17 Feb 2017, at 15:03, nicolas prochazka <prochazka.nico...@gmail.com>
> wrote:
> > I hope not to have misunderstood ip management with wireguard,
> > in a "server mode operation" , as many peers -> one peer ( server ) ,
> > private ip configuration must be coherent.
>
> There is no need for private (assuming you mean RFC1918) addresses, but of
> course it works with private IPs as well as with public IP addresses.
>
>
> > In fact, as server / client example in contrib, server must delivery ip
> to clients, there's no way for client to know good private_ip .
>
> Unless it is configured statically, which is what I suggest doing. There
> is plenty of IP space to use. Think of ULA or subprefixes of you GU(s). A
> single /64 should be sufficient to address all your clients uniquely per
> "server wg interface". The situation for legacy IP is also not that bad.
> RFC1918 space is huge, and there is also RFC6598 to pick from. Why don't
> just roll out IP configurations the same way you roll out WireGuard
> configuration? It's just a line more in the config when you use wg-quick.
>
>
> > We cannot use dhcp, layer 3 , so ...
>
> That's true for legacy IP. It does not hold true for state-of-the-art IP.
>
>
> > we need to implement a pool ip manager , is it correct ?
>
> I do not really know what you are referring to when you write "pool ip
> manager", but if you want to distribute IP configuration data inside the wg
> tunnel, you would need to configure static addresses to bootstrap that
> from. This might change in the future, as Jason said to be working in OOB
> features. IP management would then take place in user space mostly/entirely.
>
> Hope that helps!
>
> Cheers,
>
> Dan
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

[wireguard-devel] About ip management

[nicolas prochazka]

Hello,
I hope not to have misunderstood ip management with wireguard,
in a "server mode operation" , as many peers -> one peer ( server ) ,
private ip configuration must be coherent. In fact, as server / client
example in contrib, server must delivery ip to clients, there's no way for
client to know good private_ip .
We cannot use dhcp, layer 3 , so ...
we need to implement a pool ip manager , is it correct ?

Regards,
Nicolas Prochazka.
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Some questions about wireguard

[Nicolas Prochazka]

hello,
sorry for my english.
This question(udp tunnel ..)  is not relevant, I learn a lot with the read
of mailing list.
Regards,
Nicolas

2017-02-17 14:48 GMT+01:00 Jason A. Donenfeld <ja...@zx2c4.com>:

> On Wed, Feb 15, 2017 at 11:12 AM, Nicolas Prochazka
> <nicolas.procha...@gmail.com> wrote:
> > - how many tunnels a peer can manage ?
> > In our environnement, ~ 10 000 clients --> "server"|peer
>
> Each interface can have 65536 peers. Each linux system can have
> multiple interfaces.
>
> (If that peer limit becomes a problem for somebody, it wouldn't be
> difficult to remove it and expand it to 4294967296.)
>
> > how wireguard manage this ( udp tunnel from kernel ? )
>
> Not sure I understand your question. Could you rephrase?
>
> >
> > - about peer key management ?
> > with 10 000 peer keys, how can we manage it
>
> You can load the keys into the interface using wg(8). At some later
> date there may be support for dynamic database stuff.
>
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard