[Bug 246247] Caddy webserver stops listening on port 80; port 443 continues to serve

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246247

            Bug ID: 246247
           Summary: Caddy webserver stops listening on port 80; port 443
                    continues to serve
           Product: Ports & Packages
           Version: Latest
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: Individual Port(s)
          Assignee: ports-bugs at FreeBSD.org
          Reporter: gac at tutanota.com

Created attachment 214188
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=214188&action=edit
pcap that generated the sample log entry in the bug description

I have a VPS webserver running FreeBSD 12.1-RELEASE-p4, and the caddy-1.0.4
package from the FreeBSD repository. I'm having an intermittent issue; every so
often the webserver stops listening on port 80 which serves up HTTP->HTTPS
redirects. Port 443 still works so Caddy is still running and the website is
still available as long as you manually enter 'https://'

So far, all I've worked out is that whenever this happens, a log entry is
generated reading:

May  6 03:46:26 server caddy[32009]: 2020/05/06 03:46:26 set tcp
my.ip:80->remote.ip:52024: setsockopt: connection reset by peer

After this point, `lsof -nni` shows no process listening on port 80 anymore and
trying to access this port from an HTTP client results in 'connection refused'
as expected when no process is bound to a port. I've had a rolling tcpdump
capture running to try and figure out if there's a particular traffic pattern
that triggers this, and so far only one pattern seems to stand out. At the
point this happens, my server sees roughly the following:

In: SYN
+ <1ms
Out: SYN/ACK
+ ~150ms
In: ACK
+ <1ms
In: RST/ACK

So the boxes triggering this appear to be roughly a 150ms round trip away in
all cases and it seems to me like immediately after they send their regular ACK
to me, they also send a RST/ACK without waiting for any response to the regular
ACK. This is happening from multiple source IP addresses (some registered to
AWS, some registered to a company called Dedipath, possibly others but I
haven't checked every IP that has one of those log entries) and it's very
intermittent. Sometimes it won't happen for months, sometimes it happens
multiple times in a day. I've tried using Scapy to replicate this exact traffic
but have been unable to so far (either I'm doing it wrong, or there's something
different about Scapy-generated traffic that means it's not a valid
reproduction)

I've brought this up with the Caddy project on GitHub but they haven't really
been able to offer any solid suggestions so I'm opening a bug here to try and
ascertain if it's a FreeBSD issue rather than a problem with Caddy. A couple of
other GitHub users suggested they've seen the same behaviour so I intend to put
the link for this bug on the Caddy issue tracker to see if they can provide any
further information.

-- 
You are receiving this mail because:
You are the assignee for the bug.