Correct but it seems, from the error log anyway, that it's looking in the wrong directory and producing a 404. Or am I missing something? Sometimes is connects with a 404 sometimes it errors out with the wrong redirect URL.
Is this from within the jail? I would need the output from the host as well.
That was from the proxy jail. Here' s the output from the host:
Routing tables
Internet:
Destination Gateway Flags Netif Expire
default 192.168.0.1 UGS igb1
127.0.0.1 link#3 UH lo0
192.168.0.0/24 link#2 U igb1
192.168.0.200 link#2 UHS lo0
Internet6:
Destination Gateway Flags Netif Expire
::/96 ::1 UGRS lo0
::1 link#3 UH lo0
::ffff:0.0.0.0/96 ::1 UGRS lo0
fe80::/10 ::1 UGRS lo0
fe80::%lo0/64 link#3 U lo0
fe80::1%lo0 link#3 UHS lo0
ff01::%lo0/32 ::1 U lo0
ff02::/16 ::1 UGRS lo0
ff02::%lo0/32 ::1 U lo0
Itās the same net? How? Can I get an ifconfig -a from the host please?
Can you tell me what the problem is, if any, when Let's Encrypt succesfully (at least once, as demonstrated in this topic in post #3) can reach the server of @Jailer? Ignoring the fact namecheap has a broken redirect of course.
You donāt know which IP address it used. Plus there are demonstrable problems from two different networks. Thatās what counts. Itās irrelevant that it works from other networks at this point.
Here you go but it's long, I have several jails.
igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=6403bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
ether 00:25:90:f5:b8:50
nd6 options=9<PERFORMNUD,IFDISABLED>
media: Ethernet autoselect
status: no carrier
igb1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=2400b9<RXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWTSO,RXCSUM_IPV6>
ether 00:25:90:f5:b8:51
inet 192.168.0.200 netmask 0xffffff00 broadcast 192.168.0.255
nd6 options=9<PERFORMNUD,IFDISABLED>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet 127.0.0.1 netmask 0xff000000
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 02:3a:9d:2f:a0:00
nd6 options=1<PERFORMNUD>
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: epair7a flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 12 priority 128 path cost 2000
member: epair0a flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 5 priority 128 path cost 2000
member: epair6a flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 11 priority 128 path cost 2000
member: epair5a flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 10 priority 128 path cost 2000
member: epair4a flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 9 priority 128 path cost 2000
member: epair3a flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 8 priority 128 path cost 2000
member: epair2a flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 7 priority 128 path cost 2000
member: epair1a flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 6 priority 128 path cost 2000
member: igb1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 2 priority 128 path cost 20000
epair1a: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8<VLAN_MTU>
ether 02:ff:20:00:06:0a
nd6 options=1<PERFORMNUD>
media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
status: active
epair2a: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8<VLAN_MTU>
ether 02:ff:20:00:07:0a
nd6 options=1<PERFORMNUD>
media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
status: active
epair3a: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8<VLAN_MTU>
ether 02:ff:20:00:08:0a
nd6 options=1<PERFORMNUD>
media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
status: active
epair4a: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8<VLAN_MTU>
ether 02:ff:20:00:09:0a
nd6 options=1<PERFORMNUD>
media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
status: active
epair5a: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8<VLAN_MTU>
ether 02:ff:20:00:0a:0a
nd6 options=1<PERFORMNUD>
media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
status: active
epair6a: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8<VLAN_MTU>
ether 02:ff:20:00:0b:0a
nd6 options=1<PERFORMNUD>
media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
status: active
epair0a: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8<VLAN_MTU>
ether 02:ff:20:00:05:0a
nd6 options=1<PERFORMNUD>
media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
status: active
epair7a: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8<VLAN_MTU>
ether 02:ff:20:00:0c:0a
nd6 options=1<PERFORMNUD>
media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
status: active
But is it the actual problem @Jailer is facing now?
Letās recap:
First, he got a problem with the connectionā¦ But this was because of the broken redirect.
Second, he got a 404 file not found, which is a server problem (he also got the 404 file not found error in his nginx log!), not a routing problem.
Itās one of the problem that needs fixing. Iām not saying the 404 is not a problem, but that comes later.
Soā¦ Youāre sayingā¦ If a possible routing issue, which possibly isnāt even a structural problem on @Jailerās end, currently doesnāt give any troubleā¦ He should fix that first? 
Osiris signing off 
I think @Osiris is correct in the 2 problem issue. I just canāt for the life of me figure out why nginx would be looking in the wrong directory especially one not listed in the config.
Yes, lower layers are supposed to be working, then deal with upper layers. Or deal with them simultaneously. You can do that in the meantime while I try to figure out the IP stuff.
Just an FYI, odd icmp responses on my end should be expected. What my firewall doesnāt block will likely be caught by snort and blocked. That still doesnāt explain the odd hops but just figured Iād throw that out there.
When debugging, I personally like to go "big" first, than try to narrow it down. I.e., I'd start with:
grep -R etc /path/to/the/dir/where/nginx/config/files/reside
You'll get a lot of noise (your SSL certificates reside in the /usr/local/etc/ path I saw, but you could find some out of the ordinary stuff 
Actually, they shouldn't. There is definitely something wrong with your IP layer connectivity which I can't figure out with just these details. I see now there is some snort service involved, too. Plus your IP address is RFC1918 so there's an additional router with port forwards I assume. In this whole picture there is something terribly wrong. Even for a working connection the traceroute should not have the destination host answering 4 times. The increasing reply times among those 4 replies in @Osiris' output suggest a routing loop somewhere, at which point the minimum TTL of the connecting host comes into play as well, which can very well lead to problems for some clients but not for others.
But this is a completely different problem than the 404 of course.
This is the output. Doesn't look odd to me.
/usr/local/etc/nginx/nginx.conf: ssl_certificate /usr/local/etc/nginx/ssl-bundle.crt;
/usr/local/etc/nginx/nginx.conf: ssl_certificate_key /usr/local/etc/nginx/mlcnfriends.com.key;
/usr/local/etc/nginx/nginx.conf: ssl_dhparam /usr/local/etc/nginx/dhparams.pem;
/usr/local/etc/nginx/nginx.conf: ssl_certificate /usr/local/etc/letsencrypt/live/boredguy.showersnet.com/fullchain.pem;
/usr/local/etc/nginx/nginx.conf: ssl_certificate_key /usr/local/etc/letsencrypt/live/boredguy.showersnet.com/privkey.pem;
/usr/local/etc/nginx/nginx.conf: ssl_dhparam /usr/local/etc/nginx/dhparams.pem;
My ISP is a local outfit and it wouldn't surprise me one bit if they have something screwed up. My wan IP is RFC1918 so yes they have me behind their router. I had to purchase a static public IP to get out of a double NAT situation. Their "good' tech support guy left them a while back and they recently switched top level providers so It wouldn't surprise me if something isn't right on their end.
Back to the nginx. So there is a reverse proxy and an actual web server? Do you consider them both in debugging? Which component is actually throwing the 404? I lost track a bit.
Man I really donāt like this forum software now. I get anti spam measures but good lord! Too many posts for a new member and it locked me out for 14 hoursā¦
Anyway, an update is in order. I finally was able to verify the domain and update my certificate. As @Osiris said there were 2 issues involved here. The first one, the improper redirect, was resolved by submitting a ticket with namecheap. Only took a couple of hours and they got back with me and verified that there was a problem and fixed it. Many thanks to @TCM for figuring that one out. As for the error log message, I had to think about that one a bit. Thatās one of the problems with getting old you have to rattle things around in your head for a bit to come to a conclusion.
I got to looking closer at the proxy config and the nginx error log. It just didnāt make any sense that it was checking the directory listed in the error for verification. After thinking about it for a while (old guy thing) since there was no root directory listed in my server blocks I thought maybe it was checking the first file path it found in the config file which was the path for the SSL certificates. So I defined a root path in the server blocks in the proxy config for both HTTP and HTTPS and BAM! A dry run worked. So I removed the --dry-run switch and tried for real and the certificate was expanded with the www prefix for my domain.
I canāt thank you guys enough for helping me out with this, I never would have figured this out on my own. I always tell people getting somethign running is one thing, fixing it when it breaks is quite another.
TLDR; pebkac rules the day once moreā¦
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.