From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI,SPF_PASS, WEIRD_PORT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E2046C43381 for ; Thu, 7 Mar 2019 17:54:39 +0000 (UTC) Received: from krantz.zx2c4.com (krantz.zx2c4.com [192.95.5.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3CDF920661 for ; Thu, 7 Mar 2019 17:54:38 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="B/zFlrHo" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3CDF920661 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=wireguard-bounces@lists.zx2c4.com Received: from krantz.zx2c4.com (localhost [IPv6:::1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 5f7c8893; Thu, 7 Mar 2019 17:43:45 +0000 (UTC) Received: from krantz.zx2c4.com (localhost [127.0.0.1]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 5c624401 for ; Thu, 7 Mar 2019 17:43:41 +0000 (UTC) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) by krantz.zx2c4.com (ZX2C4 Mail Server) with ESMTP id ff90ab38 for ; Thu, 7 Mar 2019 17:43:41 +0000 (UTC) Received: by mail-qt1-x830.google.com with SMTP id d2so18089753qti.11 for ; Thu, 07 Mar 2019 09:54:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iVkYXIJAAHaUVNWPAqQbD+Xg6RsUSw1Mhoo6HUmBg9Y=; b=B/zFlrHoESXmfzpgssa6n4XPj7ecvCO8FT0Qy0H6PYrYrIZprCGrKgTbo/c1/pJujN vtnRopth+BFtQs2WjX1zpFRhmy+qN8kprcdNAyaE9xcnm9AwLvgv0Sb+/TvCEXvs11+K 1CbvizJF8WX5nuLy1T7vYVMV4bXQn7bNwr4LJgf5s9Mg2MKkvxZ5vFPdt68aY95wk7Zi 7+17T2fm+zp+R4sfwJim3H2qOsvCaq+/zifUn3dT6YqvsZ1+rk6hI+nOWrjkm5CaUybk n5sBt/iZ9hOkrd5Sps4KxUtlHJKY0v2lQeI4v6w4nU42wp5BGlw9LagOzbgs5PChHqFc Kkog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iVkYXIJAAHaUVNWPAqQbD+Xg6RsUSw1Mhoo6HUmBg9Y=; b=C+KsLJZISzU/+t5hNYoXH1ZZmsPzqoHFGyJlYrU/jVbBx2nn8lBP15A+42xPKqlLY8 TIRhH3lfKLzhgYXmh7mPf+2F6A+1dwyjtTdsMLRSuTpk2lTwf8blim+j6isTT4Ytgspa 3ZjRCg1QUjK5Ivjcm1FGxA0C14n+zFgxvzezS301ieMEBJz9qwetN6KhxS1WMEVOcYGS xBNbP+zEGQx1jgTrGEuZG5TWEC8X5l0RhIs3s2F9YJCnl74wX6TFrXDfb0IcVym2XyDc 9+Mb4qjdd19Zehye7nJvBbg1g4zwpDLyHSi2g1hgCcL1DKYvwdUQsCerzkmSY8B+xPMG jM1g== X-Gm-Message-State: APjAAAVx6ruf8MsVYy7jL6qA2uAFmb4bTKZoLMD4/uxt8/sY4vuNmFBx x7s1w+bXxAeHvewsudFxWrvXC7ucJwGPkwDT1U0= X-Google-Smtp-Source: APXvYqzCVxfw+tvhNAV4PCYa0ZUPQDA3CIEhRYW9JDDcj5jGHDkS7bilD8QTcZeomwM1BMoVmE9Y0v1cnr8rhF5uLWk= X-Received: by 2002:a0c:927a:: with SMTP id 55mr11643785qvz.226.1551981257729; Thu, 07 Mar 2019 09:54:17 -0800 (PST) MIME-Version: 1.0 References: <3053f293b7e9a34a733c2b5b314e2d8a620682db.camel@airmail.cc> In-Reply-To: From: Arpit Gupta Date: Thu, 7 Mar 2019 09:54:06 -0800 Message-ID: Subject: Re: cant connect to wireguard when router connected to a vpn service To: David Kerr Cc: wireguard@lists.zx2c4.com X-BeenThere: wireguard@lists.zx2c4.com X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8461074214094625084==" Errors-To: wireguard-bounces@lists.zx2c4.com Sender: "WireGuard" --===============8461074214094625084== Content-Type: multipart/alternative; boundary="00000000000090acf7058384cbb5" --00000000000090acf7058384cbb5 Content-Type: text/plain; charset="UTF-8" I am noob in networking commands so looking for any pointers :). I think the issue is packets are getting directed some where else because of a default route. Here is info on my setup. Wireguard running on host: 192.168.1.63 Router: 192.168.1.1 is also running a VPN Client and is connected to mullvad vpn service. This sets up a tunnel on my router. I have a policy rule setup on my router that sends all traffic from 192.168.1.0/24 through the vpn tunnel. I setup port forwarding according to mullvad guides on my router. I have confirmed port forwarding in mullvad is working as i am forwarding ports to other services without any issues. iptables -t nat -A PREROUTING -i tun+ -p tcp --dport xxxx -j DNAT --to-destination 192.168.1.63:54930 iptables -t nat -A PREROUTING -i tun+ -p udp --dport xxxx -j DNAT --to-destination 192.168.1.63:54930 However even with these rules i am not able to connect to wireguard when using my vpn ip. Now if i add a route to my vpn client that states all traffic from 192.168.1.63 goes through the wan then i can connect to wireguard but using my isp's ip address. With this setup i only have access to lan. My ideal setup so that i dont need to switch to different wireguard tunnel when i leave my home network is that i be able access my lan as well as route all traffic via mullvad. So i think the issue i need to solve is how come i am not able to reach wireguard even with port forwarding setup in mullvad when using my vpn ip. -- Arpit On Thu, Mar 7, 2019 at 12:04 AM David Kerr wrote: > I'm a little confused as to the network architecture. Are your running a > wireguard VPN inside of your OpenVPN? Or do you have two VPN's connecting > into your host independently? Either way, the first thing I would look at > is your ip route tables. You need to make sure that packets that arrive on > one interface (e.g. wg0) are replied to over that same interface and are > not directed out somewhere else by virtue of the default route pointing > elsewhere. > > David > > On Wed, Mar 6, 2019 at 1:23 PM Arpit Gupta wrote: > >> Actually false alarm :(. >> >> Can only get it to work if i add a policy rule in my router vpn client to >> send all traffic from host running wireguard through the WAN and thus >> skipping VPN which is not ideal as when i am routing all traffic through >> wireguard ideally i want it to use the vpn tunnel on my router. >> >> >> -- >> Arpit >> >> >> On Wed, Mar 6, 2019 at 8:20 AM Arpit Gupta wrote: >> >>> Got it working :). >>> >>> Did not need to change any client or server settings. However needed to >>> add another policy rule in my vpn client. Rule states >>> >>> Source: wireguard server >>> destination: 192.168.100.0/24 (so any of my wireguard clients) >>> interface: WAN >>> >>> So this way wireguard traffic does not go through the VPN. >>> -- >>> Arpit >>> >>> >>> On Wed, Mar 6, 2019 at 7:59 AM Arpit Gupta wrote: >>> >>>> Tried changing the allowed ip's to what was suggested and it did not >>>> work. Same behavior as before. Also my configs were working as expected >>>> before i had my router connected to a vpn service. >>>> >>>> It required me to add the following route policy for my vpn client on >>>> my router >>>> >>>> Source IP: 192.168.1.0/24, Destination: 0.0.0.0 will go throuh the >>>> VPN. So if it matters if i connected to wireguard using the ip address of >>>> the ISP vs the IP address of the VPN? >>>> >>>> >>>> -- >>>> Arpit >>>> >>>> >>>> On Wed, Mar 6, 2019 at 1:18 AM XRP wrote: >>>> >>>>> On Wed, 2019-03-06 at 08:40 +0000, Arpit Gupta wrote: >>>>> > On my server my conf is >>>>> > >>>>> > [Interface] >>>>> > Address = 192.168.100.1/32 >>>>> > PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o >>>>> > %i -j >>>>> > ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE >>>>> > PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD >>>>> > -o %i >>>>> > -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE >>>>> > ListenPort = 54930 >>>>> > PrivateKey = xxxxx >>>>> > >>>>> > [Peer] >>>>> > PublicKey = xxxx >>>>> > AllowedIPs = 192.168.100.2/32 >>>>> > >>>>> > >>>>> > on my client my config is >>>>> > >>>>> > [Interface] >>>>> > Address = 192.168.100.2 >>>>> > PrivateKey = xxxxx >>>>> > ListenPort = 21841 >>>>> > DNS = 192.168.1.63 >>>>> > >>>>> > [Peer] >>>>> > PublicKey = xxxx >>>>> > Endpoint = ddns:xxx >>>>> > AllowedIPs = 192.168.1.0/24 >>>>> > >>>>> > # This is for if you're behind a NAT and >>>>> > # want the connection to be kept alive. >>>>> > PersistentKeepalive = 25 >>>>> >>>>> Try changing AllowedIPs in the client config to: >>>>> AllowedIPs = 192.168.100.1/32,192.168.1.0/24 >>>>> >>>>> Also, if you want to masquerade the traffic to the internet you need to >>>>> add 0.0.0.0./0 to the client or change the destination IP to the server >>>>> node via a NAT rule, otherwise it's going to be rejected because the IP >>>>> packet doesn't have an AllowedIP address, I think. (The source needs to >>>>> match, so either 192.168.100.1/32 or 192.168.1.0/24). My guess is >>>>> that's why you couldn't complete the handshake. >>>>> >>>>> _______________________________________________ >> WireGuard mailing list >> WireGuard@lists.zx2c4.com >> https://lists.zx2c4.com/mailman/listinfo/wireguard >> > --00000000000090acf7058384cbb5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am noob in networking = commands so looking for any pointers :). I think the issue is packets are g= etting directed some where else because of a default route.=C2=A0

<= /div>
Here is info on my setup.

Wireguard runn= ing on host: 192.168.1.63

Router: 192.168.1.1 is a= lso running a VPN Client and is connected to mullvad vpn service. This sets= up a tunnel on my router. I have a policy rule setup on my router that sen= ds all traffic from 192.168.1.0/24 th= rough the vpn tunnel.

I setup port forwarding acco= rding to mullvad guides on my router. I have confirmed port forwarding in m= ullvad is working as i am forwarding ports to other services without any is= sues.

iptables -t nat -A PREROUTING -i tun+ -p tcp= --dport xxxx -j DNAT --to-destination 192.168.1.63:54930
iptables -t nat -A PREROUTING -i tun+ -p= udp --dport xxxx -j DNAT --to-destination 192.168.1.63:54930=C2=A0

However eve= n with these rules i am not able to connect to wireguard when using my vpn = ip.


Now if i add a route to my vpn = client that states all traffic from 192.168.1.63 goes through the wan then = i can connect to wireguard but using my isp's ip address. With this set= up i only have access to lan. My ideal setup so that i dont need to switch = to different wireguard tunnel when i leave my home network is that i be abl= e access my lan as well as route all traffic via mullvad.


So i think the issue i need to solve is how come i a= m not able to reach wireguard even with port forwarding setup in mullvad wh= en using my vpn ip.

--
Arpit
<= br>

On Thu, Mar 7, 2019 at 12:04 AM David Kerr <david@kerr.net> wrote:
I'm a little confu= sed as to the network architecture.=C2=A0 Are your running a wireguard VPN = inside of your OpenVPN?=C2=A0 Or do you have two VPN's connecting into = your host independently?=C2=A0 Either way, the first thing I would look at = is your ip route tables.=C2=A0 You need to make sure that packets that arri= ve on one interface (e.g. wg0) are replied to over that same interface and = are not directed out somewhere else by virtue of the default route pointing= elsewhere.

David

On Wed, Mar 6, 2019 at 1:23 PM Arpit Gupta &l= t;g.arpit@gmail.com<= /a>> wrote:
<= div dir=3D"ltr">Actually false alarm :(.

Can only get it= to work if i add a policy rule in my router vpn client to send all traffic= from host running wireguard through the WAN and thus skipping VPN which is= not ideal as when i am routing all traffic through wireguard ideally i wan= t it to use the vpn tunnel on my router.


--
Arpit


On Wed, Mar 6, 2019 at 8:20 AM Arpit Gupta <g.arpit@gmail.com&g= t; wrote:
Got it working :).

Did not need to change any= client or server settings. However needed to add another policy rule in my= vpn client. Rule states

Source: wireguard server<= /div>
destination: 192.168.100.0/24 (so any of my wireguard clients)
interface= : WAN

So this way wireguard traffic does not go th= rough the VPN.=C2=A0
--
Arpit

=

On Wed, Mar 6, 2019 at 7:59 AM Arpit Gupta <g.arpit@gmail.com> wrote:
=
Tried ch= anging the allowed ip's to what was suggested and it did not work. Same= behavior as before. Also my configs were working as expected before i had = my router connected to a vpn service.

It required me to = add the following route policy for my vpn client on my router
Source IP: = 192.168.1.0/24, Destination: 0.0.0.0 will go throuh the VPN. So if it m= atters if i connected to wireguard using the ip address of the ISP vs the I= P address of the VPN?


--
Arpit


On Wed, Mar 6, = 2019 at 1:18 AM XRP <xrp@airmail.cc> wrote:
On Wed, 2019-03-06 at 08:40 +0000, Arpit = Gupta wrote:
> On my server my conf is
>
> [Interface]
> Address =3D 192.168.100.1/32
> PostUp =3D iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o=
> %i -j
> ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
> PostDown =3D iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD<= br> > -o %i
> -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
> ListenPort =3D 54930
> PrivateKey =3D xxxxx
>
> [Peer]
> PublicKey =3D xxxx
> AllowedIPs =3D 192.168.100.2/32
>
>
> on my client my config is
>
> [Interface]
> Address =3D 192.168.100.2
> PrivateKey =3D xxxxx
> ListenPort =3D 21841
> DNS =3D 192.168.1.63
>
> [Peer]
> PublicKey =3D xxxx
> Endpoint =3D ddns:xxx
> AllowedIPs =3D 192.168.1.0/24
>
> # This is for if you're behind a NAT and
> # want the connection to be kept alive.
> PersistentKeepalive =3D 25

Try changing AllowedIPs in the client config to:
AllowedIPs =3D 192.168.100.1/32,192.168.1.0/24

Also, if you want to masquerade the traffic to the internet you need to
add 0.0.0.0./0 to the client or change the destination IP to the server
node via a NAT rule, otherwise it's going to be rejected because the IP=
packet doesn't have an AllowedIP address, I think. (The source needs to=
match, so either 192.168.100.1/32 or 192.168.1.0/24). My guess is
that's why you couldn't complete the handshake.

_______________________________________________
WireGuard mailing list
WireGuard@li= sts.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard=
--00000000000090acf7058384cbb5-- --===============8461074214094625084== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard --===============8461074214094625084==--