How to get SSH working on my network

johnpoz

@gabe-a mdns is not going to work across network segments /vlans.

If you have a client on say 192.168.1.x/24 wants to find 192.168.2.x/24 mdns is not going to work. You could setup avahi to pass mdns across network segments.

edit: just dawned on me your using tnsr, I don't know if you can install or use the avahi package on that?

This works for every other router without configuration (asus, tp-link, netgear, etc).

Those routers do not support multiple networks, only 1 flat network... Your router has zero to do with how mdns works when all the devices are on the same network. But once you segment and have more than 1 network mdns does not pass L2 boundaries.

If all your devices are on the same network segment/vlan - pfsense/tnsr or any other router has zero to do with devices talking to each other be it broadcast or multicast. Or even unicast - a router would only be involved when your devices are on different networks, and the traffic needs to leave 1 network and get "routed" to another network.

gabe-a

@johnpoz

What? No, all computers that need to talk to each other are on the same network, same subnet, all served by the tnsr router. Curious where you're getting multiple network segments/vlans.

Please let me know how to enable mdns passthrough/support on the router. It's not passing hostnames.

Here's how I have to connect today:

I have to physically go to a node and read its local IP address, of the form 10.2.0.XXX
- the "XXX" part changes from time to time and can't just be written down. Also, new computers are sometimes added to the network
When I want to connect to it from another node on the SAME NETWORK/SUBNET (say, local IP 10.2.0.YYY), I have to type ssh user@10.2.0.XXX. I shouldn't have to do this because that host should be reached by "user@hostname or user@hostname.local".

You may have been confused because I mentioned I tried doing this with other routers. Let me clarify.
When I get rid of the tnsr router and replace it with a different one, ssh-ing by hostname always works. Same switch, same wiring, same hosts, same config, multiple different routers tried (not at the same time, of course -- negear, tp-link, linksys -- all work fine and let the hosts talk to each other by hostname).

Once more I am not and never would want to connect from a host on a different subnet or served by a different router, to a host on another.

I'm not asking for something complicated. I literally just want to connect from one computer to another on the same network by hostname instead of always-changing local IP. I pointed out that the problem is not in the hosts' configuration because all of them can talk to each other if I were to swap out the tnsr router with another normal/consumer one.

Also confused when you mention the router has nothing to do with this. mDNS traffic is passed on a special "end of the line" address (X.X.X.255; probably 10.2.0.255 in this case) and is subject to firewall policy governing broadcasts -- hence my request for how to enable this, as somehow it is being blocked/lost/dropped/suppressed by the router.

johnpoz

@gabe-a said in How to get SSH working on my network:

on the same network, same subnet, all served by the tnsr router.

Then it has zero to do with your problem - ZERO! A router has zero to do with traffic between devices on the same L2 network..

So unless your bridging traffic across tnsr - it has no way to interfere with multicast traffic..

If you think the router has anything to do with broadcast and multicast traffic I suggest research how broadcast and multicast work. A L3 router has nothing to do with devices talking to each other via broadcast or multicast or unicast on the same L2 network - it just doesn't.. Not how it works..

Now if your trying to resolve some hostname via actual dns and asking dns running on the router to resolve that - that would come into play. But that is not how mdns works..

mdns works by sending a multicast query to 224.0.0.251, all devices on that L2 network would see that traffic - unless at your switch or your wifi AP you were filtering that traffic.. Or that traffic was being bridged across 2 different L2 segments across your router.

https://www.rfc-editor.org/rfc/rfc6762.html
Multicast DNS

Maybe your mdns is not working because your switch or AP is not passing it - but the "router" has nothing to do with that traffic. Now if your other routers were actually answering a dns query for just a hostname, then maybe that was how it was working before and you were not actually using mdns - but unbound does not answer a non fqdn query, ie hostname - the query has to be fully qualified ie hostname.domain.tld

But if you are trying to resolve hostA.local from hostB.local via mdns the router is not involved in any way.

gabe-a

@johnpoz It could be that the other routers are querying it (all the other routers seem to know the hostnames of all devices attached). How can I enable this for tnsr?

But I also know that with mDNS disabled via ifconfig, the hosts can't talk to each other regardless of router.

So it could be both.

Again, I do not have two different segments so I know it's not a bridge at play with the other routers. Perhaps you're misunderstanding, but when I say I've tested this with other routers, I mean literally right now, right in front of me, a trivial swap of boxes and transplant all the cables to the appropriate holes in the alternative router. I literally remove just the white netgate tnsr box and swap it with my old netgear, putting all the cords into that instead (I do have to add a spf to ethernet transceiver to get it to go in the hole), but that's literally it. Both are attached to the same xfinity aria -> juniper -> [insert router here].

If that's true, it's not "ZERO" -- my expectation over many years is that routers know who's on the network by hostname and can forward this along. If that expectation is invalid for tnsr, please let me know how to fix/enable it.

Thanks!

johnpoz

@gabe-a said in How to get SSH working on my network:

mDNS disabled via ifconfig

how is it you think you do that? There is no disable mdns with ifconfig..

It could be that the other routers are querying it

No, not how mdns works..

If mdns is not working on your network that has nothing to do with the router...

If your history is with soho routers, why are you jumping to tnsr? That is a product required for high speed routing - maybe pfsense would be a better choice for you? It allows for dhcp registration of devices into dns.

gabe-a

@johnpoz
Here's how I do it (it's through systemd but the changes are reflected in ifconfig with the MULTICAST or +mDNS field):
for interface in $(ifconfig | grep "Ethernet" | sed 's/ .*//'); do systemd-resolve --set-mdns=yes --interface=$interface; done

Why tnsr?
Because pfsense is way too slow to give me my 6-7gbps Xfinity on my 10gbps network

johnpoz

@gabe-a not sure why you think that has anything to do with device A that is not your router resolving anything via mdns - that might have to do with your router/os doing asking for stuff via mdns, or answering mdns that is asking for its name - but this has zero to do with some other device on the network resolving something else on the network via mdns..

Have you even bothered to look over the rfc of how mdns works that I posted?

mdns is a non server method of resolving.. A device wanting to resolve something sends out a query via multicast - any device that sees this multicast query will answer if that is its name. This has ZERO to do with the router device on the network - ZERO!!

I put a bunch of devices on a network.. They send out a multicast query for hey is your name XYZ - what is your IP, etc. If your "routers" name is not what its looking for - your router has zero interest in this multicast traffic..

If your mdns query for hostA is not working - that has zero to do with the router.. What that could have to do with is your switching network, and or your wireless network blocking this traffic. Or it has to do with hostA answering..

If what you want to do it resolve hostA to its ip, sure mdns is an option. which has zero to do with some router that might be on the network. This is multicast and devices on the same L2 seeing the traffic and answering - your router has zero to do with this.

Or you could correctly setup dns - which is running on your router.. when it gets asks for a specific fqdn, it will respond with what it knows about. So you need to setup these records, or you need your dns to allow for say dhcp registration for some dhcp client and registering that fqdn in dns. Pfsense with unbound has have issues with in the sense that dns restarts every time, so dns in general could be problematic.. But tnsr does not even have the way to set this up from what I know of tnsr.

tnsr is a high speed routing software - it is designed to maximize speed while routing and be a firewall. If your goal is some sort of dhcp clients registering their names and dns resolving that for other clients I would suggest you run that on some other box on your network. That is not the goal of tnsr. While it can provide dhcp and dns - its goal is not everything for all use cases. I am not aware of anyway for you to have its dhcp server register devices in dns to respond to other devices asking for some fqdn.

None of this has anything to do with mdns that you mention in your 2nd post with the link to https://en.wikipedia.org/wiki/Multicast_DNS

So either have your clients actually use mdns to resolve what your trying to resolve, or setup dns to resolve your clients.. Be it you manually create records in dns, or look to a dns solution where dhcp clients are registered to be resolved via dns. But this is going to be a fqdn, not just some host name. But from my limited understanding of the feature set of tnsr, that is not something tnsr can do... at this time. unbound running on tnsr can for sure be setup to resolve some fqdn to an IP - but I am not aware of a method to allow dhcp to register some fqdn to be resolved via unbound.

But again none of this has anything to do with anything related to mdns. Which is a stand alone method of hosts on some network to resolve each others names to an IP. Routing or DNS has nothing to do with that protocol

gabe-a

@johnpoz

"not sure why you think that has anything to do with device A that is not your router resolving anything via mdns"

Then let me put two and two together to explain why I think so.

You claim my problem doesn't have anything to do with the router.

Then can you explain:

When I swap out the tnsr router with a consumer router, ssh-ing by hostname works. Just one static IP, one router, one passive switch, multiple nodes. For all tests I removed/disabled everything wireless or extraneous. Just one static IP internet, going into one router, passing through one passive ethernet switch to all devices.
When I disable mDNS on my hosts with --set-mdns=off, querying by hostname doesn't work on any router, period.

What makes you sure the router isn't suppressing mDNS broadcast/receipt?

johnpoz

@gabe-a said in How to get SSH working on my network:

What makes you sure the router isn't suppressing mDNS broadcast/receipt?

Because it can't - basic 101 networking.. Period end of story.. Please read the rfc I linked to on how mdns works...

When I disable mDNS on my hosts with

No shit when you disable mdns on a "host" it will not be able to query via mdns or answer via mdns... If you turn that off on host A, that has zero to do with B and C still using it..

Just because you don't speak french, does that keep people in france from speaking it?

If people in a room, and you put in ear plugs does that keep everyone else in the room from hearing stuff?

Host A (your router) has zero to do with hosts B and C talking multicast.. Zero!!!

gabe-a

@johnpoz

When I disable mDNS support on one or both hosts, they can't ssh via hostname. When I turn it back on, they can.

But (big but!) their mDNS-enabled discourse only works with non-tnsr routers. Why?

You claim it's as obvious as shutting out the French language for a few folks in the US but everybody in France still speaking it. What if I told you without the router, nobody in France can speak French anymore? Pretty weird huh? That's what's happening and is where your metaphor fails, no?

I don't know why you keep pointing at that random technical spec sheet. It's some spec or other, with no actionable fix to the simple problem that the tnsr router mutes my network from talking to each other via hostname. It seems you aren't getting the simple fact that with any router in the mix other than tnsr, hosts talk to each other freely by hostname and with tnsr they don't.

You can point and posture all you want but you haven't offered an explanation. You simply claim it can't happen or doesn't exist or has nothing to do with it (even though with a swap of router the entire mDNS ability of the whole network disappears completely).

Why?

gabe-a

@gabe-a And to address the strange earplugs metaphor, you're still not getting it.

According to the spec doc, the speaking French and earplugs metaphor is invalid. It's more like a telephone conversation with multiple participants or a Zoom call. If the switchboard or server goes down nobody can hear each other, regardless if someone decides to throw out their phone/laptop. I've connected computers before without a router and it doesn't end well -- nobody gets an IP address, nobody knows how or where to route traffic. The broadcast has to go somewhere. Where? The other nodes. Through what? The gateway/ router (no node implicitly knows what other nodes exist on the network!). What's that? Oh right, the tnsr box.

Here's the thing. With that tnsr server/switchboard/router/gateway, nobody can hear each other speak. It's like they all forget each other's names. Completely. Add in a non-tnsr router instead and everyone knows everybody's name again. Tnsr isn't muting the people per se, but it's somehow interfering with their ability to broadcast their names.

The reason I mentioned disabling mDNS is to prove that mDNS is required for hostname resolution to work and that's indeed the path that was being taken. (Like you say, if somebody covers their ears they can't hear the names and won't broadcast their name, but others are still fine).

But put a tnsr router in the mix instead of a consumer router, and everybody goes mute and dumb.

So what do you think is more likely? According to your theory, every single node suddenly loses the ability to speak? Or is it the one changed piece (the tnsr router) that might have something to do with it?

That's right, I'm saying when one router enters the room, the entire room grows earplugs. Explain that. Better yet, help me diagnose and fix it. It's only the tnsr router that causes this problem.

johnpoz

@gabe-a What do you not understand about how multicast works - there is no "server" in mdns..

Your host looking for some resource doesn't ask your router host.. It asks all hosts on the L2 network via a multicast query to

I'm in a room and yell hey is there a john in here? If your name is John you answer - if you have ear plugs on you don't hear anyone asking for John so you don't answer. Even if your name is john.

mdns goes out on 224.0.0.251 port 5353.. That is a multicast address, all devices on the L2 network would see that traffic - be it your router host has its mdns feature turned on or off.. Or if the whole device was off - doesn't matter doesn't stop host B or C..

So yes all my analogies are correct...

If the switchboard or server goes down

The switchboard in a multicast conversation is the "SWITCH" or the AP or the bridge.. Not some host on the same network, ie your router.. As I have clearly stated multiple times already - but you are failing to understand..

Yes you could stop all devices on a L2 network from talking multicast via your switch.. But a single host connected to your switch has nothing to do with what traffic a switch passes on to other hosts on the switch.. As clearly asked early on in this thread if your devices where on different network routed through pfsense, or if you were bridging traffic through pfsense then it could have an effect.

gabe-a

@johnpoz

I'm in a room and yell hey is there a john in here? If your name is John you answer - if you have ear plugs on you don't hear anyone asking for John so you don't answer. Even if your name is john.

Of course. But why would a different router cause me (computer A) to not hear John (computer B) telling everybody his name? I'm not wearing earplugs. I'm listening as hard as I possibly can. This is what I'm saying is broken when I bring in the tnsr router to replace my consumer router. Why are you complicating this?

mdns goes out on 224.0.0.251 port 5353.. That is a multicast address, all devices on the L2 network would see that traffic - be it your router host has its mdns feature turned on or off.. Or if the whole device was off - doesn't matter doesn't stop host B or C..

What? Host B and C only have identities on the network, and can only talk to each other through the network, because they have IP addresses assigned through DHCP by the router!

Maybe you don't quite understand my (simple, single, home, wired) setup.

Internet (static IP) --> router (tnsr or other) --> passive switch --> devices.

That's it. There's only one IP that gets internet from xfinity. Only one router that gets that internet in its input jack. Its output jack goes directly into a passive switch. Other devices plug directly into the switch with their ethernet cables. That's it. Nothing more. You talking about crazy things like bridging and multiple routers and multiple networks...nope. No way. I have one network. All I need is internet to get routed to my computers and for my computers to be able to ssh into each other. This is probably the simplest home networking need imaginable. With every consumer router this is totally expected behavior. I'm literally just trying to figure out how to do this with tnsr.

Here's the problem: when the router part is tnsr, multicast doesn't work. When the router part is any consumer router (EXACT SAME INPUT INTERNET AND EXACT SAME PASSIVE SWITCH ATTACHED), the multicast [or host name resolution] works. With tnsr it completely fails.

It's this you're simply not getting and coming up with vague metaphors of people shouting. Devices only know who the other devices are through the DHCP assigned by the router, obviously. So the router defines "who they are" on the network by assigning them the IP addresses they need to get internet and talk to each other. And ssh-ing by the IP address tnsr assigns them does work -- it's just cumbersome and ever-shifting. I want to ssh by hostname like I can with every other router.

johnpoz

@gabe-a said in How to get SSH working on my network:

With tnsr it completely fails.

tnsr or any router or any actual dns server for that matter has zero to do with devices talking mdns "multicast" to each other. What "could" be happening is you think your devices are resolving via mdns when in fact they are not.

As I mentioned before your soho router might be resolving via normal dns your "host" name for you via what it has in its dhcp leases.

unbound running on pfsense/tnsr will not do this - the query has to be fully qualified.

What I would do is validate via sniff of the traffic exactly how your stuff is resolving - if it via mdns as you think then what the router is makes no difference - the router could be off and it would still work. And a "host" on a network can not prevent other devices on the network from seeing broadcast or multicast traffic.

So going to say this again, with 30 years in the biz backing it up. mdns has zero to do with some host "your router" this is peer to peer sort of resolution. And its whole purpose was to allow for resolving resources available on the network without the traditional dns setup.

gabe-a

@johnpoz
Oh, that's interesting, good point and suggestion. I'll try to trace the route the traffic is taking when I ssh using the two schemes. I suppose if the query is going through the router I'll see the router acting as the resolver.

Well that does make sense especially since the Soho routers are always eager to advertise the names of the devices connected to them.

I may have to explore llmnr to explicitly pass this info if "pure" mDNS isn't working as expected (or if it's only part of the picture). I'd heard bad things about it (rfc here: ) https://tools.ietf.org/html/rfc4795 but that's totally inapplicable to me as the network is physically constrained, and the boxes are locked in a glass cupboard in my basement so there can be no man in the middle.

You mentioned earlier also the possibility of running avahi or something on the tnsr Ubuntu box -- my experience with network tools is they don't work as expected on the tnsr box because tnsr segments traffic into namespaces and avahi only lets Ubuntu know the hostnames, not tnsr (which handles the actual routing). Any hacks to suggest?

Thanks

johnpoz

@gabe-a said in How to get SSH working on my network:

I'll try to trace the route the traffic

There is not a "trace" of traffic - you would need to sniff and see how when you ssh hostname that name is being resolved to an IP, is it a netbios broadcast, was a dns query to your routers IP using a fqdn query or just hostname, or did it add a suffix like .local, etc. , was it mdns via multicast?

If I didn't on purpose completely disable mdns on any client that tries and do it - I would show you an example.. But I on purpose disable mdns on my windows machines - because it a horrible chatty protocol that I have zero use for - I resolve anything on my network via a simple dns query.. to my unbound running on pfsense or my pihole.

What I can show you for example when I ssh to say my nas.. what happens..

I flush the machines local dns cache so I know it has to find the IP for nas.local.lan, as you can see it does a dns query to my dns it points to, in my cache my pihole on 192.168.3.10 and gets an answer

showing where my client points for dns, and that I have mdns disabled - its horrible horrible chatty noise producing protocol..

That it is enabled by default is horrible yet another horrible choice by MS if you ask me ;)

avahi is a tool that will pass mdns across network boundaries - it has zero use for you, because as you have stated all your devices on the same network. But I have gone over how to troubleshoot that and set it up a few times.. Even though I dislike using it, and don't on my network, I know how it works and I know how to set it up, etc. I just not a fan of breaking network boundaries like that.. If you want to discover something via a L2 method - then you need to be on that L2 ;)

None which has anything to do with you, since you have clearly stated all your devices are on the same network connected to a dumb switch..

Here for example is some mdns on my wireless network my phone and printer are on..

You can see my phone 192.168.2.198 sending out queries, and the stuff it already knows about, and you see a response from my printer on 192.168.2.50 to the multicast address. What I don't see is any directed unicast responses directly from the printer to the phone for example. I would have to setup span port of where my AP is to see that, since my printer is wired..

Iphone loves to use airprint to find printers - wish I could just give it the fqdn or IP of the printer so I didn't have to allow for that nonsense noise on my network.. My PC for example has no issue just printing to the fqdn of the printer across vlans.. But vs breaking the boundary - I just put the printer on the same vlan as my wireless that devices that insist on using mdns, so I don't have to break boundaries passing mdns across network segments.

edit: here I did a sniff directly on my AP via tcpdump for this sort of traffic.. This way I did not have to really change anything on my networks or clients or create a span port to see the traffic..

12:29:06.767697 IP 192.168.2.198.5353 > 224.0.0.251.5353: 0 A (QU)? BRN30055C116AD9.local. (39)
12:29:06.787748 IP 192.168.2.50.5353 > 192.168.2.198.5353: 0*- [0q] 1/0/0 A 192.168.2.50 (49)

You can see where my phone 2.198 did a query to the multicast address, and the printer at 2.50 did a directed unicast answer back to the phones specific IP..