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
What changed between yesterday and today?
Any updates or a reset to your opened ports?
Are ports 80 and 443 open?
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
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) |
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
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?
Can you please post your full, unredacted Caddyfile, and leave the server running so we can help you out?
You mean with urls unchanged?
Yep – you can redact any passwords but please leave site addresses and most everything else unchanged.
voila 
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
}Is your server (Caddy) running? I’m not able to connect.
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.
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?
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.
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?
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…
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 …
Ok …
I rebooted my router and renewed port forwarding.
this is now the result of a port scan:
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:
a nmap check on port forward target server:
I have really no idea what the reason could be.
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.