Verizon/Qwest single end-user difficulty vs Xfinity
Verizon 5G Internet Support is not at a high-enough pay grade to assess this problem... So I'm turning to y'all. I'm trying to save $$$ and increase speed, using Verizon 5G Home Internet to replace XFinity, even though they gave me a faster modem a few weeks ago. I run both of the modems in Bridge/Passthrough mode. A friend of mine is nice enough to offer some offsite backup space, and I use rsync over ssh to get there. He's 1500 miles away. He uses a non-standard ssh port (keeps the doorknob twisters away). This sort of thing has been working without difficulty over Xfinity (my end) for years. He also changed his connection almost a month ago now, to Qwest, I believe. I try the same thing over Verizon [1] and ssh always times out, no response. We are also NTP peers, and that doesn't work well over Verizon either. ICMP traceroutes and pings succeed. UDP traceroutes do not get any further than 207.109.3.78 (last hop before destination) . Not every traceroute offers TCP, but MacOS does, and nothing responds to any of that, even at the usual ssh port. UDP traceroutes to either port behave like an ordinary one, which it is. Since I can get there via xfinity, I can traceroute, ping, but not ssh back through Verizon. I also set up an incoming (xfinity) port from the same non-standard ssh port forwarding to regular ssh on a different system on my LAN, and when I ssh -p <port> that from Verizon (even cellphone data), I get that other system, and that works fine. The 207... router is not in that path. I can also ping the Verizon connection from Xfinity (and vice versa). Go figure. [1] This same difficulty occurs in Verizon's Looking Glass, from several different places, and other Looking Glasses (e.g. Cogent, Equinix). It also occurs on my Verizon phone data connection (not WiFi). If he were serving more stuff out of his home, this would be a bigger problem. -- Jeff Woolsey {woolsey,jlw}@{jlw,jxh}.com first.last@{gmail,jlw}.com Spum bad keming. Nature abhors a straight antenna, a clean lens, and empty storage. "Delete! Delete! OK!" -Dr. Bronner on disk space management "Card sorting, Joel." -me, re Solitaire
Verizon does weird stuff with traffic in their cell network. Like wireguard only running 1-2 Mbps over Verizon but faster on fixed like providers. I'm assuming they rate limit certain protocols to avoid bypassing their streaming video rate limits. I can see 200/30 Mbps on a 4G speedtest but VPN runs very slow still. Xfinity is better than cellular so I'd switch back. Any fixed cable, fiber, wisp, or fast dsl provider should be better and more stable. On Sat, Mar 18, 2023, 2:51 PM Jeff Woolsey <jlw@jlw.com> wrote:
Verizon 5G Internet Support is not at a high-enough pay grade to assess this problem... So I'm turning to y'all.
I'm trying to save $$$ and increase speed, using Verizon 5G Home Internet to replace XFinity, even though they gave me a faster modem a few weeks ago. I run both of the modems in Bridge/Passthrough mode.
A friend of mine is nice enough to offer some offsite backup space, and I use rsync over ssh to get there. He's 1500 miles away. He uses a non-standard ssh port (keeps the doorknob twisters away). This sort of thing has been working without difficulty over Xfinity (my end) for years. He also changed his connection almost a month ago now, to Qwest, I believe.
I try the same thing over Verizon [1] and ssh always times out, no response. We are also NTP peers, and that doesn't work well over Verizon either. ICMP traceroutes and pings succeed. UDP traceroutes do not get any further than 207.109.3.78 (last hop before destination) . Not every traceroute offers TCP, but MacOS does, and nothing responds to any of that, even at the usual ssh port. UDP traceroutes to either port behave like an ordinary one, which it is.
Since I can get there via xfinity, I can traceroute, ping, but not ssh back through Verizon.
I also set up an incoming (xfinity) port from the same non-standard ssh port forwarding to regular ssh on a different system on my LAN, and when I ssh -p <port> that from Verizon (even cellphone data), I get that other system, and that works fine. The 207... router is not in that path.
I can also ping the Verizon connection from Xfinity (and vice versa).
Go figure.
[1] This same difficulty occurs in Verizon's Looking Glass, from several different places, and other Looking Glasses (e.g. Cogent, Equinix). It also occurs on my Verizon phone data connection (not WiFi). If he were serving more stuff out of his home, this would be a bigger problem.
-- Jeff Woolsey {woolsey,jlw}@{jlw,jxh}.com first.last@{gmail,jlw}.com Spum bad keming. Nature abhors a straight antenna, a clean lens, and empty storage. "Delete! Delete! OK!" -Dr. Bronner on disk space management "Card sorting, Joel." -me, re Solitaire
You mentioned using a non-standard port for your ssh/rsync, have you tried changing that to something other than what your using? Keep in mind some of these providers might be blocking non-standard ports as this is a common method to abuse others and might be a cheaper alternative to dealing with the constant pile of abuse complaints. Maybe not just a thought. -Joe On Sat, Mar 18, 2023 at 2:51 PM Jeff Woolsey <jlw@jlw.com> wrote:
Verizon 5G Internet Support is not at a high-enough pay grade to assess this problem... So I'm turning to y'all.
I'm trying to save $$$ and increase speed, using Verizon 5G Home Internet to replace XFinity, even though they gave me a faster modem a few weeks ago. I run both of the modems in Bridge/Passthrough mode.
A friend of mine is nice enough to offer some offsite backup space, and I use rsync over ssh to get there. He's 1500 miles away. He uses a non-standard ssh port (keeps the doorknob twisters away). This sort of thing has been working without difficulty over Xfinity (my end) for years. He also changed his connection almost a month ago now, to Qwest, I believe.
I try the same thing over Verizon [1] and ssh always times out, no response. We are also NTP peers, and that doesn't work well over Verizon either. ICMP traceroutes and pings succeed. UDP traceroutes do not get any further than 207.109.3.78 (last hop before destination) . Not every traceroute offers TCP, but MacOS does, and nothing responds to any of that, even at the usual ssh port. UDP traceroutes to either port behave like an ordinary one, which it is.
Since I can get there via xfinity, I can traceroute, ping, but not ssh back through Verizon.
I also set up an incoming (xfinity) port from the same non-standard ssh port forwarding to regular ssh on a different system on my LAN, and when I ssh -p <port> that from Verizon (even cellphone data), I get that other system, and that works fine. The 207... router is not in that path.
I can also ping the Verizon connection from Xfinity (and vice versa).
Go figure.
[1] This same difficulty occurs in Verizon's Looking Glass, from several different places, and other Looking Glasses (e.g. Cogent, Equinix). It also occurs on my Verizon phone data connection (not WiFi). If he were serving more stuff out of his home, this would be a bigger problem.
-- Jeff Woolsey {woolsey,jlw}@{jlw,jxh}.com first.last@{gmail,jlw}.com Spum bad keming. Nature abhors a straight antenna, a clean lens, and empty storage. "Delete! Delete! OK!" -Dr. Bronner on disk space management "Card sorting, Joel." -me, re Solitaire
On Sat, Mar 18, 2023 at 12:52 PM Jeff Woolsey <jlw@jlw.com> wrote:
Verizon 5G Internet Support is not at a high-enough pay grade to assess this problem... So I'm turning to y'all.
I'm trying to save $$$ and increase speed, using Verizon 5G Home Internet to replace XFinity, even though they gave me a faster modem a few weeks ago. I run both of the modems in Bridge/Passthrough mode.
Uh...there's a pretty big difference between "Bridge" and "IP Passthrough"; I suspect you're actually running IP Passthrough, *not* bridge, and therein may lie your problem. In Bridge mode, the CPE acts as a layer 2 device, and by and large does not get involved in layer 3 politics. In IP Passthrough mode, the CPE is the layer 3 termination point for the IP address; it looks at the five tuple to determine if the packet is one that *it* needs to accept (management traffic from the ISP to the CPE), in which case it is handed to the CPE CPU to process locally; otherwise, the destination MAC is altered to the customer's router MAC address, and the frame is re-sent out the LAN side towards the customer's router. Because the CPE is the initial termination point for the layer 3 connections in IP Passthrough mode, you have two points of possible interaction: 1) you should make sure any and all firewall settings, content filters, and ALGs are disabled on the CPE, as they will still block traffic from being passed through and 2) any port/protocol tuple on the CPE that is used for managing the device from the ISP end *cannot* be passed through to the customer router, as it will be intercepted and terminated on the CPE CPU locally. So--if you've turned off every family filter option, every firewall rule, and ALG, and you still can't reach that port, I suspect you're trying to use a port that is one that the ISP uses for managing their CPE devices, such as TCP 7547. Try switching to a different port number, and see if your connection works as expected. For more exhaustively in-depth details of what 5-tuples your CPE in IP Passthrough will ingest upstream of you, I refer you to https://www.broadband-forum.org/download/TR-069_Amendment-5.pdf specificially sections 3.2.2 and Annex K, starting on page 185. Best of luck! Matt
participants (4)
-
Darin Steffl -
Jeff Woolsey -
Joe -
Matthew Petach