WireGuard Archive on lore.kernel.org
 help / Atom feed
* Traffic on port 53 fails on LTE but works on WiFi
@ 2018-11-18 18:55 John
  2018-11-19  4:26 ` Quan Zhou
                   ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: John @ 2018-11-18 18:55 UTC (permalink / raw)
  To: wireguard

I have a simple WireGuard VPN setup I use running WG on a home Linux
box and connecting to it with several iOS clients.  The server peer is
setup on port 53 since a the networkadmins of some remote WiFi
networks my mobile devices seems to block udp traffic on higher ports.
Encrypted connections work fine on WiFi as I have setup, but do _not_
work when I connect via LTE (Verizon supplying the data).  On LTE, I
am no longer able to transfer data to/from the server peer but I can
handshake with it.

If I inspect the output of `sudo wg` on the server peer, I see the
endpoint IP address changes to reflect my Verizon LTE IP and the time
since the last handshake reset to a few seconds which is consistent
with my ability to connect to the WireGuard peer server.

I am unable to transfer data (pull up a web site or check email etc).
It's as/if Verizon is blocking my data flow on port 53.  If I change
the port from 53 to 123, it seems to work fine although I do not have
universal connectivity on the various WiFi networks I visit on port
123.  The optimal port would be 53 for my use case.

So the questions:
1) What can I try on the server peer side to diagnose?
2) Do people feel that Verizon is actively blocking the connection on port 53?
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Traffic on port 53 fails on LTE but works on WiFi
  2018-11-18 18:55 Traffic on port 53 fails on LTE but works on WiFi John
@ 2018-11-19  4:26 ` Quan Zhou
  2018-11-19  7:32 ` M. Dietrich
  2018-11-19  9:57 ` Problem to load wireguard LKM in Archlinux Tosh
  2 siblings, 0 replies; 10+ messages in thread
From: Quan Zhou @ 2018-11-19  4:26 UTC (permalink / raw)
  To: John; +Cc: wireguard

> 1) What can I try on the server peer side to diagnose?

# tcpdump udp port 53

maybe you can try to `ping` and `traceroute` to your server in addition.

On 11/19/18, John <graysky@archlinux.us> wrote:
> I have a simple WireGuard VPN setup I use running WG on a home Linux
> box and connecting to it with several iOS clients.  The server peer is
> setup on port 53 since a the networkadmins of some remote WiFi
> networks my mobile devices seems to block udp traffic on higher ports.
> Encrypted connections work fine on WiFi as I have setup, but do _not_
> work when I connect via LTE (Verizon supplying the data).  On LTE, I
> am no longer able to transfer data to/from the server peer but I can
> handshake with it.
>
> If I inspect the output of `sudo wg` on the server peer, I see the
> endpoint IP address changes to reflect my Verizon LTE IP and the time
> since the last handshake reset to a few seconds which is consistent
> with my ability to connect to the WireGuard peer server.
>
> I am unable to transfer data (pull up a web site or check email etc).
> It's as/if Verizon is blocking my data flow on port 53.  If I change
> the port from 53 to 123, it seems to work fine although I do not have
> universal connectivity on the various WiFi networks I visit on port
> 123.  The optimal port would be 53 for my use case.
>
> So the questions:
> 1) What can I try on the server peer side to diagnose?
> 2) Do people feel that Verizon is actively blocking the connection on port
> 53?
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>


-- 
Regards,

Quan Zhou

F2999657195657205828D56F35F9E5CDBD86324B
quanzhou822@gmail.com
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Traffic on port 53 fails on LTE but works on WiFi
  2018-11-18 18:55 Traffic on port 53 fails on LTE but works on WiFi John
  2018-11-19  4:26 ` Quan Zhou
@ 2018-11-19  7:32 ` M. Dietrich
  2018-11-19  8:40   ` John
  2018-11-19  8:54   ` Matthias Urlichs
  2018-11-19  9:57 ` Problem to load wireguard LKM in Archlinux Tosh
  2 siblings, 2 replies; 10+ messages in thread
From: M. Dietrich @ 2018-11-19  7:32 UTC (permalink / raw)
  To: John, wireguard

[-- Attachment #1.1: Type: text/plain, Size: 770 bytes --]

Hi John,

Quotation from John at November 18, 2018 19:55:
> ... on port 53 ... do _not_ work when I connect via LTE
> (Verizon supplying the data).  On LTE, I am no longer able
> to transfer data to/from the server peer but I can handshake
> with it.

Vodafone blocks UDP traffic on port 53 in LTE.

> 1) What can I try on the server peer side to diagnose?

I would check with tcpdump. it seems Verizon does some package
inspection, maybe reducing MTU will do?

> 2) Do people feel that Verizon is actively blocking the
> connection on port 53?

Not with Verizon but Vodafone which does a complete block -
not even the handshake goes through. Not sure about the cause
for that, maybe they want to control your DNS that way.

Regards,
M. Dietrich

[-- Attachment #1.2: Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Traffic on port 53 fails on LTE but works on WiFi
  2018-11-19  7:32 ` M. Dietrich
@ 2018-11-19  8:40   ` John
  2018-11-19  8:54   ` Matthias Urlichs
  1 sibling, 0 replies; 10+ messages in thread
From: John @ 2018-11-19  8:40 UTC (permalink / raw)
  To: mdt; +Cc: wireguard

Thank you both for the replies.  I first tried reducing the MTU
(/etc/wireguard/wg0.conf setting MTU = xxxx) where I tried values of
1360, 1300, 1200, and 1100 but all met with the same result.

I next tried the suggestion to run `tcpdump udp port 53` when I have a
problematic client connect on LTE and when I have a successful
connection on LTE (different providers).  I need to read up more of
this output before I post publicly as I might be disclosing personal
privacy info.  I will say that each of them contain some lines like:

... Type63103 (Class 50031)? <BAD PTR>[|domain]
... Type4168 (Class 47859)? <BAD PTR>[|domain]

The difference is that the problematic client seems to only contain
lines with either 256 or 512 sizes (I assume sizes).
time stamp IP blah.myvzw.com.9725 > wireguard.domain: 256 [xxxxa]
[xxxxq] [xxxn] [xxxxau][|domain]
time stamp IP wireguard.37024 > dns.quad9.net.domain: xxx+ PTR?
xxx.x.xxx.xxx.xx-addr.arpa. (44)
time stamp IP blah.myvzw.com.9725 > wireguard.domain: 512 [xxxxa]
[xxxxq] [xxxn] [xxxxau][|domain]

But the successful client connection has these plus a number of lines
where the 256 or 512 is 1024.  Again, I need to read about not
disclosing personal info before I post the entire dump file.

Is the little info I did post diagnostic?
On Mon, Nov 19, 2018 at 2:32 AM M. Dietrich <mdt@emdete.de> wrote:
>
> Hi John,
>
> Quotation from John at November 18, 2018 19:55:
> > ... on port 53 ... do _not_ work when I connect via LTE
> > (Verizon supplying the data).  On LTE, I am no longer able
> > to transfer data to/from the server peer but I can handshake
> > with it.
>
> Vodafone blocks UDP traffic on port 53 in LTE.
>
> > 1) What can I try on the server peer side to diagnose?
>
> I would check with tcpdump. it seems Verizon does some package
> inspection, maybe reducing MTU will do?
>
> > 2) Do people feel that Verizon is actively blocking the
> > connection on port 53?
>
> Not with Verizon but Vodafone which does a complete block -
> not even the handshake goes through. Not sure about the cause
> for that, maybe they want to control your DNS that way.
>
> Regards,
> M. Dietrich
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Traffic on port 53 fails on LTE but works on WiFi
  2018-11-19  7:32 ` M. Dietrich
  2018-11-19  8:40   ` John
@ 2018-11-19  8:54   ` Matthias Urlichs
  2018-11-19 16:02     ` Roman Mamedov
  1 sibling, 1 reply; 10+ messages in thread
From: Matthias Urlichs @ 2018-11-19  8:54 UTC (permalink / raw)
  To: wireguard

On 19.11.18 08:32, M. Dietrich wrote:
> Vodafone blocks UDP traffic on port 53 in LTE.
They don't block it – they redirect it to their DNS proxy.
> not even the handshake goes through. Not sure about the cause
> for that, maybe they want to control your DNS that way.

Redirecting port 53 to their DNS (presumably one close to their LTE
endpoint) is reasonable, that should improve speed.

The reason these providers block UDP altogether is simple – P2P file
sharing and similar shenanigans.

Is that complete block in the terms+conditions? If not, annoy their support.

-- 
-- Matthias Urlichs

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Problem to load wireguard LKM in Archlinux
  2018-11-18 18:55 Traffic on port 53 fails on LTE but works on WiFi John
  2018-11-19  4:26 ` Quan Zhou
  2018-11-19  7:32 ` M. Dietrich
@ 2018-11-19  9:57 ` Tosh
  2018-11-19 15:04   ` John
  2 siblings, 1 reply; 10+ messages in thread
From: Tosh @ 2018-11-19  9:57 UTC (permalink / raw)
  To: wireguard

[-- Attachment #1.1.1: Type: text/plain, Size: 1668 bytes --]

Hello,

I'm using Wireguard on ArchLinux since a long time, and today I have
some troubles to start my VPN. Here is the log of dmeg when I try to
'modprobe wireguard' :

wireguard: Unknown symbol poly1305_blocks_avx (err
-2)                                                               
wireguard: Unknown symbol poly1305_emit_avx (err
-2)                                                                 
wireguard: Unknown symbol poly1305_blocks_avx512 (err
-2)                                                            
wireguard: Unknown symbol chacha20_avx512vl (err
-2)                                                                 
wireguard: Unknown symbol chacha20_avx2 (err -2)
wireguard: Unknown symbol poly1305_blocks_avx2 (err
-2)                                                              
wireguard: Unknown symbol chacha20_avx512 (err -2)

I did a MAJ of my system yesterday, but wireguard wasn't upgraded, so I
don't know where the problem come from...Seems a LKM related to crypto
is missing, but I don't know which one is.

My kernel is 4.19.2-arch1-1-ARCH, and my wireguard packages are :

- community/wireguard-dkms 0.0.20181115-1

- community/wireguard-tools 0.0.20181115-1

Thanks for your work,

-- 
-TOSH-

If you need privacy you can encrypt your mails with my GPG key:
9B79 7754 00E2 23C7 FC90  E5C6 E5D9 1B2F 0BD5 3C6A


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Problem to load wireguard LKM in Archlinux
  2018-11-19  9:57 ` Problem to load wireguard LKM in Archlinux Tosh
@ 2018-11-19 15:04   ` John
  0 siblings, 0 replies; 10+ messages in thread
From: John @ 2018-11-19 15:04 UTC (permalink / raw)
  To: Tosh; +Cc: wireguard

[-- Attachment #1.1: Type: text/plain, Size: 1316 bytes --]

Are you certain that the dkms rebuild was triggered?  Seems like like it
was not.  Perhaps manually trigger it and reboot.

On Monday, November 19, 2018, Tosh <tosh@t0x0sh.org> wrote:

> Hello,
>
> I'm using Wireguard on ArchLinux since a long time, and today I have
> some troubles to start my VPN. Here is the log of dmeg when I try to
> 'modprobe wireguard' :
>
> wireguard: Unknown symbol poly1305_blocks_avx (err
> -2)
> wireguard: Unknown symbol poly1305_emit_avx (err
> -2)
> wireguard: Unknown symbol poly1305_blocks_avx512 (err
> -2)
> wireguard: Unknown symbol chacha20_avx512vl (err
> -2)
> wireguard: Unknown symbol chacha20_avx2 (err -2)
> wireguard: Unknown symbol poly1305_blocks_avx2 (err
> -2)
> wireguard: Unknown symbol chacha20_avx512 (err -2)
>
> I did a MAJ of my system yesterday, but wireguard wasn't upgraded, so I
> don't know where the problem come from...Seems a LKM related to crypto
> is missing, but I don't know which one is.
>
> My kernel is 4.19.2-arch1-1-ARCH, and my wireguard packages are :
>
> - community/wireguard-dkms 0.0.20181115-1
>
> - community/wireguard-tools 0.0.20181115-1
>
> Thanks for your work,
>
> --
> -TOSH-
>
> If you need privacy you can encrypt your mails with my GPG key:
> 9B79 7754 00E2 23C7 FC90  E5C6 E5D9 1B2F 0BD5 3C6A
>
>

-- 
Sent from Gmail Mobile

[-- Attachment #1.2: Type: text/html, Size: 2324 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Traffic on port 53 fails on LTE but works on WiFi
  2018-11-19  8:54   ` Matthias Urlichs
@ 2018-11-19 16:02     ` Roman Mamedov
  0 siblings, 0 replies; 10+ messages in thread
From: Roman Mamedov @ 2018-11-19 16:02 UTC (permalink / raw)
  To: Matthias Urlichs; +Cc: wireguard

On Mon, 19 Nov 2018 09:54:38 +0100
Matthias Urlichs <matthias@urlichs.de> wrote:

> Redirecting port 53 to their DNS (presumably one close to their LTE
> endpoint) is reasonable, that should improve speed.

There is no justification to mess with user traffic like that.

If I specifically chose to use a specific DNS server, such as 1.1.1.1 (for its
privacy and non-tracking policies, however true or not), I should be allowed
to, and I should not have that redirected back to ISP's resolvers.

By redirecting or supporting redirection of DNS traffic you step down to the
level of oppressive censorship-states, for instance in "some countries" ISPs
do that (among other things), to prevent users from reading any content by
critiques and opponents of the country's dictator.

But, the overly-eager ISPs already got their dish served, in the form of
DNS-over-HTTPS (or TLS). They thought messing with DNS to "improve speed" was
innocent enough, but nope, so now they won't get to do any of that whatsoever.

As for improving speed on LTE, it is enough that the DHCP server gives you the
ISP's resolver close to your LTE endpoint. But the choice whether or not to
use it, should be left to the user.

-- 
With respect,
Roman
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Traffic on port 53 fails on LTE but works on WiFi
  2018-11-19 15:25 Traffic on port 53 fails on LTE but works on WiFi Jacob Schooley
@ 2018-11-19 20:24 ` John
  0 siblings, 0 replies; 10+ messages in thread
From: John @ 2018-11-19 20:24 UTC (permalink / raw)
  To: jacob.schooley+wgvpn; +Cc: wireguard

OK!  Firstly, thank you to everyone who took the time to reply.  I
think it's a safe assumption that WG is functioning as it should and
that I need to identify another port on which to run.  I will post a
new thread on this topic.

On Mon, Nov 19, 2018 at 10:28 AM Jacob Schooley
<jacob.schooley+wgvpn@gmail.com> wrote:
>
> Finally, something I can actually help with.
>
> Yes, Verizon is actively blocking data through port 53.
>
> Back in 2015 I discovered by accident that VPN traffic through port 53 on Verizon was not monitored by whatever they use to calculate data usage. Even better, it worked on deactivated sim cards for a few months after they were deactivated. Basically this meant I could dig around in the local Verizon store's dumpster every few months to find sim cards, pop them into a portable hotspot, and use a VPN over 53 for completely free, unthrottled data on Verizon without even having an account with them. I was a broke high school student and my parents wouldn't allow me to have service on my phone at the time so this was a life saver.
>
> Fast forward to a couple months ago, someone else gets root on the mifi 6620L, finds the loophole, and decides to sell mifi's with a VPN client or proxy installed that redirected everything through port 53. Basically resulting in a seamless experience for free unlimited data. These hacked devices sold for $300+ on eBay. Of course, after it was in the wild Verizon started DPIing port 53 and now nothing gets through.
>
>
>
> On 11/19/18, John <graysky@archlinux.us> wrote:
> > I have a simple WireGuard VPN setup I use running WG on a home Linux
> > box and connecting to it with several iOS clients. The server peer is
> > setup on port 53 since a the networkadmins of some remote WiFi
> > networks my mobile devices seems to block udp traffic on higher ports.
> > Encrypted connections work fine on WiFi as I have setup, but do _not_
> > work when I connect via LTE (Verizon supplying the data). On LTE, I
> > am no longer able to transfer data to/from the server peer but I can
> > handshake with it.
> >
> > If I inspect the output of `sudo wg` on the server peer, I see the
> > endpoint IP address changes to reflect my Verizon LTE IP and the time
> > since the last handshake reset to a few seconds which is consistent
> > with my ability to connect to the WireGuard peer server.
> >
> > I am unable to transfer data (pull up a web site or check email etc).
> > It's as/if Verizon is blocking my data flow on port 53. If I change
> > the port from 53 to 123, it seems to work fine although I do not have
> > universal connectivity on the various WiFi networks I visit on port
> > 123. The optimal port would be 53 for my use case.
> >
> > So the questions:
> > 1) What can I try on the server peer side to diagnose?
> > 2) Do people feel that Verizon is actively blocking the connection on port
> > 53?
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Traffic on port 53 fails on LTE but works on WiFi
@ 2018-11-19 15:25 Jacob Schooley
  2018-11-19 20:24 ` John
  0 siblings, 1 reply; 10+ messages in thread
From: Jacob Schooley @ 2018-11-19 15:25 UTC (permalink / raw)
  To: wireguard

[-- Attachment #1.1: Type: text/plain, Size: 2654 bytes --]

Finally, something I can actually help with.

Yes, Verizon is actively blocking data through port 53.

Back in 2015 I discovered by accident that VPN traffic through port 53 on
Verizon was not monitored by whatever they use to calculate data usage.
Even better, it worked on deactivated sim cards for a few months after they
were deactivated. Basically this meant I could dig around in the local
Verizon store's dumpster every few months to find sim cards, pop them into
a portable hotspot, and use a VPN over 53 for completely free, unthrottled
data on Verizon without even having an account with them. I was a broke
high school student and my parents wouldn't allow me to have service on my
phone at the time so this was a life saver.

Fast forward to a couple months ago, someone else gets root on the mifi
6620L, finds the loophole, and decides to sell mifi's with a VPN client or
proxy installed that redirected everything through port 53. Basically
resulting in a seamless experience for free unlimited data. These hacked
devices sold for $300+ on eBay. Of course, after it was in the wild Verizon
started DPIing port 53 and now nothing gets through.



On 11/19/18, John <graysky@archlinux.us> wrote:
> I have a simple WireGuard VPN setup I use running WG on a home Linux
> box and connecting to it with several iOS clients. The server peer is
> setup on port 53 since a the networkadmins of some remote WiFi
> networks my mobile devices seems to block udp traffic on higher ports.
> Encrypted connections work fine on WiFi as I have setup, but do _not_
> work when I connect via LTE (Verizon supplying the data). On LTE, I
> am no longer able to transfer data to/from the server peer but I can
> handshake with it.
>
> If I inspect the output of `sudo wg` on the server peer, I see the
> endpoint IP address changes to reflect my Verizon LTE IP and the time
> since the last handshake reset to a few seconds which is consistent
> with my ability to connect to the WireGuard peer server.
>
> I am unable to transfer data (pull up a web site or check email etc).
> It's as/if Verizon is blocking my data flow on port 53. If I change
> the port from 53 to 123, it seems to work fine although I do not have
> universal connectivity on the various WiFi networks I visit on port
> 123. The optimal port would be 53 for my use case.
>
> So the questions:
> 1) What can I try on the server peer side to diagnose?
> 2) Do people feel that Verizon is actively blocking the connection on port
> 53?
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>

[-- Attachment #1.2: Type: text/html, Size: 3894 bytes --]

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, back to index

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-11-18 18:55 Traffic on port 53 fails on LTE but works on WiFi John
2018-11-19  4:26 ` Quan Zhou
2018-11-19  7:32 ` M. Dietrich
2018-11-19  8:40   ` John
2018-11-19  8:54   ` Matthias Urlichs
2018-11-19 16:02     ` Roman Mamedov
2018-11-19  9:57 ` Problem to load wireguard LKM in Archlinux Tosh
2018-11-19 15:04   ` John
2018-11-19 15:25 Traffic on port 53 fails on LTE but works on WiFi Jacob Schooley
2018-11-19 20:24 ` John

WireGuard Archive on lore.kernel.org

Archives are clonable: git clone --mirror https://lore.kernel.org/wireguard/0 wireguard/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 wireguard wireguard/ https://lore.kernel.org/wireguard \
		wireguard@lists.zx2c4.com zx2c4-wireguard@archiver.kernel.org
	public-inbox-index wireguard


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/com.zx2c4.lists.wireguard


AGPL code for this site: git clone https://public-inbox.org/ public-inbox