External SSH tunnel fails with cellular modem

ctlow wrote:

Thanks, MrHoffman,

Your assumptions are correct. I looked at the MacOS firewall, …

The built-in macOS firewall can be left at its default.

My ISP is a major cellphone-network company with a poor history of customer service, which doesn't seem to have affected its profitability, so I can try that, but I don't think I will get very far.

Major companies can serve different customers including themselves, and sometimes less so their subscribers.

They recently provided me with this brand-spanking-new cellular broadband modem, not by Ubiquiti, for a price I couldn't turn down, SSH functionality or not, so my only options I think are to return it and go back to my (expensive) cable-modem service, or live with it.

I usually use the ISP device in its bridged mode or replace it entirely where permissible and feasible, and then install gear appropriate to the tasks. ISP gear focuses on basic functions and low cost of support. Pretty much everything g else is a distant third, at best.

Interestingly, to me, the modem configuration website does list "port forwarding", but it is poorly described in the documentation, and they list in their help files that it is not possible with this model. The port-forwarding page looks like this:

Here is a generic description ofhttps://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers.

WAN port is the port facing the internet, and LAN port is the port in the internal net the traffic will get forwarded to, and the internal client is which internal host is involved. Between those two sides of the boxis usually NAT, network address translation. Because of some design fallout, NAT usually blocks all incoming IPv4 traffic. What happens with IPv6 varies. It may pass through, or it may be blocked.

Here is what the Ubiquiti port-forwarding equivalent looks like:

This is very similar ro what you are looking at, though the grouping allows the rule to operate with groups or whatever local ports or whatever local hosts together, rather than dealing with one port or one host at a time.

I don't know what most of that means. I know what a WAN and a LAN are, but not what to do with them here. Probably irrelevant to my question.

You will need a port-forwarding WAN-side rule for TCP port 22 (or another port, if you want to use a non-default port) to the internal LAN-side TCP port 22 on whichever computer is offering the ssh server on the internal network.

Here are the ports used by Apple software: TCP and UDP ports used by Apple software products - Apple Support

Here are the reserved ports, and you will usually want to recognise or (depending on what you are doing) avoid using these, if you are (for instance) picking your own WAN-side port to forward to some LAN-side host and TCP 22 LAN-side: https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers.

TCP port 8022 is not assigned, so you can conceivably “borrow” that for your external port, and set your ssh command to use (for instance) ssh -p 8022 which will then get port-forwarded to TCP 22 on whichever internal computer, once the port-forwarding rule is established. Or you can forward TCP 22 to TCP 22, but every gremlin on the internet will poke at that port. And poke lots. I usually use a VPN server and not ssh here, not the least of which is because that can forward some or all of the client app traffic using built-in tools. And I usually have firewalls with embedded VPN server capabilities.

I have more to learn about traceroute, but this command (names changed):

traceroute server.account@ddns_account.dynamic_dns_server.com

It’s usually traceroute to just the host name, without an account.

When you are making up a domain name, the domains example.org, example,com, and example.net are available, and are reserved for this and related uses.

ran for many minutes.

The first line reads (names changed):

www.company-wifi.com (192.168.x.y)  3.359 ms  2.765 ms  2.746 ms

It got up to 64 lines of:

* * *

It’s not gettig anywhere, though I;d usually use traceroute yourfirewall.example.com as the parameter, using whatever host name is temporarily yours thanks to DDNS.

and then went back to the command-line.

I don't know of any firewall-embedded VPN server. I didn't see anything like that when I looked at the MacOS one in System Settings.

To determine what features this ISP-provided box supports, you’d have to check the documentation for your ISP-provided firewall / gateway / router / NAT box.

A VPN server in the firewall is usually the best spot, as it deals with NAT, one of the scourges of IPv4.

Once the VPN is connected, your client would be effectively be another host on the same target internal network.

If the firewall lacks VPN server capabilities, it’s possible to run a VPN server on an internal host and set up port forwarding to access that, but that’s more effort and can meet some issues. Particularly around NAT, a scourge of IPv4.

Does a simple ssh work? Ignore the tunnel for a moment.

Generally to ssh into a Mac from the Internet, you have to setup the primary router to port forward a Mac port to be visible on the Internet side of the router. Is the new service providing the router?

Do you have more than 1 home router? Maybe your original, and a new one from your cellar Internet provider? That can cause connection issues.

Networking is so much fun 😀

I know you have been using ssh tunneling for 15 years, but maybe consider switching to TailScale.com

TailScale will allow your remote Mac, iPhone, iPad appear as if they are on your local LAN.

I will assume absolutely no ”coffee shop” VPN apps, no add-on security apps, no add-on firewall apps, no network-monitoring apps, or similar, are installed here.

The traceroute command would be a typical check, though ISP ssh blocks would not surprise.

As an alternative to using ssh, can you establish a VPN connection into a VPN server embedded in your firewall? (This might involve upgrading the firewall to one with an embedded VPN server.)

As for port blocks at your ISP, talk with the ISP. ISPs tend to get cranky about efforts to work around blocks they have established, too. If the ISP is blocking ssh, they may provide a workaround, may open the port, or may tell you they don’t support it or don’t permit it.

If you use Ubiquiti networking gear, as an alternative look at using their recently-announced travel router.

If your cellular ISP allows port forwarding you would configure it as:

WAN port: high numbered value below 65535. For example 55522, or 54322, or 12322, or 12345 (the trailing 22 is just a hint to me that it is for ssh)

LAN Port: 22

Internet Client: do not know what they want, but I would leave it blank, unless they had a value for ssh, otherwise ignore.

Protocol: TCP, unless the drop-down menu has ssh

WAN connection list: I would ignore, or if it has a None entry or similar, choose that.

Now your remote Mac's ssh command would be

ssh -p 55522 -L your.tunnel.info your.home.routes.IP.address

From home you can use something like Google "What is my IP address", or you have a dynamic DNS service such as no-ip.com or if you own a Synology NAS, they offer a dynamic DNS service for their Synology NAS, and the Synology NAS will keep the dynamic DNS name up-to-date. Having a dynamic DNS name makes life easier.

HOWEVER, BEFORE you switch back to your previous ISP, I strongly suggest you investigate TailScale.com. It can really make accessing your home systems while away much easier. And you are NOT limited to just ssh. Screen Sharing, network attached storage, plex, music, etc...

And TailScale DOES NOT require any IPS setup tricks. It is transparent to your ISP.

Why is it here possible TCP 22 is getting blocked by the ISP? ssh / sftp / scp gets blocked because of attacks, and accessible ssh ports get hammered.

Again, ask the ISP about their policies.

Also have a look at other options and other tunnels.

Some folks move the ssh server and ssh port elsewhere, as another option. Less traffic, but can still get poked.

And yes, do use traceroute for connection testing too, to find where things are falling apart.

Ooooooh, and multiple routers? That’s always a fun way to learn about subnetting.

Try changing your Mac making the ssh connection so the network interface has IPv6 set to “Link-local only”. This effectively disables IPv6 connections.

You could also try

ssh -4 …

Not all network setups like IPv6.

ctlow wrote:

….

Will this end up all coming down to using Bridge mode? I could ask many more questions, but is this the crux?

Bridge Mode means the gear acts like a “transparent” to networking traffic hunk of patch cable wiring, or like an (unmanaged) network switch box.

Router mode means the device contains a router, needs an IP address, may or may not NAT, will usually not pass multicast IP traffic, will usually not pass private IP address block traffic, and is otherwise decidedly less than transparent. Bridging and Routing modes are important for settings gateway boxes, and also for using access points and mesh networks.

…but says that Bridge mode may be slow…

Bridged mode should not be appreciably different than and may be faster than routing, but details can vary. Performance between bridging and routing is seldom if ever an issue for the same box.* What you’ve put behind the bridged-mode device may alter the speed; your router / gateway / NAT box.

Would I specify Bridge mode for Ethernet or for Cellular? (I can do either or both.)

I would again encourage checking with the ISP before proceeding. See if they block any ports.

By default, ~all IPv4 gateway / router / NAT boxes will block all incoming traffic, and will only allow incoming traffic secondary to outgoing traffic. Port forwarding is one way to customize this default.

The new (cellular broadband) modem-router has 3 ethernet connections, a blue one labelled "WAN/LAN" and 2 yellow ones labelled "LAN", whereas ...

One WAN connection outside for upstream ISP connection, and a switch with three inside LAN connections.

... the LinkSys Wi-Fi router has 4 blue "ethernet" connections and one yellow ethernet connection labelled "Internet".

One WAN, four LAN.

Higher-end gateway / router / NAT boxes can have multiple WAN connections for fail-over or load-balancing features. Lower-end boxes will have one WAN connection.

*boxes intended for use with one or five or ten gigabit fiber connections will ~all be faster than boxes intended for DSL-speed ISP connections, whether we’re discussing bridging or routing. Check the box specs for details. Note that gateway / router / NAT boxes performing anti-malware or packet-filtering operations (where those features are available and enabled) can be slower than the rated throughput of the box, due in no small part to the added load involved. Or, in fewer words, “it depends”.

BobHarris wrote:

Essentially, I am trying to do an advanced thing with beginner knowledge, still having trouble with basic concepts.

Please look at http://tailscale.com

it will minimize the amount of knowledge you need to learn, and let you access your home system remotely and securely.

Ubiquiti gear such as the Express 7 and the Ubiquiti travel router is the hardware analog to that.

Essentially, I am trying to do an advanced thing with beginner knowledge, still having trouble with basic concepts.

Please look at http://tailscale.com

it will minimize the amount of knowledge you need to learn, and let you access your home system remotely and securely.

Gateway / router / network address translation (NAT) boxes contain those three general functions — gateway or firewall features for allowing or blocking network traffic, router features for getting packets from the source network to the destination network and a (separate) path for packets from the remote site back (which can or will take separate network routes!), and NAT for dealing with the dearth of IPv4 addresses.

Bridges (and optical network terminals, and unmanaged switches) don’t do any of that. They’re a network connection that provides no added features other than a network path to the next upstream router. Bring your own gateway, router, and NAT features.

Having double NAT configured — two boxes both performing NAT — tends to add network connectivity problems, which is one of the larger reasons for using IPv4 bridging.

I gotta transcribe all this over into a user tip. Ah, well. Probably not today.

PS: if not using certificates for logins, make absolutely sure all passwords are secure.

Best to disable ssh password access entirely too, to avoid exposing weak passwords.

...I can't believe that I'm hearing from the great Bob Harris...

I do not think I'm that great 👑 😁

Also Hoff has done a lot more for the discussions.apple.com community, especially around networking, but also in many other areas.