On Tue, Jan 09, 2024 at 06:24:36AM +0100, Uwe Werler wrote:
> Take a look at the example in man relayd.conf. You have to set the X-header 
> like:
> 
> match header set "X-Forwarded-For" \          value "$REMOTE_ADDR"    
> match header set "X-Forwarded-By" \           value 
> "$SERVER_ADDR:$SERVER_PORT"
> 

That doesn't seem to make difference. I had that set when I first
notice the problem. I still get

Jan  9 07:10:24 stable relayd[29792]: relay wwwtls, session 1 (1 active), 
fqdn1, 127.0.0.1 -> 127.0.0.1:8080, done, GET -> 127.0.0.1:8080;
Jan  9 07:10:25 stable relayd[28442]: relay wwwtls, session 1 (1 active), 
fqdn2, 127.0.0.1 -> 127.0.0.1:8081, done, GET -> 127.0.0.1:8081;
Jan  9 07:10:31 stable relayd[29792]: relay wwwtls2, session 2 (1 active), 0, 
127.0.0.1 -> 127.0.0.1:8080, done, GET
Jan  9 07:10:35 stable relayd[28442]: relay wwwtls2, session 2 (1 active), 0, 
127.0.0.1 -> 127.0.0.1:8080, done, GET

with the X-Forwarded-{For,By} set.

> I could post an example when I'm back at my machine.
> 
> Am 8. Januar 2024 23:51:33 MEZ schrieb Adriano Barbosa 
> <barbosa....@gmail.com>:
> >On Mon, Jan 08, 2024 at 07:01:04AM -0800, Paul Pace wrote:
> >> On 1/7/24 1:31 PM, Adriano Barbosa wrote:
> >> > On Sun, Jan 07, 2024 at 05:21:04AM -0800, Paul Pace wrote:
> >> > > On 1/6/24 7:35 PM, Adriano Barbosa wrote:
> >> > > > On Thu, Jan 04, 2024 at 06:57:10PM -0800, Paul Pace wrote:
> >> > > > > On 1/4/24 10:22 AM, Adriano Barbosa wrote:
> >> > > > > > Hi!
> >> > > > > > I'm trying to use relayd with multiple FQDNs mixing remote 
> >> > > > > > servers
> >> > > > > > with and without tls:
> >> > > > > > 
> >> > > > > > relayd -- fqdn1 --> 127.0.0.1 (no tls)
> >> > > > > >           -- fqdn2 --> x.x.x.x (with tls)
> >> > > > > > 
> >> > > > > > I wrote my relayd.conf like this:
> >> > > > > > 
> >> > > > > > table <fqdn1> { 127.0.0.1 }
> >> > > > > > table <fqdn2> { x.x.x.x }
> >> > > > > > 
> >> > > > > > http protocol https {
> >> > > > > >        tls keypair fqdn1
> >> > > > > >        tls keypair fqdn2
> >> > > > > > 
> >> > > > > >        match request header "Host" value "fqdn1" tag "fqdn1"
> >> > > > > >        pass request tagged "fqdn1" forward to <fqdn1>
> >> > > > > > 
> >> > > > > >        match request header "Host" value "fqdn2" tag "fqdn2"
> >> > > > > >        pass request tagged "fqdn2" forward to <fqdn2>
> >> > > > > > }
> >> > > > > > 
> >> > > > > > relay wwwtls {
> >> > > > > >        listen on egress port 443 tls
> >> > > > > >        protocol https
> >> > > > > >        forward to <fqdn1> port 80
> >> > > > > >        forward with tls to <fqdn2> port 443
> >> > > > > > }
> >> > > > > 
> >> > > > > With one forward requiring TLS in a relay block, relayd will 
> >> > > > > require TLS for
> >> > > > > all forward statements in the relay block.
> >> > > > > 
> >> > > > > > 
> >> > > > > > I have fqdn2 working and fqdn1 giving a "curl: (52) Empty reply 
> >> > > > > > from
> >> > > > > > server".
> >> > > > > > Removing "with tls" on the second forward, fqdn1 works and fqdn2 
> >> > > > > > gives
> >> > > > > > a "Client sent an HTTP request to an HTTPS server."
> >> > > > > > 
> >> > > > > > Is it possible to have relayd working on this scenario? What am I
> >> > > > > > missing here?
> >> > > > > > 
> >> > > > > > Obrigado!
> >> > > > > > --
> >> > > > > > Adriano
> >> > > > > 
> >> > > > 
> >> > > > Thank you for the response.
> >> > > > 
> >> > > > Digging a little more, I found that if I change the listen port from
> >> > > > 443 to values other than 443 and 80, the "match request host" filter
> >> > > > stops working. The behaviour is the same with or without "with tls" 
> >> > > > on
> >> > > > the relay.
> >> > > > 
> >> > > > With port 443:
> >> > > > stable# curl --insecure https://fqdn1
> >> > > > <h1>Server 1</h1>
> >> > > > stable# curl --insecure https://fqdn2
> >> > > > <h1>Server 2</h1>
> >> > > > 
> >> > > > With port 4430 and allegedly any port other than 80 and 443:
> >> > > > stable# curl --insecure https://fqdn1:4430
> >> > > > <h1>Server 1</h1>
> >> > > > stable# curl --insecure https://fqdn2:4430
> >> > > > <h1>Server 1</h1>
> >> > > > 
> >> > > What does curl -vk show?
> >> > > 
> >> > 
> >> > Unfortunately, no difference. Follows:
> >> > 
> >> > $ curl --insecure -vk https://fqdn2
> >> > * Host fqdn2:443 was resolved.
> >> > * IPv6: (none)
> >> > * IPv4: 127.0.0.1
> >> > *   Trying 127.0.0.1:443...
> >> > * Connected to fqdn2 (127.0.0.1) port 443
> >> > * ALPN: curl offers h2,http/1.1
> >> > * TLSv1.3 (OUT), TLS handshake, Client hello (1):
> >> > * TLSv1.3 (IN), TLS handshake, Server hello (2):
> >> > * TLSv1.3 (IN), TLS handshake, Unknown (8):
> >> > * TLSv1.3 (IN), TLS handshake, Certificate (11):
> >> > * TLSv1.3 (IN), TLS handshake, CERT verify (15):
> >> > * TLSv1.3 (IN), TLS handshake, Finished (20):
> >> > * TLSv1.3 (OUT), TLS handshake, Finished (20):
> >> > * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / [blank] / UNDEF
> >> > * ALPN: server did not agree on a protocol. Uses default.
> >> > * Server certificate:
> >> > *  subject: C=BR; ST=MS; L=DOU
> >> > *  start date: Jan  6 20:12:43 2024 GMT
> >> > *  expire date: Jan  5 20:12:43 2025 GMT
> >> > *  issuer: C=BR; ST=MS; L=DOU
> >> > *  SSL certificate verify result: self signed certificate (18), 
> >> > continuing anyway.
> >> > *   Certificate level 0: Public key type ? (4096/128 Bits/secBits), 
> >> > signed using sha256WithRSAEncryption
> >> > * using HTTP/1.x
> >> > > GET / HTTP/1.1
> >> > > Host: fqdn2
> >> > > User-Agent: curl/8.5.0
> >> > > Accept: */*
> >> > > 
> >> > < HTTP/1.1 200 OK
> >> > < Connection: keep-alive
> >> > < Content-Length: 18
> >> > < Content-Type: text/html
> >> > < Date: Sun, 07 Jan 2024 21:23:24 GMT
> >> > < Last-Modified: Sun, 07 Jan 2024 21:19:24 GMT
> >> > < Server: OpenBSD httpd
> >> > <
> >> > <h1>Server 2</h1>
> >> > * Connection #0 to host fqdn2 left intact
> >> > 
> >> > and
> >> > 
> >> > $ curl --insecure -vk https://fqdn2:4430
> >> > * Host fqdn2:4430 was resolved.
> >> > * IPv6: (none)
> >> > * IPv4: 127.0.0.1
> >> > *   Trying 127.0.0.1:4430...
> >> > * Connected to fqdn2 (127.0.0.1) port 4430
> >> > * ALPN: curl offers h2,http/1.1
> >> > * TLSv1.3 (OUT), TLS handshake, Client hello (1):
> >> > * TLSv1.3 (IN), TLS handshake, Server hello (2):
> >> > * TLSv1.3 (IN), TLS handshake, Unknown (8):
> >> > * TLSv1.3 (IN), TLS handshake, Certificate (11):
> >> > * TLSv1.3 (IN), TLS handshake, CERT verify (15):
> >> > * TLSv1.3 (IN), TLS handshake, Finished (20):
> >> > * TLSv1.3 (OUT), TLS handshake, Finished (20):
> >> > * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / [blank] / UNDEF
> >> > * ALPN: server did not agree on a protocol. Uses default.
> >> > * Server certificate:
> >> > *  subject: C=BR; ST=MS; L=DOU
> >> > *  start date: Jan  6 20:12:43 2024 GMT
> >> > *  expire date: Jan  5 20:12:43 2025 GMT
> >> > *  issuer: C=BR; ST=MS; L=DOU
> >> > *  SSL certificate verify result: self signed certificate (18), 
> >> > continuing anyway.
> >> > *   Certificate level 0: Public key type ? (4096/128 Bits/secBits), 
> >> > signed using sha256WithRSAEncryption
> >> > * using HTTP/1.x
> >> > > GET / HTTP/1.1
> >> > > Host: fqdn2:4430
> >> > > User-Agent: curl/8.5.0
> >> > > Accept: */*
> >> > > 
> >> > < HTTP/1.1 200 OK
> >> > < Connection: keep-alive
> >> > < Content-Length: 18
> >> > < Content-Type: text/html
> >> > < Date: Sun, 07 Jan 2024 21:25:42 GMT
> >> > < Last-Modified: Sun, 07 Jan 2024 21:19:15 GMT
> >> > < Server: OpenBSD httpd
> >> > <
> >> > <h1>Server 1</h1>
> >> > * Connection #0 to host fqdn2 left intact
> >> > 
> >> My best guess is httpd is not receiving a host header so is serving the
> >> first server block.
> >> 
> >> Try setting relay logs verbose and then monitor with something like:
> >> 
> >> relayctl log verbose
> >> tail -f /var/log/daemon | grep relay
> >> 
> >
> >That seems to be the reason. Where can I find the meaning of each
> >field in the log? I was no able to find on relay{ctl,d,d.conf} man
> >pages =(
> >Is there any tweak on the config file to make it work or is that an
> >unexpected behaviour?
> >
> >With requests on port 443:
> >Jan  8 18:43:56 stable relayd[40926]: relay wwwtls, session 2 (1 active), 
> >fqdn1, 127.0.0.1 -> 127.0.0.1:8080, done, GET -> 127.0.0.1:8080;
> >Jan  8 18:43:58 stable relayd[39939]: relay wwwtls, session 4 (1 active), 
> >fqdn2, 127.0.0.1 -> 127.0.0.1:8081, done, GET -> 127.0.0.1:8081;
> >
> >With requests on port 4430:
> >Jan  8 18:44:03 stable relayd[40926]: relay wwwtls2, session 3 (1 active), 
> >0, 127.0.0.1 -> 127.0.0.1:8080, done, GET
> >Jan  8 18:44:19 stable relayd[40926]: relay wwwtls2, session 4 (1 active), 
> >0, 127.0.0.1 -> 127.0.0.1:8080, done, GET
> >
> >> You could also add a first server block that is only served when other
> >> blocks aren't matched.
> >> 
> >> > > > Port 8080 also reproduces this last result.
> >> > > > Is that the expected behaviour? BTW, I'm running 7.4.
> >> > > > 
> >> > > > Please find relayd.conf and httpd.conf below.
> >> > > > fqdn{1,2} are on /etc/hosts as 127.0.0.1 and the respective tls
> >> > > > certificates exists in /etc/ssl and keys in /etc/ssl/private.
> >> > > > 
> >> > > > Obrigado!
> >> > > > --
> >> > > > Adriano
> >> > > > 
> >> > > > 
> >> > > > # relayd.conf
> >> > > > addr="127.0.0.1"
> >> > > > 
> >> > > > table <fqdn1> { 127.0.0.1 }
> >> > > > table <fqdn2> { 127.0.0.1 }
> >> > > > 
> >> > > > http protocol https {
> >> > > >           tls keypair fqdn1
> >> > > >           tls keypair fqdn2
> >> > > > 
> >> > > >           match request header "Host" value "fqdn1" tag "fqdn1"
> >> > > >           pass request tagged "fqdn1" forward to <fqdn1>
> >> > > > 
> >> > > >           match request header "Host" value "fqdn2" tag "fqdn2"
> >> > > >           pass request tagged "fqdn2" forward to <fqdn2>
> >> > > > }
> >> > > > 
> >> > > > http protocol https2 {
> >> > > >           tls keypair fqdn1
> >> > > >           tls keypair fqdn2
> >> > > > 
> >> > > >           match request header "Host" value "fqdn1" tag "fqdn1"
> >> > > >           pass request tagged "fqdn1" forward to <fqdn1>
> >> > > > 
> >> > > >           match request header "Host" value "fqdn2" tag "fqdn2"
> >> > > >           pass request tagged "fqdn2" forward to <fqdn2>
> >> > > > }

Anyway, this might still be an unexpected behaviour. Both protocols
I've defined are the same and

> >> > > > 
> >> > > > relay wwwtls {
> >> > > >           listen on $addr port 443 tls
> >> > > >           protocol https
> >> > > > 
> >> > > >           forward to <fqdn1> port 8080
> >> > > >           forward to <fqdn2> port 8081
> >> > > > }
> >> > > > 
> >> > > > relay wwwtls2 {
> >> > > >           listen on $addr port 4430 tls
> >> > > >           protocol https2
> >> > > > 
> >> > > >           forward to <fqdn1> port 8080
> >> > > >           forward to <fqdn2> port 8081
> >> > > > }

the difference is only on the listen port on the relay.

> >> > > > 
> >> > > > 
> >> > > > # httpd.conf
> >> > > > addr="127.0.0.1"
> >> > > > 
> >> > > > server "fqdn1" {
> >> > > >           listen on $addr port 8080
> >> > > >           location "*" {
> >> > > >                   root "/htdocs/server1"
> >> > > >           }
> >> > > > }
> >> > > > 
> >> > > > server "fqdn2" {
> >> > > >           listen on $addr port 8081
> >> > > >           location "*" {
> >> > > >                   root "/htdocs/server2"
> >> > > >           }
> >> > > > }
> >> > > 
> >> 
> >
> 
> -- 
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Reply via email to