1

I have a device that posts telemetry data to a remote server. Until now I've been debugging it by SSH'ing in over my local network via WiFi. In the field, the device will use a 4G modem, and I've had my ISP assign static IPs the devices for remote troubleshooting. The 4G modem is working to connect to the internet -- I can ping websites, etc. -- but I get a timeout every time I attempt to connect via SSH to the static IP. I'm sure I've misconfigured either /etc/dhcpcd.conf or /etc/network/interfaces, but I'm not sure which. The interface is eth1.

Has anyone been able to SSH into a Pi via Verizon static IP?

ifconfig:

eth1      Link encap:Ethernet  HWaddr 00:15:ff:13:77:70  
          inet addr:166.123.234.173  Bcast:166.123.234.255  Mask:255.255.255.0
          inet6 addr: dead::beef:4034:ff93:d78/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:65 errors:0 dropped:0 overruns:0 frame:0
          TX packets:153 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:5310 (5.1 KiB)  TX bytes:21669 (21.1 KiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

wlan0     Link encap:Ethernet  HWaddr b8:27:eb:4d:e4:26  
          inet addr:10.0.1.90  Bcast:10.0.1.255  Mask:255.255.255.0
          inet6 addr: fe80::29c6:be79:e368:d066/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:21633 errors:0 dropped:14440 overruns:0 frame:0
          TX packets:1597 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3120767 (2.9 MiB)  TX bytes:259096 (253.0 KiB)

/etc/network/interfaces (/etc/network/interfaces.d is empty)

# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

auto lo
iface lo inet loopback

iface eth0 inet manual

allow-hotplug wlan0
iface wlan0 inet manual
    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

allow-hotplug wlan1
iface wlan1 inet manual
    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

/etc/dhcpcd.conf

hostname
clientid
persistent
option rapid_commit
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
option ntp_servers
#option interface_mtu
require dhcp_server_identifier
slaac private
nohook lookup-hostname

Routing table:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         173.sub-166-123 0.0.0.0         UG    204    0        0 eth1
default         10.0.1.1        0.0.0.0         UG    303    0        0 wlan0
10.0.1.0        *               255.255.255.0   U     303    0        0 wlan0
166.123.234.0   *               255.255.255.0   U     204    0        0 eth1
my.usb          173.sub-166-123 255.255.255.255 UGH   204    0        0 eth1
1

An option I use for one of my mobile setups where a system needs to connect to the pi rather than the pi to the system, is to have the pi 'connect in' via OpenVPN (TAP interface), at which point it appears on the local network, making connecting to it easy.

From the comments, it appears your ssh attempts are being blocked in some manner (could be filtering, could be NAT). As long as they're not blocking OpenVPN traffic outbound, that addresses the directional reach-ability issue.

The potential down side is having to set up and maintain the OpenVPN server.

  • Any idea what additional bandwidth your setup adds? The pi is on an M2M data plan with only 20MB/month; I use ~10MB of that on telemetry data. – nrlakin Jan 11 '17 at 13:41
  • I haven't done much traffic analysis on the unit in operation yet (project list just grew a little), but after some poking around, it appears that openvpn is around 69 bytes per packet of overhead, give or take based on settings -> reference <- so I'd guess in the 4-5% range over same-network traffic. – tabbek Jan 12 '17 at 2:27
  • The issue was indeed on Verizon's side; they recently instituted a policy to block incoming connections to devices on an M2M plan. A VPN is now the only option. – nrlakin Jan 20 '17 at 18:05
1

I hope I've understood your question correctly. As far as I can tell, the Raspberry Pi is attached to a 4G network with a known IP address. The device that you are SSHing from is not connected to the same local network as the Raspberry Pi. Security in the router prevents you from connecting to the Raspberry Pi from a different local network. You will need to go into the configuration of your router and enable a feature called "Port Forwarding" for your Raspberry Pi on port 22 (which is the port that SSH uses). If you need help doing this, search for the manual for your model of router online and follow the instructions.

  • You're close--the issue is that there is no router. The 4G modem is plugged directly into the Pi and shows up as a second ethernet interface under ifconfig. The inet addr listed under ifconfig is the correct IP (i.e., the public static IP I purchased). Outgoing HTTP requests are using this IP. Everything seems to be working except that I can't SSH in; attempts aren't even showing up in the sshd log. – nrlakin Jan 10 '17 at 22:06
  • If your SSH attempts aren't showing up, that means that they are either not being sent from your computer, or the modem is blocking them from reaching the Pi. If it's the latter, then I'm out of ideas. Does the manual of the modem say anything about port forwarding? – user59801 Jan 10 '17 at 22:14
  • The modem manual is pretty useless--it's 80 pages describing the web interface. Running traceroute on the IP shows the request dying somewhere in Verizon's network. I'm getting conflicting opinions from Verizon on whether or not their modems even allow incoming connections. I'm thinking the connection is never making it out of Verizon's network. I'll update if I hear anything; they must have some mechanism for remote access for M2M users. – nrlakin Jan 10 '17 at 22:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.