No idea where to find my error


(Homer Sim) #1

I am running version 0.11.0 in a docker container.
It was running all my web apps as a reversproxy perfectly. I changed yesterday this existing working line in Caddyfile
sub1.mydomain.de {
with this:
sub1.mydomain.de, sub2.mydomain.de {

After saving and restarting container it worked
I could access with both urls.

Today I was not able to connect to any web app from internet. Internal addresses are working.

all logs I checked I found nothing … Any ideas for me how to check the issue?

Thanks


(Magikstm) #2

What changed between yesterday and today?

Any updates or a reset to your opened ports?

Are ports 80 and 443 open?


(Homer Sim) #3

I have no idea if beside what I wrote changed over night. I normally have no cronjob for updates or something like this …

I checked again. Web Apps and plain pages are accessable if using internal IP adress but If I am trying to access from outside it is not reachable

nmap showes this:
22/tcp open ssh
80/tcp open http
139/tcp open netbios-ssn
443/tcp open https

it is really strange


(Homer Sim) #4

just to be sure I did a scan from internet
and this seems to be also ok:

22 offen Secure Shell (SSH)
80 offen Web-Server
443 offen Web Server (HTTPS)

(Homer Sim) #5

After an additional restart of the caddy container
I see this in container log

2018/07/07 16:06:17 http: TLS handshake error from 62.32.81.84:43115: tls: first record does not look like a TLS handshake


(Homer Sim) #6

Please, I am really desperate. Any ideas where to look for a solution?

Maybe you can help me with the following news. Today I received from Firefox an page with this:

SSL_ERROR_BAD_CERT_DOMAIN

Can it be that caddy has issues to receive certificates but does not log it?


(Matt Holt) #7

Can you please post your full, unredacted Caddyfile, and leave the server running so we can help you out?


(Homer Sim) #8

You mean with urls unchanged?


(Matt Holt) #9

Yep – you can redact any passwords but please leave site addresses and most everything else unchanged.


(Homer Sim) #10

voila :slight_smile:

    broehlis.my-wan.de {
#wordpress
  proxy / 192.168.100.10:8090 {
    transparent
  }
  log caddy.log
  errors caddy.errors
  tls erwin12344321@yahoo.de
  gzip
}

############################################
homer-s.my-wan.de/gc-bilder {
  root /srv/gc-bilder
  log    /etc/log/gcbilder_access.log
  errors /etc/log/gcbilder_errors.log
  gzip
}

############################################
homer-s.my-wan.de/geo {
  root /srv/geo
#  tls off
  gzip
}

############################################
ebooks.homer-s.my-wan.de {
#COPS
  proxy / 192.168.100.10:8030
  tls mymail@mail.de
  basicauth / user2 pass
  basicauth / user pass
  log    /etc/log/ebooks_access.log
  errors /etc/log/ebooks_errors.log
  gzip

}

############################################
nextcloud.homer-s.my-wan.de, pi905.my-wan.de {
#nextcloud
  proxy / 192.168.100.10:8020 {
    transparent
    websocket
  }
  tls mymail@mail.de
  gzip
  log /etc/log/nextcloud_access.log
  errors /etc/log/nextcloud_errors.log
}

############funzt nicht ganz###############
#portainer.homer-s.my-wan.de {
#portainer
#  proxy / 192.168.100.10:8010 {
#    transparent
#  }
#  tls mymail@mail.de
#}

############################################
sync.homer-s.my-wan.de {
#Syncthing
  proxy / 192.168.100.10:8384 {
    transparent
  }
  basicauth / user pass
  errors /etc/log/sync_errors.log
  gzip
  tls mymail@mail.de
}

############################################
netdata.homer-s.my-wan.de {
#netdata
  proxy / 192.168.100.10:19999 {
    transparent
  }
  basicauth / user pass
  log    /etc/log/netdata_access.log
  errors /etc/log/netdata_errors.log
  gzip
  tls mymail@mail.de
}

############################################
pydio.homer-s.my-wan.de {
#pydio
  proxy / 192.168.100.10:8040 {
    transparent
  }
  log    /etc/log/pydio_access.log
  errors /etc/log/pydio_errors.log
  gzip
  tls mymail@mail.de
}

############################################
#vm.homer-s.my-wan.de {
#guacamole
#  rewrite / /guacamole
#  proxy /guacamole 192.168.100.10:8080 {
#    transparent
#    websocket
#  }
#  tls mymail@mail.de
#}

############################################
pass.homer-s.my-wan.de 
#bitwarden
  proxy / https://192.168.100.70:443 {
    transparent
    websocket
    insecure_skip_verify
  }
  log    /etc/log/pass_access.log
  errors /etc/log/pass_errors.log
  tls mymail@mail.de
}

(Matt Holt) #11

Is your server (Caddy) running? I’m not able to connect.


(Homer Sim) #12

Yes it is
I am able to connect via ssh and the dyndns url … so this should be not the issue …?!


(Matthew Fay) #13

I had a quick look, too.

whitestrake at apollo in ~
❯ env TZ=UTC date
Wed 11 Jul 2018 05:22:42 UTC

whitestrake at apollo in ~
❯ nslookup broehlis.my-wan.de 8.8.8.8
Server:          8.8.8.8
Address:	         8.8.8.8#53

Non-authoritative answer:
Name:   broehlis.my-wan.de
Address: 87.123.122.150

whitestrake at apollo in ~
❯ curl -IL http://broehlis.my-wan.de/
curl: (7) Failed to connect to broehlis.my-wan.de port 80: Connection refused

whitestrake at apollo in ~
❯ curl -IL https://broehlis.my-wan.de/
curl: (7) Failed to connect to broehlis.my-wan.de port 443: Connection refused

Seems like something at the edge of the network is refusing connections on web traffic ports.

Firewall and port forwarding configuration is likely the place to look.


(Homer Sim) #14

Thanks for your help-

Two days ago I checked port forwarding settings in my Router. They were like they assumed to be. A funny story why is port 22 correctly working?

Is there a better way to check it?


(Matthew Fay) #15

Depends on the router software. The best resource I could point you to in that regard is https://portforward.com/.

As for troubleshooting, you might try changing the port forwards to some other host and see if that works, then try changing it back.


(Homer Sim) #16

Even sitting in the office I found out that the dyndns seems to be not working.
My manual update showed a new IP address.
But when i tried to connect with this new ip adress I was not able to connect either. Yesterdays working port 22 is also not working today …
Can it be an issue with my fritzbox?


(Matthew Fay) #17

The issue could be caused or compounded by DNS propagation delays.

In fact, since my last post, the A record for the domain I checked has already changed. I queried the authoritative nameserver:

whitestrake at apollo in ~
❯ nslookup broehlis.my-wan.de 83.246.76.144
Server:		83.246.76.144
Address:	83.246.76.144#53

Name:	broehlis.my-wan.de
Address: 80.187.81.161

The new IP address has propagated to Google’s public resolver, too.

I’m not getting any response on web traffic ports from the new address, though (timeouts).


Edit: Seems it’s changed back to 87.123.122.150


(Homer Sim) #18

Thanks for this hint. I recognized it now too.
I have the feeling my DynDNS service provider is having issues …

This behavior is still existing after a while IP address is changed back. But on both addresses I am not able to reach the server. This is very strange.

At home I will reboot my router first …


(Homer Sim) #19

Ok …
I rebooted my router and renewed port forwarding.
this is now the result of a port scan:
grafik
A “closed” port means that it is responding to packets sent by the port scanner, however no application is listening on that port.

router showes:
grafik

a nmap check on port forward target server:
grafik

I have really no idea what the reason could be.


(Matthew Fay) #20

That could be what it means. Alternately, it might mean that a firewall is denying access to the port.

Based on the information you’ve given, it seems like the Caddy host is working fine, but your NAT device isn’t working as intended.

Packets received by your router on web ports simply aren’t reaching their intended destination. On its face, the issue is describable as broken port forwarding.

From here, you could try set the Caddy host as a “DMZ host” and see if that works, or swap your NAT device for another, known good device.