Development discussion of WireGuard
 help / color / mirror / Atom feed
From: "Ivan Labáth" <labawi-wg@matrix-dream.net>
To: Aryn Starr <whereislelouch@icloud.com>
Cc: wireguard@lists.zx2c4.com
Subject: Re: [Feature Request] Add ability to exclude subnets from AllowedIPs
Date: Mon, 26 Aug 2019 17:48:47 +0000	[thread overview]
Message-ID: <20190826174847.GA5022@matrix-dream.net> (raw)
In-Reply-To: <404FD4CE-ACC0-41F0-A36D-CB3DC339B3F5@icloud.com>

Hello,

please note two separate steps with regards to wireguard routing.

1) kernel routing table (and iptables, policy routing, xfrm etc)
2) wg peer IPs (routing table)

The first step (1) chooses which interface to use for a given packet.
If the chosen interface is a wireguard device, then step (2) is done
to choose the proper peer to send the packet to. The same is done in
reverse when accepting packets to prevent spoofing: in (2) - always,
in (1) - depending on configuration.

If you want to send packets outside the tunnel, you need to properly
setup (1). Setting (2) wg peer ips is mostly irrelevant (aside from
peers being permitted to originate packets from given ips, which, in some
setups would not be automatically dropped).

If you want to send packets to specific ips via a different peer
(e.g. one that can route Iranian ips), then you should assign those
ips to the different peer (2).


Basic routing, both in wireguard and kernel roting tables of most
operating systems, routes according to the most specific matching
route. Meaning, if you add a route to another peer/device, it is
automatically excluded from the less specific default one, and
under normal* circumstances, there is no need to explicitly exclude
them.

* if you are concerned about accidentally sending packets to undesired
peers, you should think about what happens before the device is up or
if it goes down (removing routes) or if the peer is removed (again,
removing routes) or similar circumstances.
For kernel routing, firewall is your friend. For wireguard .. I guess
explicitly excluding ips would be prudent.

Regards,
Ivan


On Mon, Aug 26, 2019 at 12:56:45AM +0430, Aryn Starr wrote:
> I haven’t tested that allowedIPs approach actually. I’ll take a look at that python wrapper, thanks. 
> I don’t know much about iptables and routing. I think learning it sufficiently will take quite some time? Or are there some tutorials around?
> I also actually use WireGuard with macOS (though I occasionally use it on Linux, too).
> 
> > On Aug 25, 2019, at 11:47 PM, Derrick Lyndon Pallas <derrick@pallas.us> wrote:
> > 
> > Why wouldn't this happen as an iptables rule?
> > 
> > If some AllowedIPs trick is working for you and you're using Python and the kernel version of Wireguard, check out [1], which will allow you to programmatically set up the interface.
> > 
> > FWIW, I'm not sure adding complication to AllowedIPs is the right approach, but adding it to a tool seems reasonable. Maybe it also makes sense to allow an IPset, but I'm haven't thought it through. My gut says routing prior to Wireguard is probably what you're looking for.
> > 
> > [1] https://github.com/ArgosyLabs/wgnlpy
> > 
> > ~Derrick • iPhone
> > 
> >> On Aug 22, 2019, at 12:10 PM, Aryn Starr <whereislelouch@icloud.com> wrote:
> >> 
> >> I live in Iran, and here the internet censorship is fierce. I need to route almost all of my traffic through the VPN, but some domestic sites are not accessible from the US. Also, since ISPs apply different censoring rules, sometimes my own servers are not reachable via the VPN (because the server’s ISP blocks the VPN, while my local ISP does not.)
> >> The best current solution I’ve seen is
> >> ```
> >> $ python3
> >> 
> >>>>> import ipaddress
> >>>>> n1 = ipaddress.ip_network('106.203.202.0/23')
> >>>>> n2 = ipaddress.ip_network('106.203.203.13/32')
> >>>>> l = list(n1.address_exclude(n2))
> >>>>> print(l)
> >> 
> >> ```
> >> Which is terrible.
> >> _______________________________________________
> >> 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 mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

      reply	other threads:[~2019-08-26 17:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-22 19:10 Aryn Starr
2019-08-25 19:17 ` Derrick Lyndon Pallas
2019-08-25 20:26   ` Aryn Starr
2019-08-26 17:48     ` Ivan Labáth [this message]

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=20190826174847.GA5022@matrix-dream.net \
    --to=labawi-wg@matrix-dream.net \
    --cc=whereislelouch@icloud.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).