>Why were rules written for the second router but not the first? >Is it because it was connected first? Could we write the rules we need? What I meant was the second was connected to the first. :-)~MIKE~(-: On Sat, Jul 19, 2014 at 11:31 AM, Michael Havens wrote: > > Going the other way, you have no rules to pass > > the communication through. > > Why were rules written for the second router but not the first? Is it > because it was connected first? Could we write the rules we need? > > > :-)~MIKE~(-: > > > On Fri, Jul 18, 2014 at 3:34 PM, Gilbert T. Gutierrez, Jr. < > mailing-lists@phoenixinternet.net> wrote: > >> NAT is the reason. The ping is being translated from one network to >> another as well as telnet. Going the other way, you have no rules to pass >> the communication through. >> >> Gilbert >> >> >> On 7/18/2014 2:44 PM, Michael Havens wrote: >> >> so according to your tutorial 192.168.0.x is not on the same subnet as >> 192.168.1.x. If that is correct why can I ssh (and ping and telnet....) >> from client to host but not host to client? >> >> :-)~MIKE~(-: >> >> >> On Fri, Jul 18, 2014 at 12:30 PM, Michael Havens >> wrote: >> >>> telnet localhost 22 from the server received no answer from the client >>> telnet 192.168.1.101 22 from the client received no answer from the >>> server >>> >>> I'll get back to you about the research project >>> (and as a private message) >>> >>> :-)~MIKE~(-: >>> >>> >>> On Fri, Jul 18, 2014 at 6:41 AM, wrote: >>> >>>> Hello Michael: >>>> the 'Net' is a hodgepodge of protocols, all abiding to the 'OSI Layer >>>> Model' to work properly (http://en.wikipedia.org/wiki/OSI_model). >>>> Troubleshooting your SSH connection should be a fairly simple >>>> proposition, because there are only so many moving parts (Three!). >>>> As anything under the OSI model, nothing on an upper layer will work >>>> unless the necessary components of the lower layer are working. >>>> AND you *HAVE* to troubleshoot each layer separately. >>>> So how does this go? >>>> Well, lets take a look at your SSH problem... >>>> 1.- In order for the SSH connection to work you need 3 things: >>>> 1.1.- a SSH server, >>>> 1.2.- a SSH client and, >>>> 1.3.- a TCP/IP connection. >>>> *EACH* one of the lines above is a separate project and *HAS* to be >>>> addressed as such. >>>> Lets cover the basics first, the TCP/IP connection: >>>> You *HAVE* to *KNOW* The Mantra: >>>> "In order for any 2 devices to establish a TCP connection they have to >>>> share a physical link and they need addresses in the same subnet". >>>> The statement above is a pretty dense one, and has several >>>> implications, number one being: What does "subnet" mean? >>>> Another is: what about IPs in different subnets? >>>> We'll get there... >>>> As there are already several books written (and to be written) about >>>> the few lines above, I'll water it down to the bare minimum: >>>> The subnet is defined via the netmask, and implies that "ON" parts of >>>> the netmask are always equal in all the addresses on a network segment, so: >>>> Network: >>>> 192.168.0.0/24 or >>>> 192.168.0.0 with netmask 255.255.255.0 means that >>>> *ALL* the addresses in *THIS* network are going to look like >>>> 192.168.0.${SOMETHING_ELSE} >>>> '192.168.0' is the "Network", and "${SOMETHING_ELSE}" is the "Host". >>>> You can not use "Host 0" (because that defines the network) and you can >>>> not use the highest number (255) because that's the 'broadcast address'. >>>> Which means that any '/24" (slash 24) network can address 254 'hosts'. >>>> Network: >>>> 192.168.0.0/16 or >>>> 192.168.0.0 with netmask 255.255.0.0 means that >>>> *ALL* the addresses in *THIS* network are going to look like >>>> 192.168.${SOMETHING_ELSE}.${SOMETHING_ELSE} >>>> '192.168' is the "Network", and "${SOMETHING_ELSE}.${SOMETHING_ELSE}" >>>> is the "Host". >>>> You can not use "Host 0.0" (because that defines the network) and you >>>> can not use the highest number (255.255) because that's the 'broadcast >>>> address'. >>>> Which means that any '/16" (slash 16) network can address 65534 >>>> 'hosts'. >>>> The reason why '255' is the highest number is because IPv4 addresses >>>> (and netmasks) are represented in memory in 4 bytes, each number one byte. >>>> Bytes are 8 bits, but that's a different book that you need to read >>>> too, lets move on with the network. >>>> Things get pretty interesting (and math pretty convoluted) when you >>>> define networks like 192.168.127.0/25 >>>> If yo want to see all variations, you can be lazy (like me) and run: >>>> ipcalc 192.168.0.127/25 >>>> Finally, "Netmasks" are a patch to the first defined (and shortsighted) >>>> 'Address Type' as class A,B,C or D, but I'll let you research that >>>> yourself. >>>> >>>> Well, that's all good, but how do you talk to other addresses?, I talk >>>> to google.com... >>>> That's a valid question, but >>>> 1.- it is not part of *THIS* SSH problem and >>>> 2.- you don't 'talk to google'. >>>> We'll talk more about how devices find each other in a network down >>>> below, but in order to talk to devices outside your network you need the >>>> 'Routing Protocol' (implemented at [SURPRISE!] 'the router') which is >>>> nothing else than a table of rules stating 'this IP goes that way'. In >>>> your case, all addresses go the same place (the router) so the router >>>> becomes the 'Default Gateway'. As to resolve google, you need the DNS, but >>>> you knew that... :) >>>> >>>> Now that we know what an IP address is, lets move on to the "Physical >>>> Link". >>>> Well, a cable will do... >>>> In the wireless world, the "Association" is the link. >>>> And how do you validate that? >>>> iwconfig will tell you what (if anything) you are associated to. No >>>> association, no link, no connection, no SSH. >>>> ifconfig will tell you what (if anything) you are wired to. No wire, >>>> no link, no connection, no SSH. >>>> Ain't that simple? ;-) >>>> So we have a link... >>>> And we have IP addresses in the same subnet. >>>> So we are connected!!! 8-) >>>> Not so fast Armando!!! >>>> The fact that your addresses match is not necessarily a validation, >>>> because each computer may be connected to a different router providing the >>>> same NAT(ed) address! >>>> NAT? >>>> Yes NAT (Network Address Translation protocol), but that's yet another >>>> book, so lets water it down: >>>> NAT is the protocol that allows you to have an 'outside visible >>>> address' and an 'inside invisible network' in a router. >>>> NAT (as Netmask) was implemented mainly to alleviate the IPv4 shortage >>>> address because of the 'class A,B,C or D' mistake, but as a byproduct, you >>>> can 'hide' behind it, which provides some level of security. How you hide >>>> is yet another bookshelf and essentially means that you cannot access >>>> devices 'behind the router' unless the device initiates the connection >>>> first, and that's how you raise a WEB site from 'behind the router' and why >>>> you can SSH from 'inside to outside the router' but not the other way >>>> around, so lets move on... >>>> So, how do we know that we are connected to the same router? >>>> Ah, glad you asked: >>>> ARP! >>>> Or Address Resolution Protocol. >>>> *ALL* data transmission is done at OSI layer 2. >>>> Quick implementation manual: >>>> OSI layer 1: Cable or association. >>>> OSI layer 2: MAC address. >>>> OSI layer 3: IP address. >>>> Your network doesn't know (and doesn't care) about IP addresses. The >>>> IP address is there to resolve the MAC address. >>>> When you say: >>>> ping 192.168.0.1 >>>> that generates a 'who has' request from the ARP protocol. >>>> That request is broadcasted to anyone on the physical link (OSI layer 1) >>>> The device with the IP address interrogated by 'who has' answers with >>>> its MAC address. >>>> This IP/MAC address pair is then saved to the ARP table. >>>> >From there on (and even though the IP address goes along in the TCP/IP >>>> header) all transmissions are sent to the MAC address. >>>> But then again, how do you know that your 2 boxes are talking to the >>>> same router? >>>> arp -n|grep 192.168.1.1 >>>> Same MAC? >>>> Same box. >>>> Different MAC? >>>> Same Michael... ;-) >>>> What do we know so far? >>>> Well, we know something about line 3 of the very first paragraph. >>>> What about line 2? >>>> Type >>>> which ssh >>>> You have it or not, and you know what to do, so lets move to line 1. >>>> We now need to troubleshoot the SSH server. >>>> Well, that boils down to 2 things, it is working or not... >>>> You *KNOW* that the SSH server is 'listening' (although not necessarily >>>> working) when you can connect to the 'port' >>>> Port? >>>> Yeah, port... >>>> Lets move on up in the OSI model to the application layer. >>>> In order to establish a TCP connection you need an IP connection and a >>>> port (or a socket and a port) >>>> The port is to the application what the IP address is to the MAC. >>>> So if the port is listening, the application is awake. >>>> And how do we know? >>>> There are only 975143684 possible ways to validate a 'port is open' (or >>>> listening) but I am a simple boring guy, so I do: >>>> telnet localhost 22 >>>> I either get an answer or not. >>>> If I get an answer, then we are most likely all good, but if I don't >>>> get an answer then the ramifications are staggering and I'm not even going >>>> to think about it. >>>> In order to check that the other port listens then you: >>>> telnet ${REMOTE} 22 >>>> Again, we either get an answer or not. And the 'not' means another >>>> Sunday drive to the library... >>>> Finally, why 22? >>>> Because that's the SSH port and it is defined in the configuration >>>> file, which you can change to further complicate your (or someone else's) >>>> life. >>>> But who and where defined 22 as the SSH port? >>>> grep -i ssh /etc/services >>>> And who wrote /etc/services? >>>> http://www.iana.org/ >>>> And how do I know all this crap? >>>> Because I finished LFS!!!! ;-) >>>> I hope you see everything now as clear as mud. >>>> Keep this message handy, you'll need to read it several times... >>>> Keep in mind that what I have written here is a GROSS >>>> oversimplification of several bookshelves contained in several buildings >>>> and written along several decades all over the World, it's free advice, you >>>> can't sue me... :) >>>> And always remember: >>>> For every question there exists a simple, direct and wrong answer. >>>> if you have any question, >>>> you will get any answer... >>>> ET >>>> PS: Research project: >>>> Why doesn't 'ping' use a port? >>>> Why is 'ping' 'setuid(ed)' >>>> What are 'routable' networks? >>>> What are 'non-routable' networks? >>>> What does it mean if you get and IP address like 169.254.0.0/16 >>>> Why do you always have a 127.0.0.1 address in your boxes? >>>> Who defines (and where are the documents that define) all these >>>> protocols? (RFC anyone?) >>>> >>>> >>>> Michael Havens writes: >>>> >>>>> okay, so I bought a used computer to do Linux from scratch on. Well, >>>>> I'm >>>>> going to ssh from my primary computer to the new computer but got a >>>>> 'Connection timed out' error. After googling for a bit I discovered >>>>> ufw was >>>>> to blame. >>>>> after I disabled the firewall I could ssh from 192.168.1.101 >>>>> to >>>>> 192.168.0.4 >>>>> the error I got going the other way was the connection timed out >>>>> error: >>>>> ssh mike@192.168.1.101 >>>>> ssh: connect to host 192.168.1.101 port 22: Connection timed out >>>>> After googling some more I thought perhaps openssh-server wasn't >>>>> installed... but it is. So please.... what is the problem? I verifed >>>>> openssh-client is installed but I don't know what it could be. Could >>>>> you >>>>> help me out? >>>>> :-)~MIKE~(-: >>>>> >>>> --------------------------------------------------- >>>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org >>>> To subscribe, unsubscribe, or to change your mail settings: >>>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss >>>> >>> >>> >> >> >> --------------------------------------------------- >> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org >> To subscribe, unsubscribe, or to change your mail settings:http://lists.phxlinux.org/mailman/listinfo/plug-discuss >> >> >> >> --------------------------------------------------- >> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org >> To subscribe, unsubscribe, or to change your mail settings: >> http://lists.phxlinux.org/mailman/listinfo/plug-discuss >> > >