Score:0

Apache Server not accessible from internet after work on Samba

br flag

on Ubuntu 20.04.3 I have an owncloud installation. It was accessible through ssl (with an IP address from no-ip) and everything work very well.

A few days ago I worked on samba (which was also working fine) to see if I could make Apple Time Machine work. This did not work. What is worse: The Apache Server is not accessible from the internet anymore.

Depending on the browser the error message is something like "cannot connect to the server" or "ERR_ADDRESS_UNREACHABLE".

The settings in my router (Fritz.box 7490) seem to be fine.

Apache is running:

fambopp@fambopp-MacBookAir:~$ sudo systemctl status apache2
● apache2.service - The Apache HTTP Server
     Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2021-12-14 06:35:00 CET; 30min ago
       Docs: https://httpd.apache.org/docs/2.4/
    Process: 3993 ExecStart=/usr/sbin/apachectl start (code=exited, status=0/SUCCESS)
    Process: 5017 ExecReload=/usr/sbin/apachectl graceful (code=exited, status=0/SUCCESS)
   Main PID: 3997 (apache2)
      Tasks: 6 (limit: 4531)
     Memory: 15.5M
     CGroup: /system.slice/apache2.service
             ├─3997 /usr/sbin/apache2 -k start
             ├─5021 /usr/sbin/apache2 -k start
             ├─5022 /usr/sbin/apache2 -k start
             ├─5023 /usr/sbin/apache2 -k start
             ├─5024 /usr/sbin/apache2 -k start
             └─5025 /usr/sbin/apache2 -k start

Dez 14 06:35:00 fambopp-MacBookAir systemd[1]: Starting The Apache HTTP Server...
Dez 14 06:35:00 fambopp-MacBookAir systemd[1]: Started The Apache HTTP Server.
Dez 14 07:05:04 fambopp-MacBookAir systemd[1]: Reloading The Apache HTTP Server.
Dez 14 07:05:04 fambopp-MacBookAir systemd[1]: Reloaded The Apache HTTP Server. 

I checked with nmap and cannot see any problems:

Starting Nmap 7.80 ( https://nmap.org ) at 2021-12-14 07:33 CET
Nmap scan report for fambopp-MacBookAir.fritz.box (192.168.10.194)
Host is up (0.000010s latency).
Not shown: 994 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
139/tcp  open  netbios-ssn
443/tcp  open  https
445/tcp  open  microsoft-ds
5900/tcp open  vnc

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

I had no ufw active. So I activated it and allowed everything:

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere                  
80,443/tcp (Apache Full)   ALLOW IN    Anywhere                  
137,138/udp (Samba)        ALLOW IN    Anywhere                  
139,445/tcp (Samba)        ALLOW IN    Anywhere                  
5900/tcp                   ALLOW IN    Anywhere                  
22/tcp (v6)                ALLOW IN    Anywhere (v6)             
80,443/tcp (Apache Full (v6)) ALLOW IN    Anywhere (v6)             
137,138/udp (Samba (v6))   ALLOW IN    Anywhere (v6)             
139,445/tcp (Samba (v6))   ALLOW IN    Anywhere (v6)             
5900/tcp (v6)              ALLOW IN    Anywhere (v6)

I can ping the page successfully:

PING 93.104.185.180 (93.104.185.180) 56(84) bytes of data.
64 bytes from 93.104.185.180: icmp_seq=1 ttl=63 time=0.606 ms
64 bytes from 93.104.185.180: icmp_seq=2 ttl=63 time=0.613 ms
64 bytes from 93.104.185.180: icmp_seq=3 ttl=63 time=0.595 ms

--- 93.104.185.180 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2037ms
rtt min/avg/max/mdev = 0.595/0.604/0.613/0.007 ms

I have run out of ideas where the problem could come from and am very grateful for any help. Rainer

in flag
Do you see any changes to the `access` files in `/var/log/apache2`? If you see access records, then the problem is inside the Apache configuration. If no access logs are being updated, then the problem is in the stack between the network and Apache
Rainer Bopp avatar
br flag
Indeed I have changes to the access files. And also an error log. "[ssl:warn] [pid 7756] AH01909: owncloudddns.net:443:0 server certificate does NOT include an ID wich matches the server name." How could that happen and what to do? @matigo
in flag
Has your `/etc/hostname` file changed? Alternatively, have any of your Apache configuration files changed? You'll want to confirm that your SSL certificate matches the domain name in the virtual host configuration file
Rainer Bopp avatar
br flag
No file has changed since July. The SSL-Certificate also seems to be alright. Maybe I'm not looking in the right place concerning the virtual host configuration?
Doug Smythies avatar
gn flag
You could run tcpdump (or wireshark, if you prefer) and watch things at the packet level. Suggest: `sudo tcpdump -n -tttt -i enp3s0 port 80 and port 443`. Change `enp3s0` to your interface name. I ran this: `sudo tcpdump -n -tttt -i enp3s0 host 93.104.185.180` on my computer and got no response at all when trying to access via browser.
Rainer Bopp avatar
br flag
I run tcpdump on two interfaces (I am not sure which one is the right one: `wlp2s0b1` or `ens9`) This was the result: `0 packets captured` `0 packets received by filter` `0 packets dropped by kernel`
Doug Smythies avatar
gn flag
Then I think your issue with your port forwarding from your router.
Score:0
br flag

Thank you Doug Smithies. Your indication about port forwarding pointed me to the right issue. For a very strange reason, my router assigned a new IP to the server, even so it was set to a static IP address. But it did not change this information in the port forwarding page (I don't know if this is the right wording, the router is German...). So I changed the IP back to what it was originally. Now everything works fine. The big question is: Why did that happen while is was working on Samba. Anyway, it doesn't matter now.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.