0

I have a Pi connected to both Wi-Fi and a cellular gateway but can only SSH into it from the Wi-Fi IP address. Port forwarding is, as far as I can tell, correctly set up on the cellular gateway. I believe that the problem is coming from the IP routing table as described in the second answer of this question and this question.

My current IP routing table looks like this:

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG        0 0          0 eth0
0.0.0.0         10.0.1.1        0.0.0.0         UG        0 0          0 wlan0
10.0.1.0        0.0.0.0         255.255.255.0   U         0 0          0 wlan0
192.168.0.1     0.0.0.0         255.255.255.255 UH        0 0          0 eth0
192.168.13.0    0.0.0.0         255.255.255.0   U         0 0          0 eth0

I want to be able to SSH from the Wi-Fi or from the Ethernet, but it is only letting me connect via the Wi-Fi IP address. When I try to SSH via the Ethernet connection I get a timeout error.

While I have found similar questions, I have not found a useful answer.

5
  • What's the IP of the machine that you're starting from? Looks like your eth0 and wlan0 are on different subnets. You don't appear to have routing between them. I bet the machine where you're originating the ssh has an address 10.0.1.X.
    – Brick
    Aug 9, 2017 at 21:33
  • This is probably going to be a straight networking question rather than a Raspberry Pi question per se. I think you'll be along the lines of what's here: serverfault.com/questions/513805/… Unfortunately, as that answer describes, this could get a bit complicated and even on the networking site it might be hard to get a good answer. As a start though, maybe answer the question in my original comment above.
    – Brick
    Aug 9, 2017 at 21:37
  • @Brick yes my ip address is 10.0.1.X because we are on the same wifi. eth0 and wlan0 are definitely on different subnets as the eth0 is a cell gateway and the wifi is our lab's cable based wifi. Hopefully this is some kind of breakthrough, but I have no idea where it is leading.
    – Murenrb
    Aug 9, 2017 at 21:42
  • Could the solution be to just turn the wifi off? We don't need it.
    – Murenrb
    Aug 9, 2017 at 21:43
  • No, that won't do it.
    – Brick
    Aug 9, 2017 at 21:43

1 Answer 1

0

Your basic problem is that the two interfaces, eth0 and wlan0 are on different subnets and those aren't getting each other's traffic. This problem in your case is probably more severe than it might be in other cases since these networks are probably connected only via public internet (as opposed to two subnets in your lab where you control everything in between).

You have several choices here, including but not limited to:

  1. Put everything that you need to communicate on the cellular network. (In the comments you implied that's the one that you need to work on the Pi.)

  2. Create a VPN to tie together the subnets through the public internet.

The first one is the simplest from a configuration point of view, but I suspect in your case it might be tough because I'm guessing you're going to tell me that the machine from which you'd like to ssh cannot get on the cellular network.

The second will require some work to get it established and you'll find other questions devoted entirely to that. I just did it, and it's not super-simple but it can be done.

Other options that "just" require routing rules seem suspect to me. You might be able to make this work if you put custom routing rules on the machines involved and / or the gateways. You'll also need to configure port forwarding on the gateways and make sure that you understand any security risks because your data will be flowing over the public internet. (I think ssh is sufficient as a first reaction, but I'd want to think that through if it were me.)

6
  • as you say, the machine that the ssh needs to originate from cannot be on the cellular network. So I will try the vpn and let you know what happens!
    – Murenrb
    Aug 9, 2017 at 22:06
  • after spending another day on this I don't fully agree with your answer. I get that a VPN would fix this, but my question is why isn't port forwarding working? The subnet issue should not stop a correct setup port forwarding system from letting me SSH into the pi behind a cell network. Can you explain why this isnt an option?
    – Murenrb
    Aug 11, 2017 at 20:24
  • Port forwarding might work. I don't think I ever definitely said it wouldn't. Just that it's not what I would recommend. If you want to try port forwarding, then you need to address the Pi by it's public IP rather than its private IP. You have to have access to whatever gateway is providing the public IP to configure port forwarding on that. (The public IP might or might not belong to something up stream from you.) If you want it to work on standard ports, you can only have one thing behind that gateway accepting connections.
    – Brick
    Aug 11, 2017 at 20:56
  • Continuing. Using the public IP of a cellular link is going to be a frail solution because that will typically change every time you connect and disconnect, requiring some sort of manual step or reconfiguration. Regarding the questions that you linked in your original post: The first seems relevant (although not clearly written as I see it), but I don't think the second answer makes sense. The other question that you linked describes a different situation where the Pi is essentially acting as a router. I don't think that applies here, unless I've misunderstood your question.
    – Brick
    Aug 11, 2017 at 21:01
  • @ Brick, thanks for the responses! Yeah, I didn't mean to sound confrontational there. Frankly I have no idea why the port forwarding isn't working. We are using the public IP and it just times out. The strange thing is we did have it working at one point. OH well. I have been working with a few different VPNs and I think I have the service working the way I want. Thanks for all your help!
    – Murenrb
    Aug 13, 2017 at 15:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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