On 4/1/25 21:10, Van Snyder wrote:

I have a web server listening to port 80 (http) and 443 (https).

I can load pages from it from any computer in my house, all behind the
same router, using its IP number.

I enabled port forwarding in the DMZ in my router for ports 80 and 443.

I can't load pages through my router using its WLAN name or WLAN IP
number. I get "Unable to connect" from Firefox. or "This site can't be reached"  and ERR_ADDRESS_UNREACHABLE from Konqueror.

Do you mean that you want to access your http server from the outside
world (inbound connection).


The below assumes that this is the case.

I have mapped port 8079 to port 80 in my router. I can't load pages
using that mapping.

You need to point your browser to port tcp 8079 with something like 'http://<IP>:port'.


Get it to work with an IP and than move on to DNS.

I also map an external port (not 22) to port 22, and I can "ssh" to my computer using its WLAN name.

The correct way to access services on your network from the outside and
the inside is to use Split DNS.

This was all working until about three weeks ago. I didn't change the firmware in my Linksys.

Something has changed, by the sound of what you are discribing it looks
like it was a miracle.

ARe you using UPNP?

Any ideas?

Are you restricting what IPs the httpd is listening on?
FW inbetween?

--
John Doe

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Apr 01, 2025 at 17:52:55 -0700, Van Snyder wrote:

The server is on the LAN side of the router (192.168.1.65). It's not in
the DMZ. My server isn't running Apache ACLs or iptables or TCP
wrapper. The router is running a firewall.  I've forwarded WAN-side
ports 23, 80 and 443 to my server, and another non-22 WAN-side port to
port 22 on my server.

I can view pages from my server on itself or other computers in my
house using 192.168.1.65 (the LAN side of the router), but not
47.229.8.99 (the WAN side of the router).

OK, so just to be clear:

1) Your internal computer is running a web server on ports 80 and 443.
2) Your internal computer's IP address is 192.168.1.65.
3) Your router's external IP address is 47.229.8.99.
4) You've told your router to forward port 80 to 192.168.1.65 port 80.

Maybe my server isn't listening for telnet. I installed telnet and
telnetd, but "systemctl start telnetd" said there's no such thing.

DO NOT install telnetd!!

OK, with that out of the way:

hobbit:~$ telnet 47.229.8.99 80
Trying 47.229.8.99...
telnet: Unable to connect to remote host: No route to host

I cannot reach your router's external IP address from here. You'll
want to verify that this is the correct IP adderss, and if it is,
figure out why it can't be routed-to from the outside world.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

-------- Forwarded Message --------
From: jeremy ardley <jeremy.ardley@gmail.com>
To: debian-user@lists.debian.org
Subject: Re: Web server access
Date: 04/01/2025 05:29:23 PM


On 2/4/25 08:21, Timothy M Butterworth wrote:

Ok so if I understand you correctly then you are attempting to port
forward 80 and 443 through the router's WAN Wide Area Network
interface to a server located in the DMZ DeMilitarized Zone. Does the
server have Apache ACL's, IP Tables or TCP wrapper running on it? Can
you try to do a port ping or use telnet to connect to port 80 to test connectivity. ex: `telnet <Routers WAN IP Address or Public DNS Name>
80`. As you say that the server is on the inside of your network.
Have
you tried placing the server in the DMZ?

Another alternative is the ISP has started blocking incoming
connections
on the web ports?

How could I find out if it's doing that?

It's not blocking the random port that I map to 22 so I can ssh to my
server.

I can FTP to my server from itself, but not through the router.

I can't FTP to my server from another computer in my house.

And now it seems I can't load web pages from my server on other
computers in my house. So maybe the server has started some kind of a
firewall. How would I find it and either turn it off or configure it so
it allows more than ssh.


<html><head></head><body><div>-------- Forwarded Message --------</div><div><b>From</b>: jeremy ardley &lt;<a href="mailto:jeremy%20ardley%20%3cjeremy.ardley@gmail.com%3e">jeremy.ardley@gmail.com</a>&gt;</div><div><b>To</b>: <a href="mailto:debian-user@
lists.debian.org">debian-user@lists.debian.org</a></div><div><b>Subject</b>: Re: Web server access</div><div><b>Date</b>: 04/01/2025 05:29:23 PM</div><div><br></div><div><br></div><div>On 2/4/25 08:21, Timothy M Butterworth wrote:<br></div><blockquote
type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br></div><div>Ok so if I understand you correctly then you are attempting to port <br></div><div>forward 80 and 443 through the router's WAN Wide Area Network <br>
</div><div>interface to a server located in the DMZ DeMilitarized Zone. Does the <br></div><div>server have Apache ACL's, IP Tables or TCP wrapper running on it? Can <br></div><div>you try to do a port ping or use telnet to connect to port 80 to test <br>
</div><div>connectivity. ex: `telnet &lt;Routers WAN IP Address or Public DNS Name&gt; <br></div><div>80`. As you say that the server is on the inside of your network. Have <br></div><div>you tried placing the server in the DMZ?<br></div></blockquote><

<br></div><div><br></div><div>Another alternative is the ISP has started blocking incoming connections <br></div><div>on the web ports?<br></div><div><br></div><div>How could I find out if it's doing that?</div><div><br></div><div>It's not blocking

the random port that I map to 22 so I can ssh to my server.</div><div><br></div><div>I can FTP to my server from itself, but not through the router.</div><div><br></div><div>I can't FTP to my server from another computer in my house.</div><div><br></div><

And now it seems I can't load web pages from my server on other computers in my house. So maybe the server has started some kind of a firewall. How would I find it and either turn it off or configure it so it allows more than ssh.</div><div><br></div>

<div><span></span></div></body></html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Greg Wooledge <greg@wooledge.org> wrote:

On Tue, Apr 01, 2025 at 17:52:55 -0700, Van Snyder wrote:

The server is on the LAN side of the router (192.168.1.65). It's
not in the DMZ. My server isn't running Apache ACLs or iptables or
TCP wrapper. The router is running a firewall.  I've forwarded
WAN-side ports 23, 80 and 443 to my server, and another non-22
WAN-side port to port 22 on my server.

I can view pages from my server on itself or other computers in my
house using 192.168.1.65 (the LAN side of the router), but not
47.229.8.99 (the WAN side of the router).

OK, so just to be clear:

1) Your internal computer is running a web server on ports 80 and 443.
2) Your internal computer's IP address is 192.168.1.65.
3) Your router's external IP address is 47.229.8.99.
4) You've told your router to forward port 80 to 192.168.1.65 port 80.

Maybe my server isn't listening for telnet. I installed telnet and
telnetd, but "systemctl start telnetd" said there's no such thing.

DO NOT install telnetd!!

OK, with that out of the way:

hobbit:~$ telnet 47.229.8.99 80
Trying 47.229.8.99...
telnet: Unable to connect to remote host: No route to host

I cannot reach your router's external IP address from here. You'll
want to verify that this is the correct IP adderss, and if it is,
figure out why it can't be routed-to from the outside world.

$ telnet 47.229.8.99 80
Trying 47.229.8.99...
Connected to 47.229.8.99.
Escape character is '^]'.

GET index.html
HTTP/1.1 400 Bad Request
Date: Wed, 02 Apr 2025 10:00:16 GMT
Server: Apache/2.4.62 (Debian)
Content-Length: 304
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not
understand.<br /> </p>

<address>Apache/2.4.62 (Debian) Server at blue.vsnyder Port 80</address> </body></html>
Connection closed by foreign host.
dhoworth@acer-suse:~/finance/ripple$ ping 47.229.8.99
PING 47.229.8.99 (47.229.8.99) 56(84) bytes of data.
^C
--- 47.229.8.99 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2042ms

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

<tomas@tuxteam.de> wrote:

On Wed, Apr 02, 2025 at 11:04:17AM +0100, debian-user@howorth.org.uk
wrote:

GET index.html

should be:

GET index.html HTTP/1.0

(Strictly speaking you should close off with twice <CR><LF>, but
most web servers are tolerant if you just send two <LF>)

Not sending a HTTP version in your request /is/ a bad request,
indeed.

Well, practically it makes no difference. If I send with or without an
HTTP version I get the same Bad Request response. And it makes no
difference whether I use HTTP/1.0 or HTTP/1.1.

In fact sending an HTTP version is not compulsory and the request must
be interpreted as HTTP/0.9 if it is not sent.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Apr 02, 2025 at 13:01:10 +0100, debian-user@howorth.org.uk wrote:

<tomas@tuxteam.de> wrote:

On Wed, Apr 02, 2025 at 11:04:17AM +0100, debian-user@howorth.org.uk
wrote:

GET index.html

should be:

GET index.html HTTP/1.0

Well, practically it makes no difference. If I send with or without an
HTTP version I get the same Bad Request response. And it makes no
difference whether I use HTTP/1.0 or HTTP/1.1.

hobbit:~$ printf 'GET / HTTP/1.0\r\nHost: vandyke.mynetgear.com\r\nConnection: close\r\n\r\n' | nc 47.229.8.99 80
HTTP/1.1 200 OK
Date: Wed, 02 Apr 2025 12:09:39 GMT
Server: Apache/2.4.62 (Debian)
Last-Modified: Mon, 17 Jun 2024 21:42:20 GMT
ETag: "7ba-61b1cd703a498"
Accept-Ranges: bytes
Content-Length: 1978
Vary: Accept-Encoding
Connection: close
Content-Type: text/html

<title>Van Snyder's Web</title>

<h1>Van Snyder's Web</h1>
[...]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Apr 02, 2025 at 11:04:17AM +0100, debian-user@howorth.org.uk wrote:

GET index.html

should be:

GET index.html HTTP/1.0

(Strictly speaking you should close off with twice <CR><LF>, but
most web servers are tolerant if you just send two <LF>)

Not sending a HTTP version in your request /is/ a bad request,
indeed.

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZ+0R+AAKCRAFyCz1etHa RoEaAJ9y3Q86FXGi772wCGazuKyeORUSFwCdHDZgd51XL3+YDNIsH7Rpjr1hIjU=
=TDqC
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 02.04.25 um 14:01 schrieb debian-user@howorth.org.uk:

<tomas@tuxteam.de> wrote:

On Wed, Apr 02, 2025 at 11:04:17AM +0100, debian-user@howorth.org.uk
wrote:

GET index.html

should be:

GET index.html HTTP/1.0

(Strictly speaking you should close off with twice <CR><LF>, but
most web servers are tolerant if you just send two <LF>)

Not sending a HTTP version in your request /is/ a bad request,
indeed.

Well, practically it makes no difference. If I send with or without an
HTTP version I get the same Bad Request response. And it makes no
difference whether I use HTTP/1.0 or HTTP/1.1.

In fact sending an HTTP version is not compulsory and the request must
be interpreted as HTTP/0.9 if it is not sent.

Try sending a Host-Header with the request:

GET /index.html HTTP/1.1
Host: whatever

That might make the difference.

--
Regards
mks

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

debian-user@howorth.org.uk (HE12025-04-02):

Well, practically it makes no difference. If I send with or without an
HTTP version I get the same Bad Request response. And it makes no
difference whether I use HTTP/1.0 or HTTP/1.1.

Does it make a difference if you send CRLF instead of LF, as Tomas
mentioned? For that, you would need to hit ctrl-enter and see ^M in the terminal, each time before you hit enter.

Regards,

--
Nicolas George

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Apr 02, 2025 at 03:55:08PM +0200, Nicolas George wrote:

debian-user@howorth.org.uk (HE12025-04-02):

Well, practically it makes no difference. If I send with or without an
HTTP version I get the same Bad Request response. And it makes no difference whether I use HTTP/1.0 or HTTP/1.1.

Does it make a difference if you send CRLF instead of LF, as Tomas
mentioned? For that, you would need to hit ctrl-enter and see ^M in the terminal, each time before you hit enter.

To be fair, I said that most web servers are lenient. The RFCs state
CRLF, though.

I've been immersed in $DAYJOB, so I haven't been paying very close
attention, but my impression was that the problem is solved?

FWIW, my local web server, a lighttpd, responds also with a "400
Bad Request" to a "GET /" without a version. Some randomly tested
hosts "out there" sometimes play along, sometimes not.

And oh, telnet converts the LFs to CRLFs. With nc (which doesn't
translate), LFs alone also elicit a Bad Request (again, on my local
lighttpd instance).

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZ+1dywAKCRAFyCz1etHa RrzZAJ9lJuZ95UWckS1/anI0NswJTHX2BwCdEbzYy+RmuJ1Q0V11NoA06yMb9II=
=G399
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Apr 02, 2025 at 12:03:32 -0700, Van Snyder wrote:

On Wed, 2025-04-02 at 11:25 -0700, Van Snyder wrote:

On Wed, 2025-04-02 at 01:17 -0400, Timothy M Butterworth wrote:

I am able to reach The Van Snyder's Web Site using the above IP
address and URL on port 80 but not 443. I got a certificate error
on 443. 

I've never before set up a secure server. I followed instructions at
a web page, whose URL I neglected to put into my notes, to set up the
SSL.

I probably did something wrong.

Was there a clue in the error message about what I did wrong?

I got a security error too. It says the problem is that the certificate
is self-signed. I have no idea what that means or how to repair it.

*If* you want to go down this road, the simplest way is to install one
of the "Let's Encrypt" support packages and follow its instructions to
obtain and maintain a Let's Encrypt certificate.

This is not just a one-time setup; the certificate expires every few
months and has to be updated, so there is a nightly cron job or similar
to check on it and replace it if it's sufficiently old. The good news
is, you only have to *do stuff* once, and the package should be able to
do the rest.

There are several suitable packages for this; I'm using "dehydrated",

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)