I ran into this problem and Verizon told me that they filter ports 22 and 23 to help stem the tide of IoT attacks on their networks by cellular-connected phone and alarm systems. They said their operational model assumes that all traffic will be encrypted via either SSLVPN or IPSec. I’m using IPSec tuned for low traffic volume (i.e., keepalive disabled), and it’s working well for OBM.

 -mel 

On Jun 24, 2019, at 4:50 AM, Dovid Bender <dovid@telecurve.com> wrote:

I am getting the same for SSH and https traffic. It's strange. Where the response is something small like:
<html><head></head><body>
Moved to this <a href="https://63.XX.XX.XX:443/auth.asp">location</a>.
<!-- response_code_begin ERIC_RESPONSE_OK response_code_end response_msg_begin  response_msg_end  --></body></html>
It works But when I try to load pages that are any bigger it fails. Like I said before I assume it's either an issue with the MTU or window szie. I was just wondering if anyone encountered such an issue before. It's not easy getting to someone that knows something. When you have some sort of concrete info the level1 techs tend to pass you along faster.





On Mon, Jun 24, 2019 at 7:41 AM J. Hellenthal <jhellenthal@dataix.net> wrote:
Could be wrong on this but direct SSH on the LTE side may possibly be not allowed(filtered) and might just be something you could discuss in a ticket with Verizon.

-- 
 J. Hellenthal

The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.

On Jun 24, 2019, at 04:50, Dovid Bender <dovid@telecurve.com> wrote:

All,

I finally got around to putting in a Verizon LTE connection and the ping times are pretty good. There is the occasional issue however for the most part ping times are < 50 ms. I have another strange issue though. When I try to ssh or connect via the endpoints web interface it fails. If I first connect via PPTP or SSL VPN then it works. I ruled out it being my IP since if I connect direct from the PPTP or SSL VPN box then it fails as well. It seems the tunnel does something (perhaps lowering the MTU or fragmenting packets) that allows it to work. Any thoughts?

TIA.




On Mon, Feb 4, 2019 at 8:18 AM Dovid Bender <dovid@telecurve.com> wrote:
Anyone know if Verizon static IP's over LTE have same issue where they bounce the traffic around before it gets back to the NY metro area?



On Thu, Jan 3, 2019 at 6:46 PM Dovid Bender <dovid@telecurve.com> wrote:
All,

Thanks for all of the feedback. I was on site today and noticed two things.
1) As someone mentioned it could be for static IP's they have the traffic going to a specific location. The POP is in NJ there was a min. latency of 120ms which prob had to do with this.
2) I was watching the ping times and it looked something like this:
400ms
360ms
330ms
300ms
260ms
210ms
170ms
140ms
120ms
400ms
375ms

It seems to have been coming in "waves". I assume this has to do with "how cellular work" and the signal. I tried moving it around by putting it down low on the floor, moving it locations etc. and saw the same thing every time. I am going to try Verizon next and see how it goes.



On Sat, Dec 29, 2018 at 12:13 PM Mark Milhollan <mlm@pixelgate.net> wrote:
On Fri, 28 Dec 2018, Dovid Bender wrote:

>I finally got around to setting up a cellular backup device in our new POP.

>When SSH'ing in remotely the connection seems rather slow.

Perhaps using MOSH can help make the interactive CLI session less
annoying.

>Verizon they charge $500.00 just to get a public IP and I want to avoid
>that if possible.

You might look into have it call out / maintain a connection back to
your infrastructure.


/mark