[opensuse-support] ??firewall?? problem

newer
[opensuse-support] Docking station...

older
[opensuse-support] 15.0 most boots...

Patrick Shanahan

2 Apr 2019 2 Apr '19

20:05

my local server is running Leap 42.2 all local machines may connect to the server, except one, 192.168.1.10 192.168.1.10 is my main workstation and connected fine until 08:36am this morning local time -4 utc. no software change nor noted system abnormality, except the open ssh windows on 192.168.1.10 froze, would not accept input. ping fails both ways. stopping SuSEfirewall2 on the server allows connection and ping succeedes both ways server -> 192.168.1.10 and 192.168.1.10 -> server (192.168.1.3) of course I do not wish to run my server w/o a firewall, even though there is one within the router. this has happed before, maybe twice, and merely swapping the server's cat5 cable on the router sufficed, not not this time. I am lost? any and all assistance appreciated. tks, -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Show replies by date

Patrick Shanahan

2 Apr 2 Apr

20:08

* Patrick Shanahan [04-02-19 16:06]:

...

my local server is running Leap 42.2 all local machines may connect to the server, except one, 192.168.1.10

192.168.1.10 is my main workstation and connected fine until 08:36am this morning local time -4 utc.

no software change nor noted system abnormality, except the open ssh windows on 192.168.1.10 froze, would not accept input. ping fails both ways.

stopping SuSEfirewall2 on the server allows connection and ping succeedes both ways server -> 192.168.1.10 and 192.168.1.10 -> server (192.168.1.3) of course I do not wish to run my server w/o a firewall, even though there is one within the router.

this has happed before, maybe twice, and merely swapping the server's cat5 cable on the router sufficed, not not this time.

I am lost? any and all assistance appreciated.

one other thing I failed to mention, I power cycled the router to no avail. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Patrick Shanahan

22:38

* Patrick Shanahan [04-02-19 16:11]:

...

* Patrick Shanahan [04-02-19 16:06]:

...
my local server is running Leap 42.2 all local machines may connect to the server, except one, 192.168.1.10

192.168.1.10 is my main workstation and connected fine until 08:36am this morning local time -4 utc.

concerned interfaces are ssh, nfs and http

...

...
no software change nor noted system abnormality, except the open ssh windows on 192.168.1.10 froze, would not accept input. ping fails both ways.

stopping SuSEfirewall2 on the server allows connection and ping succeedes both ways server -> 192.168.1.10 and 192.168.1.10 -> server (192.168.1.3) of course I do not wish to run my server w/o a firewall, even though there is one within the router.

this has happed before, maybe twice, and merely swapping the server's cat5 cable on the router sufficed, not not this time.

I am lost? any and all assistance appreciated.

one other thing I failed to mention, I power cycled the router to no avail.

-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Lew Wolfgang

23:20

On 04/02/2019 03:38 PM, Patrick Shanahan wrote:

...

* Patrick Shanahan [04-02-19 16:11]:

...
* Patrick Shanahan [04-02-19 16:06]:

...
my local server is running Leap 42.2 all local machines may connect to the server, except one, 192.168.1.10

192.168.1.10 is my main workstation and connected fine until 08:36am this morning local time -4 utc. concerned interfaces are ssh, nfs and http

...
...
no software change nor noted system abnormality, except the open ssh windows on 192.168.1.10 froze, would not accept input. ping fails both ways.

stopping SuSEfirewall2 on the server allows connection and ping succeedes both ways server -> 192.168.1.10 and 192.168.1.10 -> server (192.168.1.3) of course I do not wish to run my server w/o a firewall, even though there is one within the router.

Time for some troubleshooting? 192.168.1.3 is the server, right? From your workstation, have you tried nmap to see what ports are open? Maybe try it with the server's firewall both on and off. You should see ports 22, 2049, 80, and maybe 111. Then, if you can see the ports, maybe try telnet to see if you can establish a tcp connection and get a banner on port 22. As in "telnet 192.168.1.3 22". Oh, are you running ipv6? Of course, things become more complicated if Windows are involved. All the machines are running Linux, right? Regards, Lew -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Patrick Shanahan

3 Apr 3 Apr

01:24

* Lew Wolfgang [04-02-19 19:22]:

...

On 04/02/2019 03:38 PM, Patrick Shanahan wrote:

...
* Patrick Shanahan [04-02-19 16:11]:

...
* Patrick Shanahan [04-02-19 16:06]:

...
my local server is running Leap 42.2 all local machines may connect to the server, except one, 192.168.1.10

192.168.1.10 is my main workstation and connected fine until 08:36am this morning local time -4 utc. concerned interfaces are ssh, nfs and http

...
...
no software change nor noted system abnormality, except the open ssh windows on 192.168.1.10 froze, would not accept input. ping fails both ways.

stopping SuSEfirewall2 on the server allows connection and ping succeedes both ways server -> 192.168.1.10 and 192.168.1.10 -> server (192.168.1.3) of course I do not wish to run my server w/o a firewall, even though there is one within the router.

Time for some troubleshooting? 192.168.1.3 is the server, right? From your workstation, have you tried nmap to see what ports are open? Maybe try it with the server's firewall both on and off. You should see ports 22, 2049, 80, and maybe 111.

from server/192.168.1.3 # nmap -F 192.168.1.3 Starting Nmap 6.47 ( http://nmap.org ) at 2019-04-02 21:09 EDT Nmap scan report for wahoo.wahoo.no-ip.org (192.168.1.3) Host is up (0.000015s latency). Not shown: 92 closed ports PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 80/tcp open http 111/tcp open rpcbind 139/tcp open netbios-ssn 445/tcp open microsoft-ds 2049/tcp open nfs 3306/tcp open mysql Nmap done: 1 IP address (1 host up) scanned in 1.55 seconds # systemctl stop SuSEfirewall2 wahoo: ~ # nmap -F 192.168.1.3 Starting Nmap 6.47 ( http://nmap.org ) at 2019-04-02 21:09 EDT Nmap scan report for wahoo.wahoo.no-ip.org (192.168.1.3) Host is up (0.000020s latency). Not shown: 92 closed ports PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 80/tcp open http 111/tcp open rpcbind 139/tcp open netbios-ssn 445/tcp open microsoft-ds 2049/tcp open nfs 3306/tcp open mysql Nmap done: 1 IP address (1 host up) scanned in 1.55 seconds # systemctl start SuSEfirewall2 from workstation/192.168.1.10 # nmap -F 192.168.1.10 Starting Nmap 7.70 ( https://nmap.org ) at 2019-04-02 21:17 EDT Nmap scan report for crash.wahoo.no-ip.org (192.168.1.10) Host is up (0.000023s latency). Not shown: 96 closed ports PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 111/tcp open rpcbind 2049/tcp open nfs Nmap done: 1 IP address (1 host up) scanned in 1.54 seconds # systemctl stop firewalld # nmap -F 192.168.1.10 Starting Nmap 7.70 ( https://nmap.org ) at 2019-04-02 21:17 EDT Nmap scan report for crash.wahoo.no-ip.org (192.168.1.10) Host is up (0.000011s latency). Not shown: 96 closed ports PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 111/tcp open rpcbind 2049/tcp open nfs Nmap done: 1 IP address (1 host up) scanned in 1.59 seconds # systemctl start firewalld

...

Then, if you can see the ports, maybe try telnet to see if you can establish a tcp connection and get a banner on port 22. As in "telnet 192.168.1.3 22".

from 192.168.1.10 to server 192.168.1.3 # telnet 192.168.1.3 22 Trying 192.168.1.3... telnet: connect to address 192.168.1.3: Connection timed out from server to workstation (192.168.1.3 -> 192.168.1.10) # telnet 192.168.1.10 22 Trying 192.168.1.10... telnet: connect to address 192.168.1.10: Connection timed out

...

Oh, are you running ipv6?

it is enabled but not knowing enough about ipv6, I use ipv4 for internal net commands.

...

Of course, things become more complicated if Windows are involved. All the machines are running Linux, right?

there are windows machines on the net but not involved. afaics the *only* difficulty is between workstation 192.168.1.10 and the server 192.168.1.3 and stopping the server firewall allows ssh from workstation to succeed. tks -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Carlos E. R.

02:15

On 03/04/2019 03.24, Patrick Shanahan wrote:

...

* Lew Wolfgang <> [04-02-19 19:22]:

...

from server/192.168.1.3

# nmap -F 192.168.1.3

So you are scanning your server, from your server.

...

Starting Nmap 6.47 ( http://nmap.org ) at 2019-04-02 21:09 EDT Nmap scan report for wahoo.wahoo.no-ip.org (192.168.1.3)

Something weird in the DNS. It is reporting an internet name for an internal IP.

...

Host is up (0.000015s latency). Not shown: 92 closed ports PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 80/tcp open http 111/tcp open rpcbind 139/tcp open netbios-ssn 445/tcp open microsoft-ds 2049/tcp open nfs 3306/tcp open mysql

Nmap done: 1 IP address (1 host up) scanned in 1.55 seconds

# systemctl stop SuSEfirewall2

wahoo: ~ # nmap -F 192.168.1.3

Starting Nmap 6.47 ( http://nmap.org ) at 2019-04-02 21:09 EDT Nmap scan report for wahoo.wahoo.no-ip.org (192.168.1.3) Host is up (0.000020s latency). Not shown: 92 closed ports PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 80/tcp open http 111/tcp open rpcbind 139/tcp open netbios-ssn 445/tcp open microsoft-ds 2049/tcp open nfs 3306/tcp open mysql

Nmap done: 1 IP address (1 host up) scanned in 1.55 seconds

# systemctl start SuSEfirewall2

from workstation/192.168.1.10

# nmap -F 192.168.1.10

So you are scanning your client, from your client. I don't think this gives any information. Assuming that it is the server which blocks the connection, you have to scan the server from two client locations. Or scan in both directions, client to server, then server to client. Using one working client and one faulty client. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

Lew Wolfgang

02:34

On 04/02/2019 07:15 PM, Carlos E. R. wrote:

...

So you are scanning your client, from your client. I don't think this gives any information.

Assuming that it is the server which blocks the connection, you have to scan the server from two client locations.

Or scan in both directions, client to server, then server to client. Using one working client and one faulty client.

Right, that's what I meant, but didn't say it very well. At least a self-scan shows all the daemon-backed ports. Regards, Lew -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Patrick Shanahan

03:19

* Carlos E. R. [04-02-19 22:16]: [...]

...

So you are scanning your client, from your client. I don't think this gives any information.

Assuming that it is the server which blocks the connection, you have to scan the server from two client locations.

Or scan in both directions, client to server, then server to client. Using one working client and one faulty client.

server to workstation that fails (192.168.1.3 -> 192.168.1.10) # nmap -F 192.168.1.10 Starting Nmap 6.47 ( http://nmap.org ) at 2019-04-02 23:05 EDT Nmap scan report for Crash.wahoo.no-ip.org (192.168.1.10) Host is up (0.00030s latency). Not shown: 94 filtered ports PORT STATE SERVICE 22/tcp open ssh 111/tcp open rpcbind 1720/tcp closed H.323/Q.931 1723/tcp closed pptp 1755/tcp closed wms 2049/tcp open nfs MAC Address: 70:71:BC:E9:03:C0 (Pegatron) Nmap done: 1 IP address (1 host up) scanned in 1.97 seconds # systemctl stop SuSEfirewall2 # nmap -F 192.168.1.10 Starting Nmap 6.47 ( http://nmap.org ) at 2019-04-02 23:05 EDT Nmap scan report for Crash.wahoo.no-ip.org (192.168.1.10) Host is up (0.00026s latency). Not shown: 94 filtered ports PORT STATE SERVICE 22/tcp open ssh 111/tcp open rpcbind 1720/tcp closed H.323/Q.931 1723/tcp closed pptp 1755/tcp closed wms 2049/tcp open nfs MAC Address: 70:71:BC:E9:03:C0 (Pegatron) Nmap done: 1 IP address (1 host up) scanned in 3.68 seconds # systemctl start SuSEfirewall2 failing workstation to server (192.168.1.10 -> 192.168.1.3) # nmap -F 192.168.1.3 Starting Nmap 7.70 ( https://nmap.org ) at 2019-04-02 23:09 EDT Nmap scan report for wahoo.wahoo.no-ip.org (192.168.1.3) Host is up (0.00013s latency). All 100 scanned ports on wahoo.wahoo.no-ip.org (192.168.1.3) are filtered MAC Address: 78:E3:B5:AD:F1:2F (Hewlett Packard) Nmap done: 1 IP address (1 host up) scanned in 3.47 seconds # systemctl stop firewalld nmap -F 192.168.1.3 Starting Nmap 7.70 ( https://nmap.org ) at 2019-04-02 23:10 EDT Nmap scan report for wahoo.wahoo.no-ip.org (192.168.1.3) Host is up (0.00012s latency). All 100 scanned ports on wahoo.wahoo.no-ip.org (192.168.1.3) are filtered MAC Address: 78:E3:B5:AD:F1:2F (Hewlett Packard) Nmap done: 1 IP address (1 host up) scanned in 3.44 seconds # systemctl start firewalld with server firewall stopped (192.168.1.3) # nmap -F 192.168.1.3 Starting Nmap 7.70 ( https://nmap.org ) at 2019-04-02 23:11 EDT Nmap scan report for wahoo.wahoo.no-ip.org (192.168.1.3) Host is up (0.00010s latency). Not shown: 92 closed ports PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 80/tcp open http 111/tcp open rpcbind 139/tcp open netbios-ssn 445/tcp open microsoft-ds 2049/tcp open nfs 3306/tcp open mysql MAC Address: 78:E3:B5:AD:F1:2F (Hewlett Packard) Nmap done: 1 IP address (1 host up) scanned in 1.61 seconds # systemctl start SuSEfirewall2 another workstation to server with both firewalls up (192.168.1.2 -> 192.168.1.3) # nmap -F 192.168.1.3 Starting Nmap 7.70 ( https://nmap.org ) at 2019-04-02 23:15 EDT Nmap scan report for wahoo.wahoo.no-ip.org (192.168.1.3) Host is up (0.0047s latency). Not shown: 90 filtered ports PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 80/tcp open http 111/tcp open rpcbind 139/tcp open netbios-ssn 443/tcp closed https 445/tcp open microsoft-ds 465/tcp closed smtps 587/tcp closed submission 2049/tcp open nfs MAC Address: 78:E3:B5:AD:F1:2F (Hewlett Packard) Nmap done: 1 IP address (1 host up) scanned in 7.30 seconds with server firewall down (192.168.1.2 -> 192.168.1.3) # nmap -F 192.168.1.3 Starting Nmap 7.70 ( https://nmap.org ) at 2019-04-02 23:17 EDT Nmap scan report for wahoo.wahoo.no-ip.org (192.168.1.3) Host is up (0.0020s latency). Not shown: 92 closed ports PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 80/tcp open http 111/tcp open rpcbind 139/tcp open netbios-ssn 445/tcp open microsoft-ds 2049/tcp open nfs 3306/tcp open mysql MAC Address: 78:E3:B5:AD:F1:2F (Hewlett Packard) Nmap done: 1 IP address (1 host up) scanned in 1.81 seconds tks, -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Carlos E. R.

09:38

On 03/04/2019 05.19, Patrick Shanahan wrote:

...

* Carlos E. R. <> [04-02-19 22:16]: [...]

...
So you are scanning your client, from your client. I don't think this gives any information.

Assuming that it is the server which blocks the connection, you have to scan the server from two client locations.

Or scan in both directions, client to server, then server to client. Using one working client and one faulty client.

server to workstation that fails (192.168.1.3 -> 192.168.1.10)

I translated all that to a calc sheet. Attached as csv (";" as separator). Don't complain, it is just 1K ;-) It seems to me that the fault is at the 192.168.1.3 firewall. From the 192.168.1.2 -> 192.168.1.3 case, some closed ports disappear when stopping the "3" firewall, and others appear as open. This is normal. I would look at the firewall definition files from any occurrence of 192.168.1.10, and /etc/hosts.deny (as Otto Rodusek i6 says). Another test is a traceroute: compare 192.168.1.2 -> 192.168.1.3 with 192.168.1.10 -> 192.168.1.3, with the server firewall down and up. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

Patrick Shanahan

13:07

* Carlos E. R. [04-03-19 05:41]:

...

On 03/04/2019 05.19, Patrick Shanahan wrote:

...
* Carlos E. R. <> [04-02-19 22:16]: [...]

...
So you are scanning your client, from your client. I don't think this gives any information.

Assuming that it is the server which blocks the connection, you have to scan the server from two client locations.

Or scan in both directions, client to server, then server to client. Using one working client and one faulty client.

server to workstation that fails (192.168.1.3 -> 192.168.1.10)

I translated all that to a calc sheet. Attached as csv (";" as separator). Don't complain, it is just 1K ;-)

...

It seems to me that the fault is at the 192.168.1.3 firewall.

that is what I think, but ... I made no firewall changes to the server and iptables -nL shows only ACCEPT for local addrs, 192.168.1.0/24

...

From the 192.168.1.2 -> 192.168.1.3 case, some closed ports disappear when stopping the "3" firewall, and others appear as open. This is normal.

I would look at the firewall definition files from any occurrence of 192.168.1.10, and /etc/hosts.deny (as Otto Rodusek i6 says).

no appearance of 192.168.1.10, grep -R 192.168.1.10 /etc/sysconfig/* and not in hosts.deny

...

Another test is a traceroute: compare 192.168.1.2 -> 192.168.1.3 with 192.168.1.10 -> 192.168.1.3, with the server firewall down and up.

from 192.168.1.2 -> 192.168.1.3 firewall active traceroute to 192.168.1.3 (192.168.1.3), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * from 192.168.1.2 -> 192.168.1.3 firewall inactive traceroute to 192.168.1.3 (192.168.1.3), 30 hops max, 60 byte packets 1 wahoo.wahoo.no-ip.org (192.168.1.3) 2.159 ms 2.125 ms 2.106 ms from 192.168.1.10 -> 192.168.1.3 firewall active traceroute 192.168.1.3 traceroute to 192.168.1.3 (192.168.1.3), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * from 192.168.1.10 -> 192.168.1.3 firewall inactive traceroute 192.168.1.3 traceroute to 192.168.1.3 (192.168.1.3), 30 hops max, 60 byte packets 1 wahoo.wahoo.no-ip.org (192.168.1.3) 0.581 ms 0.527 ms 0.499 ms -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Lew Wolfgang

14:03

On 04/03/2019 06:07 AM, Patrick Shanahan wrote:

...

traceroute to 192.168.1.3 (192.168.1.3), 30 hops max, 60 byte packets 1 wahoo.wahoo.no-ip.org (192.168.1.3) 2.159 ms 2.125 ms 2.106 ms

from 192.168.1.10 -> 192.168.1.3 firewall active

traceroute 192.168.1.3 traceroute to 192.168.1.3 (192.168.1.3), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * *

from 192.168.1.10 -> 192.168.1.3 firewall inactive

traceroute 192.168.1.3 traceroute to 192.168.1.3 (192.168.1.3), 30 hops max, 60 byte packets 1 wahoo.wahoo.no-ip.org (192.168.1.3) 0.581 ms 0.527 ms 0.499 ms

Wow, interesting! Have you looked at /var/log/messages for any strangeness? Have you tried running "arp" on 192.168.1.3 and 192.168.1.10? If something is funky with the firewall on 192.168.1.3, maybe it can't be trusted to log denys? Maybe run tcpdump on 192.168.1.3? "tcpdump host 192.168.1.10" Then, from 10 try pinging 3 with the firewall on and off. Maybe try "telnet 192.168.1.3 22" to watch the tcp session being established. Or not. Regards, Lew -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Patrick Shanahan

14:48

* Lew Wolfgang [04-03-19 10:11]:

...

On 04/03/2019 06:07 AM, Patrick Shanahan wrote:

...
traceroute to 192.168.1.3 (192.168.1.3), 30 hops max, 60 byte packets [...] traceroute 192.168.1.3 traceroute to 192.168.1.3 (192.168.1.3), 30 hops max, 60 byte packets 1 wahoo.wahoo.no-ip.org (192.168.1.3) 0.581 ms 0.527 ms 0.499 ms

Wow, interesting!

Have you looked at /var/log/messages for any strangeness?

server uses rsyslog only: nfs: server 192.168.1.10 not responding, timed out from server(192.168.1.3) workstation(192.168.1.10) users journalctl which I do not know but journalctl |grep 192.168.1.3 yields no output.

...

Have you tried running "arp" on 192.168.1.3 and 192.168.1.10?

from server (192.168.1.3) arp Address HWtype HWaddress Flags Mask Iface 192.168.1.254 ether dc:7f:a4:21:cd:8d C eth0 Carolyn.wahoo.no-ip.org ether 5c:5f:67:45:14:1f C eth0 crash2.wahoo.no-ip.org ether 00:0f:b5:f9:f9:c3 C eth0 toshiba.wahoo.no-ip.org ether 1a:c8:5e:60:15:d9 C eth0 Crash.wahoo.no-ip.org ether 70:71:bc:e9:03:c0 C eth0 from workstation (192.168.1.10) arp Address HWtype HWaddress Flags Mask Iface wahoo.wahoo.no-ip.org ether 78:e3:b5:ad:f1:2f C enp0s25 toshiba.wahoo.no-ip.org ether 1a:c8:5e:60:15:d9 C enp0s25 192.168.1.78 ether 00:6b:9e:1e:b3:e4 C enp0s25 crash2.wahoo.no-ip.org ether 00:0f:b5:f9:f9:c3 C enp0s25 Carolyn.wahoo.no-ip.org ether 5c:5f:67:45:14:1f C enp0s25 192.168.1.254 ether dc:7f:a4:21:cd:8d C enp0s25 192.168.1.75 ether 60:f1:89:5b:30:9b C enp0s25 192.168.1.83 ether 8c:45:00:21:9c:ce C enp0s25

...

If something is funky with the firewall on 192.168.1.3, maybe it can't be trusted to log denys?

Maybe run tcpdump on 192.168.1.3? "tcpdump host 192.168.1.10"

tcpdump host 192.168.1.10 > /tmp/mutt.txt tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes ^C102 packets captured 103 packets received by filter 0 packets dropped by kernel output rather large, see here: http://wahoo.no-ip.org/~paka/tcpdump.192.168.1.10.txt

...

Then, from 10 try pinging 3 with the firewall on and off.

fails with server firewall on, succeeds with server firewall off

...

Maybe try "telnet 192.168.1.3 22" to watch the tcp session being established. Or not.

fails with server firewall on, no output, blank with server firewall off: telnet -n telnet.txt 192.168.1.3 22 Trying 192.168.1.3... Connected to 192.168.1.3. Escape character is '^]'. SSH-2.0-OpenSSH_7.2 note: I hadn't tried before but I can ssh to the server using the external network addr, 108.246.209.12 tks, -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Patrick Shanahan

16:23

* Patrick Shanahan [04-03-19 10:51]: rebooted to a live cd and was able to access 192.168.1.3 server but problem workstation local address was not 192.168.1.10 but 192.168.1.83. if that clears the waters some ??? -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Lew Wolfgang

16:43

On 4/3/19 9:23 AM, Patrick Shanahan wrote:

...

* Patrick Shanahan [04-03-19 10:51]:

rebooted to a live cd and was able to access 192.168.1.3 server but problem workstation local address was not 192.168.1.10 but 192.168.1.83.

if that clears the waters some ???

Why don't you try changing the problem workstation's IP address manually to something other than 192.168.1.10? Regards, Lew -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Patrick Shanahan

18:58

* Lew Wolfgang [04-03-19 12:44]:

...

On 4/3/19 9:23 AM, Patrick Shanahan wrote:

...
* Patrick Shanahan [04-03-19 10:51]:

rebooted to a live cd and was able to access 192.168.1.3 server but problem workstation local address was not 192.168.1.10 but 192.168.1.83.

if that clears the waters some ???

Why don't you try changing the problem workstation's IP address manually to something other than 192.168.1.10?

I did that based on the above and it does work, but causes many other problems with nis and cifs and sshfs :(. temporary solution. tks, -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Carlos E. R.

19:03

On 03/04/2019 20.58, Patrick Shanahan wrote:

...

* Lew Wolfgang <> [04-03-19 12:44]:

...
On 4/3/19 9:23 AM, Patrick Shanahan wrote:

...
* Patrick Shanahan <> [04-03-19 10:51]:

rebooted to a live cd and was able to access 192.168.1.3 server but problem workstation local address was not 192.168.1.10 but 192.168.1.83.

if that clears the waters some ???

Why don't you try changing the problem workstation's IP address manually to something other than 192.168.1.10?

I did that based on the above and it does work, but causes many other problems with nis and cifs and sshfs :(. temporary solution.

Instead of changing, add another IP to the server machine or the client. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

Carlos E. R.

18:54

On 03/04/2019 15.07, Patrick Shanahan wrote:

...

* Carlos E. R. <> [04-03-19 05:41]:

...

...
Another test is a traceroute: compare 192.168.1.2 -> 192.168.1.3 with 192.168.1.10 -> 192.168.1.3, with the server firewall down and up.

from 192.168.1.2 -> 192.168.1.3 firewall active

traceroute to 192.168.1.3 (192.168.1.3), 30 hops max, 60 byte packets 1 * * * 2 * * *

Hum. I forgot to mention that you have to tell traceroute to use one of the open ports in the firewall: traceroute -p 22 -T 192.168.1.3 But I suspect it will make no difference. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

Lew Wolfgang

03:10

On 04/02/2019 06:24 PM, Patrick Shanahan wrote:

...

...
Oh, are you running ipv6? it is enabled but not knowing enough about ipv6, I use ipv4 for internal net commands.

I mentioned ipv6 because I've seen rogue router announcements siphon off traffic to bit-buckets. For example, users used to be able to turn on Internet Connection Services (ICS) on Windows boxes, which allowed the boxes to advertise themselves as v6 routers. But the packets would just disappear. This manifested itself as failed ssh connections. ssh tries v6 addresses first, falling back to v4 if the server rejects the v6. But the rejects would never return with a bogus router on the subnet. In this case, "ssh -4 hostname" would work. I don't think this is your problem though.

...

...
Of course, things become more complicated if Windows are involved. All the machines are running Linux, right? there are windows machines on the net but not involved. afaics the*only* difficulty is between workstation 192.168.1.10 and the server 192.168.1.3 and stopping the server firewall allows ssh from workstation to succeed.

So try an nmap from client to the server, once with the server's firewall on, and once with it off. If nmap shows port 22 open with the firewall on, but "telnet 192.168.1.10 22" fails, then you've got a really interesting problem! You might also try "ssh -v 192.168.1.10" and see if you can find where it's failing. You could try this both from a working client, and the bad one. Could the server's firewall, which apparently has multiple Ethernet ports, be forwarding traffic off-network? Maybe just return packets? Some kind of a loop? What does "ip addr" and "ip route" have to say? When all else fails, maybe it's time to break out tcpdump or wireshark to see exactly what's coming and going. Carlos also has a point about the wahoo.no-ip.org name resolution. What does your /etc/resolv.conf look like? And /etc/hosts? Regards, Lew -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Patrick Shanahan

03:30

* Lew Wolfgang [04-02-19 23:11]:

...

On 04/02/2019 06:24 PM, Patrick Shanahan wrote:

...
...
Oh, are you running ipv6? it is enabled but not knowing enough about ipv6, I use ipv4 for internal net commands.

I mentioned ipv6 because I've seen rogue router announcements siphon off traffic to bit-buckets. For example, users used to be able to turn on Internet Connection Services (ICS) on Windows boxes, which allowed the boxes to advertise themselves as v6 routers. But the packets would just disappear. This manifested itself as failed ssh connections. ssh tries v6 addresses first, falling back to v4 if the server rejects the v6. But the rejects would never return with a bogus router on the subnet. In this case, "ssh -4 hostname" would work. I don't think this is your problem though.

with server firewall up, ssh -4 from server to workstation and reverse both fail.

...

...
...
Of course, things become more complicated if Windows are involved. All the machines are running Linux, right? there are windows machines on the net but not involved. afaics the*only* difficulty is between workstation 192.168.1.10 and the server 192.168.1.3 and stopping the server firewall allows ssh from workstation to succeed.

So try an nmap from client to the server, once with the server's firewall on, and once with it off. If nmap shows port 22 open with the firewall on, but "telnet 192.168.1.10 22" fails, then you've got a really interesting problem! You might also try "ssh -v 192.168.1.10" and see if you can find where it's failing. You could try this both from a working client, and the bad one.

see other mail

...

Could the server's firewall, which apparently has multiple Ethernet ports, be forwarding traffic off-network? Maybe just return packets? Some kind of a loop? What does "ip addr" and "ip route" have to say?

# ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 78:e3:b5:ad:f1:2f brd ff:ff:ff:ff:ff:ff inet 192.168.1.3/24 brd 192.168.1.255 scope global eth0 valid_lft forever preferred_lft forever inet6 2600:1702:1031:3f90:7ae3:b5ff:fead:f12f/64 scope global mngtmpaddr dynamic valid_lft 3320sec preferred_lft 3320sec inet6 fe80::7ae3:b5ff:fead:f12f/64 scope link valid_lft forever preferred_lft forever 3: wlan0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 74:de:2b:df:0e:c9 brd ff:ff:ff:ff:ff:ff # ip route default via 192.168.1.254 dev eth0 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.3

...

When all else fails, maybe it's time to break out tcpdump or wireshark to see exactly what's coming and going.

Carlos also has a point about the wahoo.no-ip.org name resolution. What does your /etc/resolv.conf look like? And /etc/hosts?

### /etc/resolv.conf file autogenerated by netconfig! # # Before you change this file manually, consider to define the # static DNS configuration using the following variables in the # /etc/sysconfig/network/config file: # NETCONFIG_DNS_STATIC_SEARCHLIST # NETCONFIG_DNS_STATIC_SERVERS # NETCONFIG_DNS_FORWARDER # or disable DNS configuration updates via netconfig by setting: # NETCONFIG_DNS_POLICY='' # # See also the netconfig(8) manual page and other documentation. # # Note: Manual change of this file disables netconfig too, but # may get lost when this file contains comments or empty lines # only, the netconfig settings are same with settings in this # file and in case of a "netconfig update -f" call. # ### Please remove (at least) this line when you modify the file! search attlocal.net wahoo.no-ip.org nameserver 156.154.70.1 nameserver 8.8.4.4 nameserver 64.94.33.33 # # hosts This file describes a number of hostname-to-address # mappings for the TCP/IP subsystem. It is mostly # used at boot time, when no name servers are running. # On small systems, this file can be used instead of a # "named" name server. # Syntax: # # IP-Address Full-Qualified-Hostname Short-Hostname # 127.0.0.1 localhost # special IPv6 addresses ::1 localhost ipv6-localhost ipv6-loopback fe00::0 ipv6-localnet ff00::0 ipv6-mcastprefix ff02::1 ipv6-allnodes ff02::2 ipv6-allrouters ff02::3 ipv6-allhosts 108.246.209.12 wahoo.no-ip.org paka 192.168.1.3 wahoo.wahoo.no-ip.org wahoo 192.168.1.2 toshiba.wahoo.no-ip.org toshiba 192.168.1.100 Carolyn.wahoo.no-ip.org Carolyn 192.168.1.101 acer.wahoo.no-ip.org acer 192.168.1.5 dell.wahoo.no-ip.org dell 192.168.1.8 crash2.wahoo.no-ip.org crash2 192.168.1.10 Crash.wahoo.no-ip.org Crash the current hosts/resolv.conf have work properly for years... tks, -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Carlos E. R.

09:59

On 03/04/2019 05.30, Patrick Shanahan wrote:

...

* Lew Wolfgang <> [04-02-19 23:11]:

...

...
Could the server's firewall, which apparently has multiple Ethernet ports, be forwarding traffic off-network? Maybe just return packets? Some kind of a loop? What does "ip addr" and "ip route" have to say?

# ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 78:e3:b5:ad:f1:2f brd ff:ff:ff:ff:ff:ff inet 192.168.1.3/24 brd 192.168.1.255 scope global eth0 valid_lft forever preferred_lft forever inet6 2600:1702:1031:3f90:7ae3:b5ff:fead:f12f/64 scope global mngtmpaddr dynamic valid_lft 3320sec preferred_lft 3320sec inet6 fe80::7ae3:b5ff:fead:f12f/64 scope link valid_lft forever preferred_lft forever 3: wlan0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 74:de:2b:df:0e:c9 brd ff:ff:ff:ff:ff:ff

You do have IPv6 addresses.

...

...
When all else fails, maybe it's time to break out tcpdump or wireshark to see exactly what's coming and going.

Carlos also has a point about the wahoo.no-ip.org name resolution. What does your /etc/resolv.conf look like? And /etc/hosts?

### /etc/resolv.conf file autogenerated by netconfig! # ... search attlocal.net wahoo.no-ip.org nameserver 156.154.70.1 nameserver 8.8.4.4 nameserver 64.94.33.33

...

108.246.209.12 wahoo.no-ip.org paka 192.168.1.3 wahoo.wahoo.no-ip.org wahoo 192.168.1.2 toshiba.wahoo.no-ip.org toshiba 192.168.1.100 Carolyn.wahoo.no-ip.org Carolyn 192.168.1.101 acer.wahoo.no-ip.org acer 192.168.1.5 dell.wahoo.no-ip.org dell 192.168.1.8 crash2.wahoo.no-ip.org crash2 192.168.1.10 Crash.wahoo.no-ip.org Crash

the current hosts/resolv.conf have work properly for years...

Yes, they work as intended, but... it doesn't look right to me. The thing is, you are using internally machine names with an "external" name. IMO, the correct thing would be something like: 192.168.1.3 wahoo.wahoo wahoo 192.168.1.2 toshiba.wahoo toshiba 192.168.1.100 Carolyn.wahoo Carolyn 192.168.1.101 acer.wahoo acer 192.168.1.5 dell.wahoo dell 192.168.1.8 crash2.wahoo crash2 192.168.1.10 Crash.wahoo Crash That is, the names *.wahoo.no-ip.org would resolve (or not) externally, while the names *.wahoo would resolve internally. The way you have it, it is possible that a query to wahoo.wahoo.no-ip.org or Crash.wahoo.no-ip.org would be asked at an external domain name server (with empty answer): cer@Telcontar:~/tmp/patrick> host wahoo.wahoo.no-ip.org cer@Telcontar:~/tmp/patrick> -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

Patrick Shanahan

11:59

* Carlos E. R. [04-03-19 06:00]:

...

On 03/04/2019 05.30, Patrick Shanahan wrote:

...
* Lew Wolfgang <> [04-02-19 23:11]:

...

...
...
Could the server's firewall, which apparently has multiple Ethernet ports, be forwarding traffic off-network? Maybe just return packets? Some kind of a loop? What does "ip addr" and "ip route" have to say?

# ip addr 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 78:e3:b5:ad:f1:2f brd ff:ff:ff:ff:ff:ff inet 192.168.1.3/24 brd 192.168.1.255 scope global eth0 valid_lft forever preferred_lft forever inet6 2600:1702:1031:3f90:7ae3:b5ff:fead:f12f/64 scope global mngtmpaddr dynamic valid_lft 3320sec preferred_lft 3320sec inet6 fe80::7ae3:b5ff:fead:f12f/64 scope link valid_lft forever preferred_lft forever 3: wlan0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 74:de:2b:df:0e:c9 brd ff:ff:ff:ff:ff:ff

You do have IPv6 addresses.

...
...
When all else fails, maybe it's time to break out tcpdump or wireshark to see exactly what's coming and going.

Carlos also has a point about the wahoo.no-ip.org name resolution. What does your /etc/resolv.conf look like? And /etc/hosts?

### /etc/resolv.conf file autogenerated by netconfig! # ... search attlocal.net wahoo.no-ip.org nameserver 156.154.70.1 nameserver 8.8.4.4 nameserver 64.94.33.33

...

...
108.246.209.12 wahoo.no-ip.org paka 192.168.1.3 wahoo.wahoo.no-ip.org wahoo 192.168.1.2 toshiba.wahoo.no-ip.org toshiba 192.168.1.100 Carolyn.wahoo.no-ip.org Carolyn 192.168.1.101 acer.wahoo.no-ip.org acer 192.168.1.5 dell.wahoo.no-ip.org dell 192.168.1.8 crash2.wahoo.no-ip.org crash2 192.168.1.10 Crash.wahoo.no-ip.org Crash

the current hosts/resolv.conf have work properly for years...

Yes, they work as intended, but... it doesn't look right to me.

The thing is, you are using internally machine names with an "external" name. IMO, the correct thing would be something like:

192.168.1.3 wahoo.wahoo wahoo 192.168.1.2 toshiba.wahoo toshiba 192.168.1.100 Carolyn.wahoo Carolyn 192.168.1.101 acer.wahoo acer 192.168.1.5 dell.wahoo dell 192.168.1.8 crash2.wahoo crash2 192.168.1.10 Crash.wahoo Crash

That is, the names *.wahoo.no-ip.org would resolve (or not) externally, while the names *.wahoo would resolve internally.

The way you have it, it is possible that a query to wahoo.wahoo.no-ip.org or Crash.wahoo.no-ip.org would be asked at an external domain name server (with empty answer):

changed /etc/hosts as you suggested.

...

cer@Telcontar:~/tmp/patrick> host wahoo.wahoo.no-ip.org cer@Telcontar:~/tmp/patrick>

# host wahoo.no-ip.org wahoo.no-ip.org has address 108.246.209.12 wahoo.no-ip.org mail is handled by 5 wahoo.no-ip.org. wahoo.no-ip.org mail is handled by 10 wahoo.no-ip.org. wahoo.no-ip.org mail is handled by 15 wahoo.ddns.net. # host wahoo.wahoo.no-ip.org # host crash.wahoo.no-ip.org # host crash2.wahoo.no-ip.org # host wahoo # host wahoo.wahoo Host wahoo.wahoo not found: 3(NXDOMAIN) # host crash # host crash.wahoo Host crash.wahoo not found: 3(NXDOMAIN) same results and ping resolves correctly but fails between server, wahoo, to workstation, crash, and crash to wahoo from crash to toshiba and crash2 ping works from wahoo to toshiba and crash2 ping works names are resolved correctly -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Carlos E. R.

18:58

On 03/04/2019 13.59, Patrick Shanahan wrote:

...

* Carlos E. R. <...> [04-03-19 06:00]:

...
On 03/04/2019 05.30, Patrick Shanahan wrote:

...

...
...
the current hosts/resolv.conf have work properly for years...

Yes, they work as intended, but... it doesn't look right to me.

The thing is, you are using internally machine names with an "external" name. IMO, the correct thing would be something like:

192.168.1.3 wahoo.wahoo wahoo 192.168.1.2 toshiba.wahoo toshiba 192.168.1.100 Carolyn.wahoo Carolyn 192.168.1.101 acer.wahoo acer 192.168.1.5 dell.wahoo dell 192.168.1.8 crash2.wahoo crash2 192.168.1.10 Crash.wahoo Crash

That is, the names *.wahoo.no-ip.org would resolve (or not) externally, while the names *.wahoo would resolve internally.

The way you have it, it is possible that a query to wahoo.wahoo.no-ip.org or Crash.wahoo.no-ip.org would be asked at an external domain name server (with empty answer):

changed /etc/hosts as you suggested.

...
cer@Telcontar:~/tmp/patrick> host wahoo.wahoo.no-ip.org cer@Telcontar:~/tmp/patrick>

# host wahoo.no-ip.org wahoo.no-ip.org has address 108.246.209.12 wahoo.no-ip.org mail is handled by 5 wahoo.no-ip.org. wahoo.no-ip.org mail is handled by 10 wahoo.no-ip.org. wahoo.no-ip.org mail is handled by 15 wahoo.ddns.net. # host wahoo.wahoo.no-ip.org # host crash.wahoo.no-ip.org # host crash2.wahoo.no-ip.org # host wahoo # host wahoo.wahoo Host wahoo.wahoo not found: 3(NXDOMAIN) # host crash # host crash.wahoo Host crash.wahoo not found: 3(NXDOMAIN)

The command "host" ignores the /etc/hosts file. ping doesn't.

...

same results and ping resolves correctly but fails between server, wahoo, to workstation, crash, and crash to wahoo

from crash to toshiba and crash2 ping works from wahoo to toshiba and crash2 ping works names are resolved correctly

Now that I think. What are the routes at .3 and .10? -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

Patrick Shanahan

19:02

* Carlos E. R. [04-03-19 14:59]:

...

On 03/04/2019 13.59, Patrick Shanahan wrote:

...
* Carlos E. R. <...> [04-03-19 06:00]:

...
On 03/04/2019 05.30, Patrick Shanahan wrote:

...
...
...
the current hosts/resolv.conf have work properly for years...

Yes, they work as intended, but... it doesn't look right to me.

The thing is, you are using internally machine names with an "external" name. IMO, the correct thing would be something like:

192.168.1.3 wahoo.wahoo wahoo 192.168.1.2 toshiba.wahoo toshiba 192.168.1.100 Carolyn.wahoo Carolyn 192.168.1.101 acer.wahoo acer 192.168.1.5 dell.wahoo dell 192.168.1.8 crash2.wahoo crash2 192.168.1.10 Crash.wahoo Crash

That is, the names *.wahoo.no-ip.org would resolve (or not) externally, while the names *.wahoo would resolve internally.

The way you have it, it is possible that a query to wahoo.wahoo.no-ip.org or Crash.wahoo.no-ip.org would be asked at an external domain name server (with empty answer):

changed /etc/hosts as you suggested.

...
cer@Telcontar:~/tmp/patrick> host wahoo.wahoo.no-ip.org cer@Telcontar:~/tmp/patrick>

# host wahoo.no-ip.org wahoo.no-ip.org has address 108.246.209.12 wahoo.no-ip.org mail is handled by 5 wahoo.no-ip.org. wahoo.no-ip.org mail is handled by 10 wahoo.no-ip.org. wahoo.no-ip.org mail is handled by 15 wahoo.ddns.net. # host wahoo.wahoo.no-ip.org # host crash.wahoo.no-ip.org # host crash2.wahoo.no-ip.org # host wahoo # host wahoo.wahoo Host wahoo.wahoo not found: 3(NXDOMAIN) # host crash # host crash.wahoo Host crash.wahoo not found: 3(NXDOMAIN)

The command "host" ignores the /etc/hosts file. ping doesn't.

...
same results and ping resolves correctly but fails between server, wahoo, to workstation, crash, and crash to wahoo

from crash to toshiba and crash2 ping works from wahoo to toshiba and crash2 ping works names are resolved correctly

Now that I think. What are the routes at .3 and .10?

from 192.168.1.10: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.1.254 0.0.0.0 UG 0 0 0 enp0s25 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 enp0s25 from 192.168.1.3: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.1.254 0.0.0.0 UG 0 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 tks -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Carlos E. R.

19:05

On 03/04/2019 21.02, Patrick Shanahan wrote:

...

* Carlos E. R. <> [04-03-19 14:59]:

...
On 03/04/2019 13.59, Patrick Shanahan wrote:

...

...
Now that I think. What are the routes at .3 and .10?

from 192.168.1.10: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.1.254 0.0.0.0 UG 0 0 0 enp0s25 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 enp0s25

from 192.168.1.3: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.1.254 0.0.0.0 UG 0 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0

Absolutely normal... -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

tomas.kuchta.lists＠gmail.com

18:42

Are you by any chance using fail2ban or similar on the troubled computer? That might case something like this. Tomas On Tue, 2019-04-02 at 21:24 -0400, Patrick Shanahan wrote:

...

* Lew Wolfgang [04-02-19 19:22]:

...
On 04/02/2019 03:38 PM, Patrick Shanahan wrote:

...
* Patrick Shanahan [04-02-19 16:11]:

...
* Patrick Shanahan [04-02-19 16:06]:

...
my local server is running Leap 42.2 all local machines may connect to the server, except one, 192.168.1.10

192.168.1.10 is my main workstation and connected fine until 08:36am this morning local time -4 utc.

concerned interfaces are ssh, nfs and http

...
...
no software change nor noted system abnormality, except the open ssh windows on 192.168.1.10 froze, would not accept input. ping fails both ways.

stopping SuSEfirewall2 on the server allows connection and ping succeedes both ways server -> 192.168.1.10 and 192.168.1.10 -> server (192.168.1.3) of course I do not wish to run my server w/o a firewall, even though there is one within the router.

Time for some troubleshooting? 192.168.1.3 is the server, right? From your workstation, have you tried nmap to see what ports are open? Maybe try it with the server's firewall both on and off. You should see ports 22, 2049, 80, and maybe 111.

from server/192.168.1.3

# nmap -F 192.168.1.3

Starting Nmap 6.47 ( http://nmap.org ) at 2019-04-02 21:09 EDT Nmap scan report for wahoo.wahoo.no-ip.org (192.168.1.3) Host is up (0.000015s latency). Not shown: 92 closed ports PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 80/tcp open http 111/tcp open rpcbind 139/tcp open netbios-ssn 445/tcp open microsoft-ds 2049/tcp open nfs 3306/tcp open mysql

Nmap done: 1 IP address (1 host up) scanned in 1.55 seconds

# systemctl stop SuSEfirewall2

wahoo: ~ # nmap -F 192.168.1.3

Starting Nmap 6.47 ( http://nmap.org ) at 2019-04-02 21:09 EDT Nmap scan report for wahoo.wahoo.no-ip.org (192.168.1.3) Host is up (0.000020s latency). Not shown: 92 closed ports PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 80/tcp open http 111/tcp open rpcbind 139/tcp open netbios-ssn 445/tcp open microsoft-ds 2049/tcp open nfs 3306/tcp open mysql

Nmap done: 1 IP address (1 host up) scanned in 1.55 seconds

# systemctl start SuSEfirewall2

from workstation/192.168.1.10

# nmap -F 192.168.1.10 Starting Nmap 7.70 ( https://nmap.org ) at 2019-04-02 21:17 EDT Nmap scan report for crash.wahoo.no-ip.org (192.168.1.10) Host is up (0.000023s latency). Not shown: 96 closed ports PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 111/tcp open rpcbind 2049/tcp open nfs

Nmap done: 1 IP address (1 host up) scanned in 1.54 seconds

# systemctl stop firewalld

# nmap -F 192.168.1.10 Starting Nmap 7.70 ( https://nmap.org ) at 2019-04-02 21:17 EDT Nmap scan report for crash.wahoo.no-ip.org (192.168.1.10) Host is up (0.000011s latency). Not shown: 96 closed ports PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 111/tcp open rpcbind 2049/tcp open nfs

Nmap done: 1 IP address (1 host up) scanned in 1.59 seconds

# systemctl start firewalld

...
Then, if you can see the ports, maybe try telnet to see if you can establish a tcp connection and get a banner on port 22. As in "telnet 192.168.1.3 22".

from 192.168.1.10 to server 192.168.1.3 # telnet 192.168.1.3 22 Trying 192.168.1.3... telnet: connect to address 192.168.1.3: Connection timed out

from server to workstation (192.168.1.3 -> 192.168.1.10) # telnet 192.168.1.10 22 Trying 192.168.1.10... telnet: connect to address 192.168.1.10: Connection timed out

...
Oh, are you running ipv6?

it is enabled but not knowing enough about ipv6, I use ipv4 for internal net commands.

...
Of course, things become more complicated if Windows are involved. All the machines are running Linux, right?

there are windows machines on the net but not involved. afaics the *only* difficulty is between workstation 192.168.1.10 and the server 192.168.1.3 and stopping the server firewall allows ssh from workstation to succeed.

tks

-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounte r.net Photos: http://wahoo.no-ip.org/piwigo class="Apple-tab-span" style="white-space:pre"> paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Patrick Shanahan

18:57

* tomas.kuchta.lists@gmail.com [04-03-19 14:42]:

...

Are you by any chance using fail2ban or similar on the troubled computer? That might case something like this.

Tomas

On Tue, 2019-04-02 at 21:24 -0400, Patrick Shanahan wrote:

...
* Lew Wolfgang [04-02-19 19:22]:

...
On 04/02/2019 03:38 PM, Patrick Shanahan wrote:

...
* Patrick Shanahan [04-02-19 16:11]:

...
* Patrick Shanahan [04-02-19 16:06]:

...
my local server is running Leap 42.2 all local machines may connect to the server, except one, 192.168.1.10

192.168.1.10 is my main workstation and connected fine until 08:36am this morning local time -4 utc.

concerned interfaces are ssh, nfs and http

...
...
no software change nor noted system abnormality, except the open ssh windows on 192.168.1.10 froze, would not accept input. ping fails both ways.

stopping SuSEfirewall2 on the server allows connection and ping succeedes both ways server -> 192.168.1.10 and 192.168.1.10 -> server (192.168.1.3) of course I do not wish to run my server w/o a firewall, even though there is one within the router.

Time for some troubleshooting? 192.168.1.3 is the server, right? From your workstation, have you tried nmap to see what ports are open? Maybe try it with the server's firewall both on and off. You should see ports 22, 2049, 80, and maybe 111.

from server/192.168.1.3

# nmap -F 192.168.1.3

Starting Nmap 6.47 ( http://nmap.org ) at 2019-04-02 21:09 EDT Nmap scan report for wahoo.wahoo.no-ip.org (192.168.1.3) Host is up (0.000015s latency). Not shown: 92 closed ports PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 80/tcp open http 111/tcp open rpcbind 139/tcp open netbios-ssn 445/tcp open microsoft-ds 2049/tcp open nfs 3306/tcp open mysql

Nmap done: 1 IP address (1 host up) scanned in 1.55 seconds

# systemctl stop SuSEfirewall2

wahoo: ~ # nmap -F 192.168.1.3

Starting Nmap 6.47 ( http://nmap.org ) at 2019-04-02 21:09 EDT Nmap scan report for wahoo.wahoo.no-ip.org (192.168.1.3) Host is up (0.000020s latency). Not shown: 92 closed ports PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 80/tcp open http 111/tcp open rpcbind 139/tcp open netbios-ssn 445/tcp open microsoft-ds 2049/tcp open nfs 3306/tcp open mysql

Nmap done: 1 IP address (1 host up) scanned in 1.55 seconds

# systemctl start SuSEfirewall2

from workstation/192.168.1.10

# nmap -F 192.168.1.10 Starting Nmap 7.70 ( https://nmap.org ) at 2019-04-02 21:17 EDT Nmap scan report for crash.wahoo.no-ip.org (192.168.1.10) Host is up (0.000023s latency). Not shown: 96 closed ports PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 111/tcp open rpcbind 2049/tcp open nfs

Nmap done: 1 IP address (1 host up) scanned in 1.54 seconds

# systemctl stop firewalld

# nmap -F 192.168.1.10 Starting Nmap 7.70 ( https://nmap.org ) at 2019-04-02 21:17 EDT Nmap scan report for crash.wahoo.no-ip.org (192.168.1.10) Host is up (0.000011s latency). Not shown: 96 closed ports PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 111/tcp open rpcbind 2049/tcp open nfs

Nmap done: 1 IP address (1 host up) scanned in 1.59 seconds

# systemctl start firewalld

...
Then, if you can see the ports, maybe try telnet to see if you can establish a tcp connection and get a banner on port 22. As in "telnet 192.168.1.3 22".

from 192.168.1.10 to server 192.168.1.3 # telnet 192.168.1.3 22 Trying 192.168.1.3... telnet: connect to address 192.168.1.3: Connection timed out

from server to workstation (192.168.1.3 -> 192.168.1.10) # telnet 192.168.1.10 22 Trying 192.168.1.10... telnet: connect to address 192.168.1.10: Connection timed out

...
Oh, are you running ipv6?

it is enabled but not knowing enough about ipv6, I use ipv4 for internal net commands.

...
Of course, things become more complicated if Windows are involved. All the machines are running Linux, right?

there are windows machines on the net but not involved. afaics the *only* difficulty is between workstation 192.168.1.10 and the server 192.168.1.3 and stopping the server firewall allows ssh from workstation to succeed.

tks

-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounte r.net Photos: http://wahoo.no-ip.org/piwigo class="Apple-tab-span" style="white-space:pre"> paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

yes I am, but it is not being stopped by fail2ban. I have disabled fail2ban and still have same problem and the ip is not in /etc/hosts.deny nor being banned by the firewall as far as I can determine. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Carlos E. R.

19:00

On 03/04/2019 20.57, Patrick Shanahan wrote:

...

* tomas.kuchta.lists@gmail.com [04-03-19 14:42]:

...
Are you by any chance using fail2ban or similar on the troubled computer? That might case something like this.

Tomas

...

yes I am, but it is not being stopped by fail2ban. I have disabled fail2ban and still have same problem and the ip is not in /etc/hosts.deny nor being banned by the firewall as far as I can determine.

How does fail2ban work, what does it change? -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

Patrick Shanahan

19:15

* Carlos E. R. [04-03-19 15:01]:

...

On 03/04/2019 20.57, Patrick Shanahan wrote:

...
* tomas.kuchta.lists@gmail.com [04-03-19 14:42]:

...
Are you by any chance using fail2ban or similar on the troubled computer? That might case something like this.

Tomas

...
yes I am, but it is not being stopped by fail2ban. I have disabled fail2ban and still have same problem and the ip is not in /etc/hosts.deny nor being banned by the firewall as far as I can determine.

How does fail2ban work, what does it change?

it counts access attempts over a period of time and issues firewall bans for a limited time to violators, depending on your configuration. I have used it for quite some years. used denyhosts also for a while, but one is enough. anyway, fail2ban or the firewall denying access would only work going to the server, not the other way, and would leave a trail in the logs, which do not appear. tks -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

tomas.kuchta.lists＠gmail.com

22:14

just in case ... fail2ban logs to /var/log/fail2ban.log You would not see it in /etc/hosts.deny -Tomas On Wed, 2019-04-03 at 15:15 -0400, Patrick Shanahan wrote:

...

* Carlos E. R. [04-03-19 15:01]:

...
On 03/04/2019 20.57, Patrick Shanahan wrote:

...
* tomas.kuchta.lists@gmail.com [04-03-19 14:42]:

...
Are you by any chance using fail2ban or similar on the troubled computer? That might case something like this.

Tomas

...
yes I am, but it is not being stopped by fail2ban. I have disabled fail2ban and still have same problem and the ip is not in /etc/hosts.deny nor being banned by the firewall as far as I can determine.

How does fail2ban work, what does it change?

it counts access attempts over a period of time and issues firewall bans for a limited time to violators, depending on your configuration. I have used it for quite some years. used denyhosts also for a while, but one is enough.

anyway, fail2ban or the firewall denying access would only work going to the server, not the other way, and would leave a trail in the logs, which do not appear.

tks -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounte r.net Photos: http://wahoo.no-ip.org/piwigo class="Apple-tab-span" style="white-space:pre"> paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Patrick Shanahan

23:38

* tomas.kuchta.lists@gmail.com [04-03-19 18:17]:

...

just in case ...

fail2ban logs to /var/log/fail2ban.log You would not see it in /etc/hosts.deny

-Tomas

On Wed, 2019-04-03 at 15:15 -0400, Patrick Shanahan wrote:

...
* Carlos E. R. [04-03-19 15:01]:

...
On 03/04/2019 20.57, Patrick Shanahan wrote:

...
* tomas.kuchta.lists@gmail.com [04-03-19 14:42]:

...
Are you by any chance using fail2ban or similar on the troubled computer? That might case something like this.

Tomas

...
yes I am, but it is not being stopped by fail2ban. I have disabled fail2ban and still have same problem and the ip is not in /etc/hosts.deny nor being banned by the firewall as far as I can determine.

How does fail2ban work, what does it change?

it counts access attempts over a period of time and issues firewall bans for a limited time to violators, depending on your configuration. I have used it for quite some years. used denyhosts also for a while, but one is enough.

anyway, fail2ban or the firewall denying access would only work going to the server, not the other way, and would leave a trail in the logs, which do not appear.

tks

yes, it is not there. tks -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Patrick Shanahan

23:44

New subject: [opensuse-support] FIXED but not solved: ??firewall?? problem

* Patrick Shanahan [04-03-19 19:41]: changed ip of workstation. tired of hunting. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Carlos E. R.

02:04

On 02/04/2019 22.05, Patrick Shanahan wrote:

...

my local server is running Leap 42.2 all local machines may connect to the server, except one, 192.168.1.10

192.168.1.10 is my main workstation and connected fine until 08:36am this morning local time -4 utc.

no software change nor noted system abnormality, except the open ssh windows on 192.168.1.10 froze, would not accept input. ping fails both ways.

stopping SuSEfirewall2 on the server allows connection and ping succeedes both ways server -> 192.168.1.10 and 192.168.1.10 -> server (192.168.1.3) of course I do not wish to run my server w/o a firewall, even though there is one within the router.

Which machine reports in the firewall log blocking packages? The server? And it only affects connections from 192.168.1.10, not from others? How strange. Did you try to restart the affected firewalls? Or restart the network? -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

Patrick Shanahan

03:40

* Carlos E. R. [04-02-19 22:05]:

...

On 02/04/2019 22.05, Patrick Shanahan wrote:

...
my local server is running Leap 42.2 all local machines may connect to the server, except one, 192.168.1.10

192.168.1.10 is my main workstation and connected fine until 08:36am this morning local time -4 utc.

no software change nor noted system abnormality, except the open ssh windows on 192.168.1.10 froze, would not accept input. ping fails both ways.

stopping SuSEfirewall2 on the server allows connection and ping succeedes both ways server -> 192.168.1.10 and 192.168.1.10 -> server (192.168.1.3) of course I do not wish to run my server w/o a firewall, even though there is one within the router.

Which machine reports in the firewall log blocking packages? The server?

there is no firewall log entry for attempted or denied access from 192.168.1.10 workstation to the 192.168.1.3 server

...

And it only affects connections from 192.168.1.10, not from others? How strange.

very strange

...

Did you try to restart the affected firewalls?

stopped and restarted multiple times. access from 192.168.1.10 to 192.168.1.3 works if the firewall is stopped on 192.168.1.3. no other combination works. ALL other machines on the network which are allowed access to the server still work as expected. the ONLY connection problem is 192.168.1.10 -> 192.168.1.3 and the reverse 192.168.1.3 -> 192.168.1.10.

...

Or restart the network?

multiple times. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Otto Rodusek i6

04:41

Hi, Did you check server /etc/hosts.deny? Grep for 192.168.1.10 in firewall scripts? Good luck! Sent from my iPhoneXsMax with IOS 12.2 (16E227).

...

On 3 Apr 2019, at 11:40, Patrick Shanahan wrote:

* Carlos E. R. [04-02-19 22:05]:

...
...
On 02/04/2019 22.05, Patrick Shanahan wrote:

my local server is running Leap 42.2 all local machines may connect to the server, except one, 192.168.1.10

192.168.1.10 is my main workstation and connected fine until 08:36am this morning local time -4 utc.

no software change nor noted system abnormality, except the open ssh windows on 192.168.1.10 froze, would not accept input. ping fails both ways.

stopping SuSEfirewall2 on the server allows connection and ping succeedes both ways server -> 192.168.1.10 and 192.168.1.10 -> server (192.168.1.3) of course I do not wish to run my server w/o a firewall, even though there is one within the router.

Which machine reports in the firewall log blocking packages? The server?

there is no firewall log entry for attempted or denied access from 192.168.1.10 workstation to the 192.168.1.3 server

...
And it only affects connections from 192.168.1.10, not from others? How strange.

very strange

...
Did you try to restart the affected firewalls?

stopped and restarted multiple times. access from 192.168.1.10 to 192.168.1.3 works if the firewall is stopped on 192.168.1.3. no other combination works. ALL other machines on the network which are allowed access to the server still work as expected. the ONLY connection problem is 192.168.1.10 -> 192.168.1.3 and the reverse 192.168.1.3 -> 192.168.1.10.

...
Or restart the network?

multiple times.

-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

-- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Patrick Shanahan

11:49

* Otto Rodusek i6 [04-03-19 00:43]:

...

Hi,

Did you check server /etc/hosts.deny? Grep for 192.168.1.10 in firewall scripts?

Good luck!

yes, and it is not there. and tried with fail2ban stopped. no connection. tks, -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Carlos E. R.

09:42

On 03/04/2019 05.40, Patrick Shanahan wrote:

...

* Carlos E. R. <> [04-02-19 22:05]:

...

...
Which machine reports in the firewall log blocking packages? The server?

there is no firewall log entry for attempted or denied access from 192.168.1.10 workstation to the 192.168.1.3 server

Unless you have disabled the logs, that would indicate that the packets do not reach the machine.

...

...
And it only affects connections from 192.168.1.10, not from others? How strange.

very strange

...
Did you try to restart the affected firewalls?

stopped and restarted multiple times. access from 192.168.1.10 to 192.168.1.3 works if the firewall is stopped on 192.168.1.3. no other combination works. ALL other machines on the network which are allowed access to the server still work as expected. the ONLY connection problem is 192.168.1.10 -> 192.168.1.3 and the reverse 192.168.1.3 -> 192.168.1.10.

The nmap 192.168.1.3 -> 192.168.1.10 do not indicate a problem.

...

...
Or restart the network?

multiple times.

-- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)

Patrick Shanahan

12:16

* Carlos E. R. [04-03-19 05:44]:

...

On 03/04/2019 05.40, Patrick Shanahan wrote:

...
* Carlos E. R. <> [04-02-19 22:05]:

...
...
Which machine reports in the firewall log blocking packages? The server?

there is no firewall log entry for attempted or denied access from 192.168.1.10 workstation to the 192.168.1.3 server

Unless you have disabled the logs, that would indicate that the packets do not reach the machine.

they are not disabled but 192.168.1.3 shows no records from 192.168.1.10 since ~08:30 yesterday when they would not longer communicate.

...

...
...
And it only affects connections from 192.168.1.10, not from others? How strange.

very strange

...
Did you try to restart the affected firewalls?

stopped and restarted multiple times. access from 192.168.1.10 to 192.168.1.3 works if the firewall is stopped on 192.168.1.3. no other combination works. ALL other machines on the network which are allowed access to the server still work as expected. the ONLY connection problem is 192.168.1.10 -> 192.168.1.3 and the reverse 192.168.1.3 -> 192.168.1.10.

The nmap 192.168.1.3 -> 192.168.1.10 do not indicate a problem.

...
...
Or restart the network?

multiple times.

tks, -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

1848

Age (days ago)

1849

Last active (days ago)

List overview

Download

36 comments

5 participants

participants (5)

Carlos E. R.
Lew Wolfgang
Otto Rodusek i6
Patrick Shanahan
tomas.kuchta.lists＠gmail.com

[opensuse-support] ??firewall?? problem

tags

participants (5)