You are not logged in.
Hello,
I've been hacking at this all day and I have come up short with any explanation. I have a Unifi Dream Machine Pro setup as my DHCP server. This results on my nameserver on my arch linux install to be the IP of the UDMP. However, when attempting to ping any webpage, I get "Temporary failure in name resolution"
This is the result of running ip link
https://photos.app.goo.gl/SuiFAnbZNREu7Tws5
This is the result of running ip address
https://photos.app.goo.gl/LVDBFzWEY4Nb1CVZ8
From what I can tell, I have an IP assigned by the UDMP and it matches what the Unifi UI shows me. However, nothing is able to be resolved. My resolve.conf looks like this
# Generated by NetworkManager
search localdomain
nameserver 192.168.0.1The nameserver is the UDMP. I'm able to resolve addresses on my Mac using that. I can ping it on my linux machine, but I can't access the UI at that IP from a browser and I can't SSH with a "connection refused"
I apologize for the images. Even changing the DNS servers on my install to "8.8.8.8" results in intermittent DNS failures. So it's hard to copy and email these to myself.
Last edited by SirMyztiq (2020-05-08 02:40:23)
Offline
Can you "ping 8.8.8.8" ?
Can you "dig @8.8.8.8 google.com" ?
Do you run systemd-resolved ?
Because of the ma-haaanny bridge devices (what's that all about? docker?): what's your routing table like? => "ip r"
Offline
Can you "ping 8.8.8.8" ?
Can you "dig @8.8.8.8 google.com" ?
Do you run systemd-resolved ?
Because of the ma-haaanny bridge devices (what's that all about? docker?): what's your routing table like? => "ip r"
I can ping 8.8.8.8
I can also ping the IP of my UDMP. But I can't SSH or hit the UI through the IP...
Doing "dig @8.8.8.8 google.com" actually times out. But doing "dig @1.1.1.1 google.com" works...
I don't run systemd-resolved. Although I did start the service earlier but didn't get much after that.
Here is "ip r"
https://photos.app.goo.gl/yNBWvAem16ziuiq97
Here are both "dig"s
https://photos.app.goo.gl/g4aJULFSraeNKarU6
I'm not sure what created all those extra bridges. I'm assuming docker as well!
Offline
What if you use 1.1.1.1 as resolver in resolve.conf?
I can also ping the IP of my UDMP. But I can't SSH or hit the UI through the IP...
nmap 192.168.0.1You can still access it from your mac? Log in and check dhcp clients, for MAC filters, the routing and IP tables/netfilter.
One more thing since we don't know the actual network layout: https://security.stackexchange.com/ques … ea-network
Especially if there're no traffic indicator LEDs.
Offline
What if you use 1.1.1.1 as resolver in resolve.conf?
I can also ping the IP of my UDMP. But I can't SSH or hit the UI through the IP...
nmap 192.168.0.1You can still access it from your mac? Log in and check dhcp clients, for MAC filters, the routing and IP tables/netfilter.
One more thing since we don't know the actual network layout: https://security.stackexchange.com/ques … ea-network
Especially if there're no traffic indicator LEDs.
If I change the nameserver to 1.1.1.1 it works. I've tried it before and just tried it. However, it's EXTREMELY fickle and slow. DNS resolution goes in and out.
I'm able to SSH, access the UI and everything from my mac. I looked at every possible security configuration. Nothing that points to the culprit.
I also ran the nmap command to find any DHCP server and it found the UDMP which was expected.
Would a tool like wireshark help me see the bits and pieces?
Last edited by SirMyztiq (2020-05-06 15:26:24)
Offline
I'd first check the lower layers.
Take docker and those bridges out and check your journal on whether you reconnect (carrier events) all the time.
How's the local connection (eg. w/ your macbook)?
Offline
Closed: I have no idea what docker was doing but running a "docker network prune" to clear out all those networks seems to have done the trick.
seth, thank you so much for helping me out!
Last edited by SirMyztiq (2020-05-08 02:40:53)
Offline