Route Table Question

Comments

5 comments

  • Avatar
    Firewalla

    There is a NAT between the overlay and the normal subnet.  So on 192.168.218.x you can SSH into any host on 192.168.32.x, but if you are on 192.168.32.x, if you want to ssh into 192.168.218.x, you will need to add a port forward under settings.

    0
    Comment actions Permalink
  • Avatar
    Kevin Wyrick

    I do have a static route defined on the Synology to route 192.168.218.0 to 192.168.32.117 ( firewalla ).

     

    I have no issues ssh'ing from .32 or WAN to the 218 network.   My problem occurs when I try to ssh between two devices where both are inside of the 218 subnet.  I was wondering if the route table above where 218 was being sent to the WAN was the culprit?

    0
    Comment actions Permalink
  • Avatar
    Firewalla

    The overlay network should not be visible to synology ... so adding a route there should have unpredictable results.  Even both devices (synology and firewalla) share layer 2 (MAC layer), the IP layer of the .32 network is owned by synology and .218 is owned by firewalla ...

    0
    Comment actions Permalink
  • Avatar
    Kevin Wyrick

    The overlay network is not visible to the Synology.  The route table posted above is from the Firewalla.  The static route I put on the Synlology is external to this issue, and I probably should not have mentioned it other than to show I have a few devices still on the .32 that can ssh back to devices on the .218 with no issues.  The route was added because the Synology would have sent that traffic to the WAN otherwise.  The issue here is communication between two devices on the .218.

    The initial question is regarding the route table posted in the first post from the Firewalla.  Why is .218 traffic being routed to the WAN, and could that be an issue that is keeping two devices that are both .218 from completing a handshake.  I am not a network guy, so I understand it is likely there for a reason I do not understand, but am bringing it up based on my case.

    0
    Comment actions Permalink
  • Avatar
    Kevin Wyrick

    After more testing, not a routing issue.

    The PI that I was having issues with was connected via "wlan0" to the router's AP.  I changed to a SSID of an AP that is connected to a switch that is connected to a LAN port on the router.  The Firewalla is connected to the same switch as the remote AP.  Now I my connection issues are gone.  Nothing changes with the subnet, and the Pi's IP does not change.

    If I move back to the router's AP, they return.  I can ping, but ssh turns an ssh_exchange_identification: read: connection reset by peer.

    0
    Comment actions Permalink

Please sign in to leave a comment.

Powered by Zendesk