* RX Errors from Android Peer
@ 2018-04-25 20:14 Eddie
2018-04-25 21:18 ` Jason A. Donenfeld
0 siblings, 1 reply; 6+ messages in thread
From: Eddie @ 2018-04-25 20:14 UTC (permalink / raw)
To: wireguard
Only found out about this project a few days ago and have been trying it
out. Looks killer.
Noticed that connecting from the Android app (0.4.0), yeah I know it's
only Alpha level, the wg0 interface on the Linux side (0.0.20180420)
reports RX errors:
wg0: flags=209<UP,POINTOPOINT,RUNNING,NOARP> mtu 1420
inet 192.168.150.1 netmask 255.255.255.255 destination
192.168.150.2
inet6 fe80::a615:c1b7:2533:52d9 prefixlen 64 scopeid 0x20<link>
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
txqueuelen 1 (UNSPEC)
RX packets 7265 bytes 1049904 (1.0 MiB)
RX errors 168 dropped 10 overruns 0 frame 168
TX packets 8836 bytes 7561628 (7.2 MiB)
TX errors 3 dropped 0 overruns 0 carrier 0 collisions 0
Running a similar test from another Linux laptop didn't show the same
symptoms.
I can try and capture the packets on the internet facing interface it
that might help. If so, what information would you like reported back,
or I could just host/upload a raw capture file.
Cheers.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RX Errors from Android Peer
2018-04-25 20:14 RX Errors from Android Peer Eddie
@ 2018-04-25 21:18 ` Jason A. Donenfeld
2018-04-25 22:28 ` Eddie
0 siblings, 1 reply; 6+ messages in thread
From: Jason A. Donenfeld @ 2018-04-25 21:18 UTC (permalink / raw)
To: stunnel; +Cc: WireGuard mailing list
Hi Eddie,
Those RX frame errors are caused by the interface receiving packets
that have a source IP not included in the allowed-ips list of the
peer.
https://git.zx2c4.com/WireGuard/tree/src/receive.c#n351
Jason
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RX Errors from Android Peer
2018-04-25 21:18 ` Jason A. Donenfeld
@ 2018-04-25 22:28 ` Eddie
2018-04-26 8:59 ` René van Dorst
2018-04-26 13:04 ` Jason A. Donenfeld
0 siblings, 2 replies; 6+ messages in thread
From: Eddie @ 2018-04-25 22:28 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: WireGuard mailing list
Jason,
Not sure I follow you.
The Android app, I thought, was designed to send all traffic out via the
tunnel. It's configuration would be, in Linux format:
[Interface]
Address = 192.168.150.10/24
DNS = 192.168.0.254
PrivateKey = Android private key
[Peer]
PublicKey = Linux public key
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = MyServer.net:51820
So all the traffic sent, should be from 192.168.150.10. The
corresponding Linux configuration is:
[Interface]
PrivateKey = Linux private key
ListenPort = 51820
[Peer]
PublicKey = Android public key
AllowedIPs = 192.168.150.10/32
[Peer]
PublicKey = Laptop public key
AllowedIPs = 192.168.150.11/32
The RX errors go up immediately I connect and stop increasing when I
disconnect. They are NOT random pokes at my server from script-kiddies,
which i would have thought would have been dropped silently.
So, I don't see how the source IP wouldn't match the allowed-ip.
Cheers.
On 4/25/2018 2:18 PM, Jason A. Donenfeld wrote:
> Hi Eddie,
>
> Those RX frame errors are caused by the interface receiving packets
> that have a source IP not included in the allowed-ips list of the
> peer.
>
> https://git.zx2c4.com/WireGuard/tree/src/receive.c#n351
>
> Jason
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RX Errors from Android Peer
2018-04-25 22:28 ` Eddie
@ 2018-04-26 8:59 ` René van Dorst
2018-04-26 13:04 ` Jason A. Donenfeld
1 sibling, 0 replies; 6+ messages in thread
From: René van Dorst @ 2018-04-26 8:59 UTC (permalink / raw)
To: wireguard
Hi Eddie and Jason,
I seeing this too.
On the server: WireGuard 0.0.20180420-2-g802b85c (Mips32r2)
peer: bHFjNUyfx141TvuNXUyIQ2BDAF57zfcpgdRd09UOlSg=
endpoint: <ipv4>:22649
allowed ips: 10.0.0.8/32, fd00::8/128, <ipv6 prefix/48>:fff8::/64
latest handshake: 17 minutes, 41 seconds ago
transfer: 3.07 MiB received, 18.78 MiB sent
wg0 Link encap:UNSPEC HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.0.0.1 P-t-P:10.0.0.1 Mask:255.255.255.0
inet6 addr: fd00::1/64 Scope:Global
inet6 addr: <ipv6 prefix/48>:fff0::/60 Scope:Global
UP POINTOPOINT RUNNING NOARP MTU:1440 Metric:1
RX packets:23629 errors:215 dropped:0 overruns:0 frame:215
TX packets:23885 errors:6 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3224980 (3.0 MiB) TX bytes:19693516 (18.7 MiB)
Latest Android client 0.4.0 on a Backberry DTEK50 android 6.0.1. So
fallback on userspace implementation.
Address: 10.0.0.8/32, <ipv6 prefix/48>:fff8::1/64
dns: 8.8.8.8
Allowed IPS: ::/0, 0.0.0.0/0
MTU: auto.
Before test
wg0 Link encap:UNSPEC HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.0.0.1 P-t-P:10.0.0.1 Mask:255.255.255.0
inet6 addr: fd00::1/64 Scope:Global
inet6 addr: <ipv6 prefix/48>:fff0::/60 Scope:Global
UP POINTOPOINT RUNNING NOARP MTU:1440 Metric:1
RX packets:23714 errors:215 dropped:0 overruns:0 frame:215
TX packets:23996 errors:6 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3239760 (3.0 MiB) TX bytes:19715932 (18.8 MiB)
dmesg:
wireguard: wg0: Sending handshake initiation to peer 6 (85d26a64)
wireguard: wg0: Receiving handshake initiation from peer 6 (85d26a64)
wireguard: wg0: Sending handshake response to peer 6 (85d26a64)
wireguard: wg0: Keypair 93 created for peer 6
wireguard: wg0: Keypair 91 destroyed for peer 6
wireguard: wg0: Receiving keepalive packet from peer 6 (85d26a64)
wireguard: wg0: Packet has unallowed src IP (8cd8bd50) from peer 6 (85d26a64)
wireguard: wg0: Receiving keepalive packet from peer 6 (85d26a64)
wireguard: wg0: Receiving keepalive packet from peer 6 (85d26a64)
wireguard: wg0: Receiving keepalive packet from peer 6 (85d26a64)
wireguard: wg0: Receiving handshake initiation from peer 6 (85d26a64)
wireguard: wg0: Sending handshake response to peer 6 (85d26a64)
wireguard: wg0: Keypair 94 created for peer 6
wireguard: wg0: Keypair 92 destroyed for peer 6
wireguard: wg0: Receiving keepalive packet from peer 6 (85d26a64)
wireguard: wg0: Retrying handshake with peer 6 (85d26a64) because we
stopped hearing back after 15 seconds
wireguard: wg0: Sending handshake initiation to peer 6 (85d26a64)
wireguard: wg0: Receiving handshake response from peer 6 (85d26a64)
After test:
wg0 Link encap:UNSPEC HWaddr
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.0.0.1 P-t-P:10.0.0.1 Mask:255.255.255.0
inet6 addr: fd00::1/64 Scope:Global
inet6 addr: <ipv6 prefix/48>:fff0::/60 Scope:Global
UP POINTOPOINT RUNNING NOARP MTU:1440 Metric:1
RX packets:26810 errors:216 dropped:0 overruns:0 frame:216
TX packets:26866 errors:6 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3674552 (3.5 MiB) TX bytes:21719820 (20.7 MiB)
Tunnel is working: test-ipv6.nl shows both my ISP ipv4 and ipv6 address.
Greats,
René van Dorst.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: RX Errors from Android Peer
2018-04-25 22:28 ` Eddie
2018-04-26 8:59 ` René van Dorst
@ 2018-04-26 13:04 ` Jason A. Donenfeld
2018-04-26 16:09 ` Eddie
1 sibling, 1 reply; 6+ messages in thread
From: Jason A. Donenfeld @ 2018-04-26 13:04 UTC (permalink / raw)
To: stunnel; +Cc: WireGuard mailing list
Hello Eddie,
Precisely what's happening here is that your device has various TCP
connections that are open _before_ you turn on the VPN. Then you turn
on the VPN, and now those prior TCP sessions try to continue over the
VPN, using the old source IP address. It takes a few seconds for
everything to time out, and for those TCP connections to be
reestablished with the right new tunnel source IP. In the meantime,
the WireGuard server gets packets using the old source IP, which of
course isn't correlated with that peer's allowed IPs, and so it
complains and rejects those packets. If it allowed them, that'd be a
security problem.
So, nothing to worry about.
Jason
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RX Errors from Android Peer
2018-04-26 13:04 ` Jason A. Donenfeld
@ 2018-04-26 16:09 ` Eddie
0 siblings, 0 replies; 6+ messages in thread
From: Eddie @ 2018-04-26 16:09 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: WireGuard mailing list
Jason,
Gottcha. Thank you for the explanation.
Cheers.
On 4/26/2018 6:04 AM, Jason A. Donenfeld wrote:
> Hello Eddie,
>
> Precisely what's happening here is that your device has various TCP
> connections that are open _before_ you turn on the VPN. Then you turn
> on the VPN, and now those prior TCP sessions try to continue over the
> VPN, using the old source IP address. It takes a few seconds for
> everything to time out, and for those TCP connections to be
> reestablished with the right new tunnel source IP. In the meantime,
> the WireGuard server gets packets using the old source IP, which of
> course isn't correlated with that peer's allowed IPs, and so it
> complains and rejects those packets. If it allowed them, that'd be a
> security problem.
>
> So, nothing to worry about.
>
> Jason
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-04-26 16:08 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-04-25 20:14 RX Errors from Android Peer Eddie
2018-04-25 21:18 ` Jason A. Donenfeld
2018-04-25 22:28 ` Eddie
2018-04-26 8:59 ` René van Dorst
2018-04-26 13:04 ` Jason A. Donenfeld
2018-04-26 16:09 ` Eddie
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).