Re: Configure User-Agent is relayd HTTP Check ?
On Wed, 29 May 2024 12:19:15 +0100, Joel Carnat wrote: > > Is there a way to specify a User-Agent value for the check http or shall I > rather tell relayd to validate on "code 418"? here two possible way to overstep it. 1. Use `check script /some/script` which uses curl, wget, ftp or any other way to make HTTP call which is accepted by that server. 2. Use `check send "HEAD /health HTTP/1.1\r\nHost: host\r\nUser-Agent: dummy\r\n\r\n" expect "200 OK HTTP/1.1"` (I haven't tested it, it may contains typos, but it should make an idea) -- wbr, Kirill
Configure User-Agent is relayd HTTP Check ?
Hi,
Some web applications don’t like when relayd connects to them, for
health-checks, without providing a User-Agent HTTP header. They return an
HTTP/418.
So something like
relay "ipv4" {
listen on www.example.com port 443 tls
protocol "https"
forward to port 8080 check http "/health" code 200
}
will not work.
Is there a way to specify a User-Agent value for the check http or shall I
rather tell relayd to validate on "code 418"?
Thank you,
Joel C.
--
Envoyé de mon iPhone
match rules and relayd rdr
Hi, I want to convert a pf rule to rdr-to via relayd (add load balancer in the mix to multiple servers). My hesitation is how to pass the extra tcp options I pass in the rule. I believe this should be done via match rules, but I'm not sure if the pass rule should be on the pf or the relayd side. The rule looks like this: pass in quick on egress proto tcp from any to $server port = 80 flags S/SA set (prio(1, 2)) keep state (pflow, tcp.first 10, tcp.opening 10, tcp.established 18000, tcp.closing 30, tcp.finwait 30, tcp.closed 30) tag from_ext Should I change the pf pass rule to match (with no quick) and add the relayd anchor after that (with pass in relayd, default) or the other way around: relayd anchor first, match in relayd and then pass in quick on the pf side. I want to keep both the prio and tcp options as well as the rdr-to inserted from relayd. Is it essentially the same either way? Thanks, G
Re: Relayd forward to multiple ports on one target host?
Paul Pace writes:
> On 2024-05-02 07:32, Manuel Giraud wrote:
>> table { 127.0.0.1 }
>> table { 127.0.0.1 }
>> table { 127.0.0.1 }
>
> On 2024-05-02 07:02, Zé Loff wrote:
>> table { 10.17.16.10 }
>> table { 10.17.16.10 }
>> table { 10.17.16.10 }
>
> Multiple tables - I didn't see that!
Yes, AFAIU, a table is *not* just an alias for say 192.0.2.99. It is
the structure that maintain the link between a protocol an a relay
(surely this explanation is not quite right: you better read the man
pages ;)
--
Manuel Giraud
Re: Relayd forward to multiple ports on one target host?
On 2024-05-02 07:32, Manuel Giraud wrote:
table { 127.0.0.1 }
table { 127.0.0.1 }
table { 127.0.0.1 }
On 2024-05-02 07:02, Zé Loff wrote:
table { 10.17.16.10 }
table { 10.17.16.10 }
table { 10.17.16.10 }
Multiple tables - I didn't see that!
I'm going with something like this to keep things simple for myself:
table { 192.0.2.99 }
table { 192.0.2.99 }
table { 192.0.2.99 }
Thank you,
Paul
Re: Relayd forward to multiple ports on one target host?
Paul Pace writes:
> Hello!
>
> I have an OpenBSD server that hosts multiple services listening on
> various ports (some projects have their own web server, some projects
> require a reverse proxy, some projects just use httpd, etc.). This
> server receives requests via relayd on a different server. I was
> hoping to not insert relayd between every request to the host, but
> it's not the end of the world if this is the only viable solution
> while using relayd.
>
> The requests to relayd go to domains (e.g., www.example.com,
> serviceone.example.com, servicetwo.example.com, etc.) for web services
> (ports 80 and 443), but I cannot figure out a way to specify a port on
> the target server to forward requests to when there are multiple ports
> (e.g., www is on port 80, serviceone is on port 8080, servicetwo is on
> port 3, etc.). Running relayd -n does not report syntax errors
> when there are multiple forward to rules for the same target server
> with different ports in the relay block, but I can't find a way to
> specify which request should go to which port.
Hi,
I'm not sure this could answer your issue but here is a sketch of what
I'm using on some servers:
--8<---cut here---start->8---
table { 127.0.0.1 }
table { 127.0.0.1 }
table { 127.0.0.1 }
http protocol "secure" {
tcp { nodelay, sack, socket buffer 65536, backlog 128 }
tls { no tlsv1.0, ciphers HIGH, keypair example.com }
# Matching is done here on Host
match request quick header "Host" value "example.com" \
forward to
match request quick header "Host" value "service1.example.com" \
forward to
match request quick header "Host" value "service2.example.com" \
forward to
}
relay "secure-proxy" {
listen on 0.0.0.0 port 443 tls
protocol "secure"
# Forward to different services
forward with tls to port 80 check tls
forward with tls to port 8080 check tls
forward with tls to port 3 check tls
}
--8<---cut here---end--->8---
Best regards,
--
Manuel Giraud
Re: Relayd forward to multiple ports on one target host?
On Thu, May 02, 2024 at 06:34:51AM -0700, Paul Pace wrote:
> Hello!
>
> I have an OpenBSD server that hosts multiple services listening on various
> ports (some projects have their own web server, some projects require a
> reverse proxy, some projects just use httpd, etc.). This server receives
> requests via relayd on a different server. I was hoping to not insert relayd
> between every request to the host, but it's not the end of the world if this
> is the only viable solution while using relayd.
>
> The requests to relayd go to domains (e.g., www.example.com,
> serviceone.example.com, servicetwo.example.com, etc.) for web services
> (ports 80 and 443), but I cannot figure out a way to specify a port on the
> target server to forward requests to when there are multiple ports (e.g.,
> www is on port 80, serviceone is on port 8080, servicetwo is on port 3,
> etc.). Running relayd -n does not report syntax errors when there are
> multiple forward to rules for the same target server with different ports in
> the relay block, but I can't find a way to specify which request should go
> to which port.
>
> Thank you,
>
> Paul
>
Not sure if this is what you are looking for but, I use something like
this on my relayd.conf:
table { 10.17.16.10 }
table { 10.17.16.10 }
table { 10.17.16.10 }
http protocol "http_revproxy" {
match request header "Host" value "www.example.com" forward to
match request header "Host" value "serviceone.example.com" forward to
}
https protocol "https_revproxy" {
tls keypair "servicetwo.example.com"
match request header "Host" value "servicetwo.example.com" forward to
}
relay "http_relay" {
listen on re0 port 80
protocol "http_revproxy"
forward to port 80 check tcp
forward to port 8080 check tcp
}
relay "https_relay" {
listen on re0 port 443
protocol "https_revproxy"
forward to port check tcp
}
Three notes:
- servicetwo is internally served over simple HTTP (i.e. no TLS) on port
. So you get HTTPS between the client and relayd, and HTTP between
relayd and the service itself
- change re0 to the appropriate interface on the "listen" lines
- I find it preferable to have everything going through relayd,
especially since in makes it easier for me to centralise the whole TLS
certificates dance.
--
Relayd forward to multiple ports on one target host?
Hello! I have an OpenBSD server that hosts multiple services listening on various ports (some projects have their own web server, some projects require a reverse proxy, some projects just use httpd, etc.). This server receives requests via relayd on a different server. I was hoping to not insert relayd between every request to the host, but it's not the end of the world if this is the only viable solution while using relayd. The requests to relayd go to domains (e.g., www.example.com, serviceone.example.com, servicetwo.example.com, etc.) for web services (ports 80 and 443), but I cannot figure out a way to specify a port on the target server to forward requests to when there are multiple ports (e.g., www is on port 80, serviceone is on port 8080, servicetwo is on port 3, etc.). Running relayd -n does not report syntax errors when there are multiple forward to rules for the same target server with different ports in the relay block, but I can't find a way to specify which request should go to which port. Thank you, Paul
Re: RELAY_MAXHOSTS for relayd
On 26/04/2024 20:48, Tobias Fiebig wrote: Moin, I am currently playing around with some relayd things, and noticed that relayd has a #define for RELAY_MAXHOSTS 32 (defined in 2007); Currently planning to give 64 a shot. Does somebody recall why this value was chosen? (Kind of trying to not shoot myself in the foot there, if it is preventable. ;-)) With best regards, Tobias I'm near that limit and interested to see what you come up with. G
RELAY_MAXHOSTS for relayd
Moin, I am currently playing around with some relayd things, and noticed that relayd has a #define for RELAY_MAXHOSTS 32 (defined in 2007); Currently planning to give 64 a shot. Does somebody recall why this value was chosen? (Kind of trying to not shoot myself in the foot there, if it is preventable. ;-)) With best regards, Tobias
Re: Restic rest server broken with relayd.
Hi Stuart.
Stuart Henderson wrote:
> On 2024-04-10, a...@abiscuola.com wrote:
> > Is there a way to restore the previous behaviour in relayd(8)
>
> Only by reverting the commit etc.
>
> > or, is there a known workaround for restic, in this case?
>
> That's probably a question for restic really (or possibly the
> requirement is coming from a 3rd party REST library).
>
> > I know that relayd(8) is right
>
> It seems a little strict to me.
Yes and no.
I mean, while I agree that it looks a bit too strict, the restic
developers are wrong assuming that *any* proxy, put between a
restic HTTP server (that might not even be the packaged
restic-rest-server) and the client would return the headers as
they expect and they are also wrong assuming that the content-length
will be the same between a HEAD call and a GET call.
They even told me that there is no reason why a proxy would mangle
the response headers. Probably they never had to deal with a setup
in a classic corporate network.
That said, IMHO relayd(8) should have shipped with an option, in the
configuration file, to restore the previous behaviour, while
keeping the new one the default.
>
> To my eye, the older version of the HTTP spec requires it ("The
> Content-Length entity-header field indicates the size of the
> entity-body, in decimal number of OCTETs, sent to the recipient or, in
> the case of the HEAD method, the size of the entity-body that would have
> been sent had the request been a GET").
>
> That's been replaced now but it's still permitted: "The server SHOULD
> send the same header fields in response to a HEAD request as it would
> have sent if the request had been a GET, except that the payload header
> fields (Section 3.3) MAY be omitted."
It's permitted, but not mandatory. This is, of course, on the client
program to fix properly.
Anyway. I worked around the problem by putting the restic server behind
a simple TCP relay in relayd(8). Of course, I also needed to change the
public port, but that's a minor nuisance.
Being able to keep the 443 would have been better.
--
absc
Re: Restic rest server broken with relayd.
On 2024-04-10, a...@abiscuola.com wrote:
> Is there a way to restore the previous behaviour in relayd(8)
Only by reverting the commit etc.
> or, is there a known workaround for restic, in this case?
That's probably a question for restic really (or possibly the
requirement is coming from a 3rd party REST library).
> I know that relayd(8) is right
It seems a little strict to me.
To my eye, the older version of the HTTP spec requires it ("The
Content-Length entity-header field indicates the size of the
entity-body, in decimal number of OCTETs, sent to the recipient or, in
the case of the HEAD method, the size of the entity-body that would have
been sent had the request been a GET").
That's been replaced now but it's still permitted: "The server SHOULD
send the same header fields in response to a HEAD request as it would
have sent if the request had been a GET, except that the payload header
fields (Section 3.3) MAY be omitted."
--
Please keep replies on the mailing list.
Restic rest server broken with relayd.
Hi all. I've updated my server to OpenBSD 7.5, where relayd(8) works as a reverse proxy for a bunch of services, including the restic-rest-server from ports. However, with the change in version 1.87 of the usr.sbin/relayd/relay_http.c file, relayd(8) stopped forwarding the content-length header in response to HEAD requests. The restic client, before doing anything, does a HEAD request to understand the size of the repository config file but, of course, restic gives up because of the absence of the content-length header in the respone. Is there a way to restore the previous behaviour in relayd(8) or, is there a known workaround for restic, in this case? I know that relayd(8) is right and, luckily, the important files are backed-up locally using just http, so it's not an emergency. Thanks in advance. -- absc
Re: OpenBSD 7.5 - relayd -> vaultwarden - websockets payload not working
It's certainly possible that some of the relayd hardening changes are to blame. Would you be able to rebuild relayd with some of those commits reverted to see if one of them is to blame? - todd
Re: OpenBSD 7.5 - relayd -> vaultwarden - websockets payload not working
Pardon me for not sending plain text the first time. Got trigger happy.
Ollie
I have been running the Vaultwarden password manager behind relayd for a couple
of years now, and have spun up a new 7.5 VM on Vultr to test.
I'm using pkg_add to install the binary package for the 7.5 release -
vaultwarden-1.30.5, so nothing nonstandard.
The problem - Vaultwarden uses a websockets connection to push changes to user
data in real time to all connected devices, and on 7.5 with relayd acting as
reverse proxy, websockets sessions get established successfully, but no payload
is able to pass from the server to the client.
Here are two images that show the dev console in Firefox -
https://imgur.com/a/msvyXbX
The first image shows websockets working correctly when public traffic is
directed to Vaultwarden's Rocket server without using relayd as a reverse proxy.
The second image shows relayd in place; no websockets payload can pass and the
Vaultwarden application cannot push changes to user data.
Relayd worked great for Vaultwarden in 7.4 and earlier. I saw that relayd got
touched in the changelogs.
My relayd.conf is:
table { localhost }
# protocol definition for vaultwarden with tls
http protocol vaultwarden-https {
# forward connections to vaultwarden rocket
match request path "/*" forward to
# add headers vaultwarden may need
match request header append "Host" value "$HOST"
match request header append "X-Real-IP" value "$REMOTE_ADDR"
match request header append "X-Forwarded-For" value "$REMOTE_ADDR"
match request header append "X-Forwarded-By" value
"$SERVER_ADDR:$SERVER_PORT"
match request header append "CF-Connecting-IP" value "$REMOTE_ADDR"
# various TCP options
tcp { nodelay, sack, backlog 128 }
# tls config
tls keypair vault.example.com
tls { no tlsv1.0, ciphers HIGH }
# allow websockets - this is nice it handles all the headers no need
for manual header edits
http websockets
}
# relay definition for vaultwarden - forward inbound 443 tls on the egress
interface to rocket on default port 8000
relay vaultwarden-https-relay {
listen on egress port 443 tls
protocol vaultwarden-https
forward to port 8000
}
And dmesg (VM on vultr) is:
OpenBSD 7.5 (GENERIC.MP) #82: Wed Mar 20 15:48:40 MDT 2024
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4278042624 (4079MB)
avail mem = 4127375360 (3936MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S3 S4 S5
acpi0: tables DSDT FACP APIC HPET MCFG WAET
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD EPYC-Rome Processor, 1996.57 MHz, 17-31-00
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,OSVW,TOPEXT,CPCTR,FSGSBASE,BMI1,AVX2,SMEP,BMI2,CLFLUSHOPT,CLWB,SHA,UMIP,IBRS,IBPB,SSBD,IBPB,STIBP,XSAVEOPT,XSAVES
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line
8-way L2 cache, 16MB 64b/line 16-way L3 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 1000MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD EPYC-Rome Processor, 1996.74 MHz, 17-31-00
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,OSVW,TOPEXT,CPCTR,FSGSBASE,BMI1,AVX2,SMEP,BMI2,CLFLUSHOPT,CLWB,SHA,UMIP,IBRS,IBPB,SSBD,IBPB,STIBP,XSAVEOPT,XSAVES
cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line
8-way L2 cache, 16MB 64b/line 16-way L3 cache
cpu1: smt 1, core 0, package 0
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
acpihpet0 at acpi0: 1 Hz
acpimcfg0 at acpi0
acpimcfg0: addr 0xb000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
"ACPI0006" at acpi0 not configured
acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x
"PNP0A06" at acpi0 not configured
"PNP0A06" at acp
OpenBSD 7.5 - relayd -> vaultwarden - websockets payload not working
I have been running the Vaultwarden password manager behind relayd for a couple
of years now, and have spun up a new 7.5 VM on Vultr to test.
I'm using pkg_add to install the binary package for the 7.5 release -
vaultwarden-1.30.5, so nothing nonstandard.
The problem - Vaultwarden uses a websockets connection to push changes to user
data in real time to all connected devices, and on 7.5 with relayd acting as
reverse proxy, websockets sessions get established successfully, but no payload
is able to pass from the server to the client.
Here are two images that show the dev console in Firefox -
https://imgur.com/a/msvyXbX
The first image shows websockets working correctly when public traffic is
directed to Vaultwarden's Rocket server without using relayd as a reverse proxy.
The second image shows relayd in place; no websockets payload can pass and the
Vaultwarden application cannot push changes to user data.
Relayd worked great for Vaultwarden in 7.4 and earlier. I saw that relayd got
touched in the changelogs.
My relayd.conf is:
table { localhost }
# protocol definition for vaultwarden with tls
http protocol vaultwarden-https {
# forward connections to vaultwarden rocket
match request path "/*" forward to
# add headers vaultwarden may need
match request header append "Host" value "$HOST"
match request header append "X-Real-IP" value "$REMOTE_ADDR"
match request header append "X-Forwarded-For" value "$REMOTE_ADDR"
match request header append "X-Forwarded-By" value
"$SERVER_ADDR:$SERVER_PORT"
match request header append "CF-Connecting-IP" value "$REMOTE_ADDR"
# various TCP options
tcp { nodelay, sack, backlog 128 }
# tls config
tls keypair vault.example.com
tls { no tlsv1.0, ciphers HIGH }
# allow websockets - this is nice it handles all the headers no need
for manual header edits
http websockets
}
# relay definition for vaultwarden - forward inbound 443 tls on the egress
interface to rocket on default port 8000
relay vaultwarden-https-relay {
listen on egress port 443 tls
protocol vaultwarden-https
forward to port 8000
}
And dmesg (VM on vultr) is:
OpenBSD 7.5 (GENERIC.MP) #82: Wed Mar 20 15:48:40 MDT 2024
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4278042624 (4079MB)
avail mem = 4127375360 (3936MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0
acpi0 at bios0: ACPI 3.0
acpi0: sleep states S3 S4 S5
acpi0: tables DSDT FACP APIC HPET MCFG WAET
acpi0: wakeup devices
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: AMD EPYC-Rome Processor, 1996.57 MHz, 17-31-00
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,OSVW,TOPEXT,CPCTR,FSGSBASE,BMI1,AVX2,SMEP,BMI2,CLFLUSHOPT,CLWB,SHA,UMIP,IBRS,IBPB,SSBD,IBPB,STIBP,XSAVEOPT,XSAVES
cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line
8-way L2 cache, 16MB 64b/line 16-way L3 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 1000MHz
cpu1 at mainbus0: apid 1 (application processor)
cpu1: AMD EPYC-Rome Processor, 1996.74 MHz, 17-31-00
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,AMCR8,ABM,SSE4A,MASSE,OSVW,TOPEXT,CPCTR,FSGSBASE,BMI1,AVX2,SMEP,BMI2,CLFLUSHOPT,CLWB,SHA,UMIP,IBRS,IBPB,SSBD,IBPB,STIBP,XSAVEOPT,XSAVES
cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 512KB 64b/line
8-way L2 cache, 16MB 64b/line 16-way L3 cache
cpu1: smt 1, core 0, package 0
ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins
acpihpet0 at acpi0: 1 Hz
acpimcfg0 at acpi0
acpimcfg0: addr 0xb000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
"ACPI0006" at acpi0 not configured
acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x
"PNP0A06" at acpi0 not configured
"PNP0A06" at acpi0 not configured
"PNP0A06" at acpi0 not configured
"QEMU0002" at acpi0 not configured
acpicmos0 at acpi0
"ACPI0010" at acpi0 not c
Re: relayd fallback when using tag/tagged
> > > Using such a configuration:
> > > #-8<---
> > > table { 192.0.2.4 }
> > > table { 192.0.2.7}
> > > http protocol www {
> > >block
> > >match request header "Host" value "www.example" tag "example"
> > >pass request tagged "example" forward to
Wouldn't it be wrong if relayd sends the requests to even though
you told him quite clearly to send them to ?
If is down then relayd must error out, or not (because this is
what you told him to do: sending to )
I think you need an additional step between which decides where to send the
request.
Then in next step you can tag and modify...
Maybe I'm wrong but to me it sounds more consistent when doing the
layer 3 redirection on 192.0.2.30 :
table { 192.0.2.4 }
table { 192.0.2.7 }
redirect www {
listen on 192.0.2.30 port 80
forward to check http "/" code 200
forward to check icmp
}
And then do all the layer 7 filtering on 192.0.2.4
But as I said before: maybe I'm wrong ;-)
Re: relayd fallback when using tag/tagged
Le 2/15/24 à 10:33, Michael Hekeler a écrit :
Hello,
I'm trying to configure relayd(8) to use tags, to allow legit host names
only and modify HTTP headers, and fallback. But I can't have it working
properly.
I don't understand exactly what you want to achieve. Do you want:
A. Requests with http header "www.example" going to primary.
And going to fallback if primary is down.
And block all other requests.
or:
B. Request with http header "www.example" going to primary.
And all other going to fallback.
And block nothing (=all requests are served either by primary or
by fallback)
It looks more like A.
I want to relay to the primary by default.
I the primary fails, then I want to relay to a secondary. Which is just
a static webpage saying "work in progress, be back soon".
If A) then put both servers in the table and let HCE decide which host
is up. Something like that (header check ignored in example):
table {192.0.2.4 192.0.2.7}
redirect www {
listen on 192.0.2.30 port 80
forward to check http “/” code 200
}
This implies "mode roundrobin" which is not what I want. The secondary
should only be displayed when the primary is down.
If B) then you need an an additional pass rule in your protocol.
Something like that (to be honest I don't know why you need the tag here
so I ignored that in that example):
http protocol www {
pass request quick header "Host" value "www.example" \
forward to
pass request forward to
block
}
I need tags because the relayd(8) exposes several FQDN and sets various
headers depending on those.
Using such a configuration:
#-8<---
table { 192.0.2.4 }
table { 192.0.2.7}
http protocol www {
block
match request header "Host" value "www.example" tag "example"
pass request tagged "example" forward to
}
relay www {
listen on 192.0.2.30 port 80
protocol www
forward to port 80 check http "/" code 200
forward to port 80
}
#-8<---
forwards all tagged HTTP traffic to the primary server. But if it is turned
off, relayd(8) only replies with error rather than sending the traffic to
the fallback server.
Removing tags and using a simple "pass" directive in protocol (as described
in the man page) does work as expected regarding the fallback server.
Is there a way to use both tags and fallback with relayd(8) to mimic
Apache's Failover[1] configuration with "ProxyPass" and "BalancerMember
(...) status=+H" ?
Thank you,
Joel C.
[1] https://httpd.apache.org/docs/trunk/howto/reverse_proxy.html#failover
--
Bonne journée,
Joel C.
Tél: +33 663541230
Re: relayd fallback when using tag/tagged
> Hello,
>
> I'm trying to configure relayd(8) to use tags, to allow legit host names
> only and modify HTTP headers, and fallback. But I can't have it working
> properly.
I don't understand exactly what you want to achieve. Do you want:
A. Requests with http header "www.example" going to primary.
And going to fallback if primary is down.
And block all other requests.
or:
B. Request with http header "www.example" going to primary.
And all other going to fallback.
And block nothing (=all requests are served either by primary or
by fallback)
If A) then put both servers in the table and let HCE decide which host
is up. Something like that (header check ignored in example):
table {192.0.2.4 192.0.2.7}
redirect www {
listen on 192.0.2.30 port 80
forward to check http “/” code 200
}
If B) then you need an an additional pass rule in your protocol.
Something like that (to be honest I don't know why you need the tag here
so I ignored that in that example):
http protocol www {
pass request quick header "Host" value "www.example" \
forward to
pass request forward to
block
}
>
> Using such a configuration:
> #-8<---
> table { 192.0.2.4 }
> table { 192.0.2.7}
> http protocol www {
> block
> match request header "Host" value "www.example" tag "example"
> pass request tagged "example" forward to
> }
> relay www {
> listen on 192.0.2.30 port 80
> protocol www
> forward to port 80 check http "/" code 200
> forward to port 80
> }
> #-8<---
> forwards all tagged HTTP traffic to the primary server. But if it is turned
> off, relayd(8) only replies with error rather than sending the traffic to
> the fallback server.
>
> Removing tags and using a simple "pass" directive in protocol (as described
> in the man page) does work as expected regarding the fallback server.
>
> Is there a way to use both tags and fallback with relayd(8) to mimic
> Apache's Failover[1] configuration with "ProxyPass" and "BalancerMember
> (...) status=+H" ?
>
> Thank you,
> Joel C.
>
> [1] https://httpd.apache.org/docs/trunk/howto/reverse_proxy.html#failover
>
Re: relayd fallback when using tag/tagged
Le 13/02/2024 à 10:07, Manuel Giraud a écrit :
Joel Carnat writes:
Hello,
I'm trying to configure relayd(8) to use tags, to allow legit host
names only and modify HTTP headers, and fallback. But I can't have it
working properly.
Using such a configuration:
#-8<---
table { 192.0.2.4 }
table { 192.0.2.7}
http protocol www {
block
match request header "Host" value "www.example" tag "example"
pass request tagged "example" forward to
}
I've not tested it but maybe you're missing this last rule in the
previous block:
pass request forward to
That doesn't work either.
If I add it, with or without a tagged directive, it becomes the only
effective rule (last matching rule?) and it never reaches the primary
server.
Re: relayd fallback when using tag/tagged
Joel Carnat writes:
> Hello,
>
> I'm trying to configure relayd(8) to use tags, to allow legit host
> names only and modify HTTP headers, and fallback. But I can't have it
> working properly.
>
> Using such a configuration:
> #-8<---
> table { 192.0.2.4 }
> table { 192.0.2.7}
> http protocol www {
> block
> match request header "Host" value "www.example" tag "example"
> pass request tagged "example" forward to
> }
I've not tested it but maybe you're missing this last rule in the
previous block:
pass request forward to
--
Manuel Giraud
Re: relayd fallback when using tag/tagged
The proposed rules don't seem to change relayd(8)'s behaviour.
It keeps sending HTTP traffic to the primary server and fail when it is
down. The secondary / fallback server is never used.
Starting status:
relayd[26195]: host 192.0.2.7, check http code (14ms,http code ok),
state unknown -> up, availability 100.00%
relayd[26195]: host 192.0.2.4, check http code (44ms,http code ok),
state unknown -> up, availability 100.00%
Stopping the backend server:
*relayd[21988]: host 192.0.2.4, check http code (3ms,http code
malformed), state up -> down, availability 95.65%
relayd[54506]: host 192.0.2.4, check http code (1ms,tcp connect failed),
state up -> down, availability 99.44%*
HTTP request while primary host is down:
relayd[63036]: relay www4tls, session 6 (1 active), example, 1.2.3.4 ->
:0, session failed, [ww.example/] [Host: www.example] [User-Agent:
curl/7.81.0] GET
Le 13/02/2024 à 04:29, l...@trungnguyen.me a écrit :
Hi
On February 13, 2024 12:20:26 AM UTC, Joel Carnat wrote:
Hello,
I'm trying to configure relayd(8) to use tags, to allow legit host names only
and modify HTTP headers, and fallback. But I can't have it working properly.
Using such a configuration:
#-8<---
table { 192.0.2.4 }
table { 192.0.2.7}
http protocol www {
block
match request header "Host" value "www.example" tag "example"
pass request tagged "example" forward to
Try:
match request header "Host" value "www.example" tag example
pass forward to tagged example
}
relay www {
listen on 192.0.2.30 port 80
protocol www
forward to port 80 check http "/" code 200
forward to port 80
}
#-8<---
forwards all tagged HTTP traffic to the primary server. But if it is turned
off, relayd(8) only replies with error rather than sending the traffic to the
fallback server.
What errors are you having?
Removing tags and using a simple "pass" directive in protocol (as described in
the man page) does work as expected regarding the fallback server.
Is there a way to use both tags and fallback with relayd(8) to mimic Apache's Failover[1]
configuration with "ProxyPass" and "BalancerMember (...) status=+H" ?
Thank you,
Joel C.
[1] https://httpd.apache.org/docs/trunk/howto/reverse_proxy.html#failover
https://man.openbsd.org/relayd.conf.5#tag
Re: relayd fallback when using tag/tagged
Hi
On February 13, 2024 12:20:26 AM UTC, Joel Carnat wrote:
>Hello,
>
>I'm trying to configure relayd(8) to use tags, to allow legit host names only
>and modify HTTP headers, and fallback. But I can't have it working properly.
>
>Using such a configuration:
>#-8<---
>table { 192.0.2.4 }
>table { 192.0.2.7}
>http protocol www {
> block
> match request header "Host" value "www.example" tag "example"
> pass request tagged "example" forward to
Try:
match request header "Host" value "www.example" tag example
pass forward to tagged example
>}
>relay www {
> listen on 192.0.2.30 port 80
> protocol www
> forward to port 80 check http "/" code 200
> forward to port 80
>}
>#-8<---
>forwards all tagged HTTP traffic to the primary server. But if it is turned
>off, relayd(8) only replies with error rather than sending the traffic to the
>fallback server.
>
What errors are you having?
>Removing tags and using a simple "pass" directive in protocol (as described in
>the man page) does work as expected regarding the fallback server.
>
>Is there a way to use both tags and fallback with relayd(8) to mimic Apache's
>Failover[1] configuration with "ProxyPass" and "BalancerMember (...)
>status=+H" ?
>
>Thank you,
>Joel C.
>
>[1] https://httpd.apache.org/docs/trunk/howto/reverse_proxy.html#failover
>
https://man.openbsd.org/relayd.conf.5#tag
relayd fallback when using tag/tagged
Hello,
I'm trying to configure relayd(8) to use tags, to allow legit host names
only and modify HTTP headers, and fallback. But I can't have it working
properly.
Using such a configuration:
#-8<---
table { 192.0.2.4 }
table { 192.0.2.7}
http protocol www {
block
match request header "Host" value "www.example" tag "example"
pass request tagged "example" forward to
}
relay www {
listen on 192.0.2.30 port 80
protocol www
forward to port 80 check http "/" code 200
forward to port 80
}
#-8<---
forwards all tagged HTTP traffic to the primary server. But if it is
turned off, relayd(8) only replies with error rather than sending the
traffic to the fallback server.
Removing tags and using a simple "pass" directive in protocol (as
described in the man page) does work as expected regarding the fallback
server.
Is there a way to use both tags and fallback with relayd(8) to mimic
Apache's Failover[1] configuration with "ProxyPass" and "BalancerMember
(...) status=+H" ?
Thank you,
Joel C.
[1] https://httpd.apache.org/docs/trunk/howto/reverse_proxy.html#failover
Re: relayd: "listen on egress" only listens to IPv4 and not IPv6
Thanks for the feedback.
I guess now i have to try and remember what this was about ;-)
/Benno
Stefan R. Filipek(srfili...@gmail.com) on 2024.02.03 09:47:45 -0500:
> Hi all,
>
> Reviving a really old thread, but this problem still exists in 7.4 and
> is impacting my use case as well.
>
> However, I can confirm that this patch does fix the issue. An
> additional "struct keyname *name;" was required in the function, but
> otherwise it works as-is.
>
> Best,
> Stefan
>
>
>
> On Tue, Sep 17, 2019 at 2:03???PM Muhammad Kaisar Arkhan
> wrote:
> >
> > Hi,
> >
> > No, not yet. I've been busy with life atm (Uni just started and other
> > stuff). I'm hoping to test it this weekend.
> >
> > Thanks.
> >
> >
> > Le September 17, 2019 ?? 1:51 PM Sebastian Benoit
> > <http://benoit-li...@fb12.de > a ??crit:
> >
> > > Hi,
> > >
> > > did you manage to test the diff?
> > >
> > > /Benno
> > >
> > > Sebastian Benoit(benoit-li...@fb12.de) on 2019.09.01 17:05:34 +0200:
> > >
> > > > > Sebastian Benoit(benoit-li...@fb12.de) on 2019.09.01 16:44:37
> > > +0200:
> > > >
> > > > > > > Muhammad Kaisar Arkhan(h...@yukiisbo.red) on
> > > > 2019.08.29 14:55:03 +0200:
> > > > >
> > > > > > > > > Hi Tom,
> > > > > >
> > > > > >
> > > > > > > > > > > listen on
> > > > > > 2a03:6000:9106::50f7:f07a:d1cc port 443 tls
> > > > > > >
> > > > > > > > > > > I've tried this before,
> > > > > > > it just results in this:
> > > > > >
> > > > > > /etc/relayd.conf:33: cannot load certificates for
> > > > > > relay https2:443
> > > > > >
> > > > > > > > > Your error says "for relay https2",
> > > > > > but the relayd.conf file you quote does
> > > > > not have a relay "https2".
> > > > >
> > > > > Please show the output of "relayd -nvv" and *exactly* the
> > > > > /etc/relayd.conf
> > > > > file at the time when you ran the command.
> > > > >
> > > > > > > sorry, my mistake: the https2 there is fine, it
> > > > > comes from the second
> > > > "listen ..." directive.
> > > >
> > > > I think i found the issue: relays with multiple listen
> > > > statements do not
> > > > work with keypair currently.
> > > >
> > > > Can you test this diff with a config that has a listen on the
> > > > v4 adress and
> > > > a listen on the v6 adress, not the "egress" method.
> > > >
> > > > If it does not work, please show again your config and "relayd
> > > > -nvv".
> > > >
> > > > /Benno
> > > >
> > > > diff --git usr.sbin/relayd/parse.y usr.sbin/relayd/parse.y
> > > > index c6e2bcacdfb..8338d5c9e6d 100644
> > > > --- usr.sbin/relayd/parse.y
> > > > +++ usr.sbin/relayd/parse.y
> > > > @@ -3323,11 +3312,19 @@ relay_inherit(struct relay *ra, struct
> > > > relay *rb)
> > > > goto err;
> > > > }
> > > >
> > > > - if (relay_load_certfiles(conf, rb, NULL) == -1) {
> > > > + if (TAILQ_EMPTY(>rl_proto->tlscerts) &&
> > > > + relay_load_certfiles(conf, rb, NULL) == -1) {
> > > > yyerror("cannot load certificates for relay %s",
> > > > rb->rl_conf.name);
> > > > goto err;
> > > > }
> > > > + TAILQ_FOREACH(name, >rl_proto->tlscerts, entry) {
> > > > + if (relay_load_certfiles(conf, rb, name->name) == -1) {
> > > > + yyerror("cannot load keypair %s for relay %s",
> > > > + name->name, rb->rl_conf.name);
> > > > + goto err;
> > > > + }
> > > > + }
> > > >
> > > > TAILQ_FOREACH(rta, >rl_tables, rlt_entry) {
> > > > if ((rtb = calloc(1, sizeof(*rtb))) == NULL) {
> > > >
> > > > > --
> > >
>
--
Re: relayd: "listen on egress" only listens to IPv4 and not IPv6
Hi all,
Reviving a really old thread, but this problem still exists in 7.4 and
is impacting my use case as well.
However, I can confirm that this patch does fix the issue. An
additional "struct keyname *name;" was required in the function, but
otherwise it works as-is.
Best,
Stefan
On Tue, Sep 17, 2019 at 2:03 PM Muhammad Kaisar Arkhan
wrote:
>
> Hi,
>
> No, not yet. I've been busy with life atm (Uni just started and other stuff).
> I'm hoping to test it this weekend.
>
> Thanks.
>
>
> Le September 17, 2019 à 1:51 PM Sebastian Benoit <http://benoit-li...@fb12.de
> > a écrit:
>
> > Hi,
> >
> > did you manage to test the diff?
> >
> > /Benno
> >
> > Sebastian Benoit(benoit-li...@fb12.de) on 2019.09.01 17:05:34 +0200:
> >
> > > > Sebastian Benoit(benoit-li...@fb12.de) on 2019.09.01 16:44:37
> > +0200:
> > >
> > > > > > Muhammad Kaisar Arkhan(h...@yukiisbo.red) on 2019.08.29
> > > 14:55:03 +0200:
> > > >
> > > > > > > > Hi Tom,
> > > > >
> > > > >
> > > > > > > > > > listen on
> > > > > 2a03:6000:9106::50f7:f07a:d1cc port 443 tls
> > > > > >
> > > > > > > > > > I've tried this before, it
> > > > > > just results in this:
> > > > >
> > > > > /etc/relayd.conf:33: cannot load certificates for
> > > > > relay https2:443
> > > > >
> > > > > > > > Your error says "for relay https2", but
> > > > > the relayd.conf file you quote does
> > > > not have a relay "https2".
> > > >
> > > > Please show the output of "relayd -nvv" and *exactly* the
> > > > /etc/relayd.conf
> > > > file at the time when you ran the command.
> > > >
> > > > > > sorry, my mistake: the https2 there is fine, it
> > > > comes from the second
> > > "listen ..." directive.
> > >
> > > I think i found the issue: relays with multiple listen statements
> > > do not
> > > work with keypair currently.
> > >
> > > Can you test this diff with a config that has a listen on the v4
> > > adress and
> > > a listen on the v6 adress, not the "egress" method.
> > >
> > > If it does not work, please show again your config and "relayd
> > > -nvv".
> > >
> > > /Benno
> > >
> > > diff --git usr.sbin/relayd/parse.y usr.sbin/relayd/parse.y
> > > index c6e2bcacdfb..8338d5c9e6d 100644
> > > --- usr.sbin/relayd/parse.y
> > > +++ usr.sbin/relayd/parse.y
> > > @@ -3323,11 +3312,19 @@ relay_inherit(struct relay *ra, struct
> > > relay *rb)
> > > goto err;
> > > }
> > >
> > > - if (relay_load_certfiles(conf, rb, NULL) == -1) {
> > > + if (TAILQ_EMPTY(>rl_proto->tlscerts) &&
> > > + relay_load_certfiles(conf, rb, NULL) == -1) {
> > > yyerror("cannot load certificates for relay %s",
> > > rb->rl_conf.name);
> > > goto err;
> > > }
> > > + TAILQ_FOREACH(name, >rl_proto->tlscerts, entry) {
> > > + if (relay_load_certfiles(conf, rb, name->name) == -1) {
> > > + yyerror("cannot load keypair %s for relay %s",
> > > + name->name, rb->rl_conf.name);
> > > + goto err;
> > > + }
> > > + }
> > >
> > > TAILQ_FOREACH(rta, >rl_tables, rlt_entry) {
> > > if ((rtb = calloc(1, sizeof(*rtb))) == NULL) {
> > >
> > > > --
> >
Re: relayd forward with tls
> Where can I read about the meaning of each field in relayd log? Like you > said, that 0 is related to the tag one set on the protocol. I can't tell where to find documentation for relayd's log. But - to be honest - I found it was not too hard to work with. For playing with relayd and httpd I suggest Michael W Lucas's book "Relayd and Httpd Mastery". Mr. Lucas, has a way of writing that is easy to read! https://mwl.io/nonfiction/tools#relayd ...and of course the excellent manpages relayd(8), relayd.conf(5)
Re: relayd forward with tls
> Em qui., 11 de jan. de 2024 às 13:35, Michael Hekeler
> escreveu:
> >
> > > 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
> >
> > Please examine your log:
> > The first and the second request are processed by "relay wwwtls"
> > The first is tagged "fqdn1" and the second request is tagged "fqdn2"
> > The first is relayed to 127.0.0.1:8080
> > The second is relayed to 127.0.0.1:8081
> > All is fine here :-)
> >
> > Now look to the third and fourth requests.
> > They are both processed by wwwtls2.
> > But they are not tagged (see tag 0) and thats the problem!
> > Because the request stays untagged in the protocol the relay wwwtls2
> > chooses simply the first found forward rule: 127.0.0.1:8080
> >
> > So examine your requests:
> > This is fine: 'curl https://fqdn1'
> > But this not: 'curl https://fqdn1:4430'
> >
> > See the difference?
> >
> > The second sets in HTTP-Header "[HTTP_HOST] => fqdn1:4430"
> > Thats why you should match "fqdn1:4430" in relayd.conf:
> >
> > match request header "Host" value "fqdn1:4430" tag "fqdn1"
> > - or -
> > match request header "Host" value "fqdn1*" tag "fqdn1"
> >
>
> That was exactly the problem.
> I didn't know how to read the logs nor the definition of HTTP_HOST.
Most browsers can show the HTTP-Header.
E.g. in firefox -> developer tools -> network -> just click on any
object and it will show headers (and much more)
Or you can place a simple script in httpd that dumps the header.
In PHP for example you can do: print_r($_SERVER);
What I do is placing a simple C program in /cgi-bin:
#include
int
main(int argc, char *argv[])
{
extern char **environ;
printf("Content-Type: text/plain\n\n");
for (int i = 0; environ[i] != NULL; i++) {
printf("%s\n", environ[i]);
}
}
Re: relayd forward with tls
> 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"
This has nothing to do with relayd's forwarding rules in this topic.
Setting these headers is for logging in httpd.
Because if not set X-Forwarded-For then httpd logs the IP of the relayd
host as source for ALL requests and the original IP of the request would
be lost.
To overcome this httpd comes with a log format called "forwarded" which
appends X-Forwarded-{For,Port} to existing log format.
Re: relayd forward with tls
Em qui., 11 de jan. de 2024 às 13:35, Michael Hekeler escreveu: > > > 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 > > Please examine your log: > The first and the second request are processed by "relay wwwtls" > The first is tagged "fqdn1" and the second request is tagged "fqdn2" > The first is relayed to 127.0.0.1:8080 > The second is relayed to 127.0.0.1:8081 > All is fine here :-) > > Now look to the third and fourth requests. > They are both processed by wwwtls2. > But they are not tagged (see tag 0) and thats the problem! > Because the request stays untagged in the protocol the relay wwwtls2 > chooses simply the first found forward rule: 127.0.0.1:8080 > > So examine your requests: > This is fine: 'curl https://fqdn1' > But this not: 'curl https://fqdn1:4430' > > See the difference? > > The second sets in HTTP-Header "[HTTP_HOST] => fqdn1:4430" > Thats why you should match "fqdn1:4430" in relayd.conf: > > match request header "Host" value "fqdn1:4430" tag "fqdn1" > - or - > match request header "Host" value "fqdn1*" tag "fqdn1" > That was exactly the problem. I didn't know how to read the logs nor the definition of HTTP_HOST. Thank you very much! -- Adriano
Re: relayd forward with tls
> 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 Please examine your log: The first and the second request are processed by "relay wwwtls" The first is tagged "fqdn1" and the second request is tagged "fqdn2" The first is relayed to 127.0.0.1:8080 The second is relayed to 127.0.0.1:8081 All is fine here :-) Now look to the third and fourth requests. They are both processed by wwwtls2. But they are not tagged (see tag 0) and thats the problem! Because the request stays untagged in the protocol the relay wwwtls2 chooses simply the first found forward rule: 127.0.0.1:8080 So examine your requests: This is fine: 'curl https://fqdn1' But this not: 'curl https://fqdn1:4430' See the difference? The second sets in HTTP-Header "[HTTP_HOST] => fqdn1:4430" Thats why you should match "fqdn1:4430" in relayd.conf: match request header "Host" value "fqdn1:4430" tag "fqdn1" - or - match request header "Host" value "fqdn1*" tag "fqdn1"
Re: relayd forward with tls
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
> :
> >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 { 127.0.0.1 }
> >> > > > > > table { 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
> >> > > > > >
> >> > > > > >match request header "Host" value "fqdn2" tag "fqdn2"
> >> > > > > >pass request tagged "fqdn2" forward to
> >> > > > > > }
> >> > > > > >
> >> > > > > > relay wwwtls {
> >> > > > > >listen on egress port 443 tls
> >> > > > > >protocol https
> >> > > > > >forward to port 80
> >> > > > > >forward with tls to 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
> >> > >
Re: relayd forward with tls
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"
I could post an example when I'm back at my machine.
Am 8. Januar 2024 23:51:33 MEZ schrieb Adriano Barbosa :
>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 { 127.0.0.1 }
>> > > > > > table { 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
>> > > > > >
>> > > > > >match request header "Host" value "fqdn2" tag "fqdn2"
>> > > > > >pass request tagged "fqdn2" forward to
>> > > > > > }
>> > > > > >
>> > > > > > relay wwwtls {
>> > > > > >listen on egress port 443 tls
>> > > > > >protocol https
>> > > > > >forward to port 80
>> > > > > >forward with tls to 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
>> > > > Server 1
>> > > > stable# curl --insecure https://fqdn2
>> > > > Server 2
>> > > >
>> > > > With port 4430 and allegedly any port other than 80 and 443:
>> > > > stable# curl --insecure https://fqdn1:4430
>> > > > Server 1
>> > > > stable# curl --insecure https://fqdn2:4430
>> > > > Server 1
>> > > >
>> > > What does curl -vk show?
>> > >
>> >
>> > Unfortunately, no difference. Follows:
>> >
>> > $ curl --insecure -vk https://fqdn2
>> > * Host fqdn2:443 was resolved.
>> > * IPv6: (none)
>> > * IPv4:
Re: relayd forward with tls
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 { 127.0.0.1 }
> > > > > > table { 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
> > > > > >
> > > > > >match request header "Host" value "fqdn2" tag "fqdn2"
> > > > > >pass request tagged "fqdn2" forward to
> > > > > > }
> > > > > >
> > > > > > relay wwwtls {
> > > > > >listen on egress port 443 tls
> > > > > >protocol https
> > > > > >forward to port 80
> > > > > >forward with tls to 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
> > > > Server 1
> > > > stable# curl --insecure https://fqdn2
> > > > Server 2
> > > >
> > > > With port 4430 and allegedly any port other than 80 and 443:
> > > > stable# curl --insecure https://fqdn1:4430
> > > > Server 1
> > > > stable# curl --insecure https://fqdn2:4430
> > > > Server 1
> > > >
> > > 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
&
Re: relayd forward with tls
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 { 127.0.0.1 }
table { 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
match request header "Host" value "fqdn2" tag "fqdn2"
pass request tagged "fqdn2" forward to
}
relay wwwtls {
listen on egress port 443 tls
protocol https
forward to port 80
forward with tls to 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
Server 1
stable# curl --insecure https://fqdn2
Server 2
With port 4430 and allegedly any port other than 80 and 443:
stable# curl --insecure https://fqdn1:4430
Server 1
stable# curl --insecure https://fqdn2:4430
Server 1
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
<
Server 2
* 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
<
Server 1
* 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
Re: relayd forward with tls
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 { 127.0.0.1 }
> > > > table { 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
> > > >
> > > > match request header "Host" value "fqdn2" tag "fqdn2"
> > > > pass request tagged "fqdn2" forward to
> > > > }
> > > >
> > > > relay wwwtls {
> > > > listen on egress port 443 tls
> > > > protocol https
> > > > forward to port 80
> > > > forward with tls to 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
> > Server 1
> > stable# curl --insecure https://fqdn2
> > Server 2
> >
> > With port 4430 and allegedly any port other than 80 and 443:
> > stable# curl --insecure https://fqdn1:4430
> > Server 1
> > stable# curl --insecure https://fqdn2:4430
> > Server 1
> >
> 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
<
Server 2
* 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
Re: relayd forward with tls
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 { 127.0.0.1 }
table { 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
match request header "Host" value "fqdn2" tag "fqdn2"
pass request tagged "fqdn2" forward to
}
relay wwwtls {
listen on egress port 443 tls
protocol https
forward to port 80
forward with tls to 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
Server 1
stable# curl --insecure https://fqdn2
Server 2
With port 4430 and allegedly any port other than 80 and 443:
stable# curl --insecure https://fqdn1:4430
Server 1
stable# curl --insecure https://fqdn2:4430
Server 1
What does curl -vk show?
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 { 127.0.0.1 }
table { 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
match request header "Host" value "fqdn2" tag "fqdn2"
pass request tagged "fqdn2" forward to
}
http protocol https2 {
tls keypair fqdn1
tls keypair fqdn2
match request header "Host" value "fqdn1" tag "fqdn1"
pass request tagged "fqdn1" forward to
match request header "Host" value "fqdn2" tag "fqdn2"
pass request tagged "fqdn2" forward to
}
relay wwwtls {
listen on $addr port 443 tls
protocol https
forward to port 8080
forward to port 8081
}
relay wwwtls2 {
listen on $addr port 4430 tls
protocol https2
forward to port 8080
forward to port 8081
}
# 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"
}
}
Re: relayd forward with tls
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 { 127.0.0.1 }
> > table { 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
> >
> > match request header "Host" value "fqdn2" tag "fqdn2"
> > pass request tagged "fqdn2" forward to
> > }
> >
> > relay wwwtls {
> > listen on egress port 443 tls
> > protocol https
> > forward to port 80
> > forward with tls to 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
Server 1
stable# curl --insecure https://fqdn2
Server 2
With port 4430 and allegedly any port other than 80 and 443:
stable# curl --insecure https://fqdn1:4430
Server 1
stable# curl --insecure https://fqdn2:4430
Server 1
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 { 127.0.0.1 }
table { 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
match request header "Host" value "fqdn2" tag "fqdn2"
pass request tagged "fqdn2" forward to
}
http protocol https2 {
tls keypair fqdn1
tls keypair fqdn2
match request header "Host" value "fqdn1" tag "fqdn1"
pass request tagged "fqdn1" forward to
match request header "Host" value "fqdn2" tag "fqdn2"
pass request tagged "fqdn2" forward to
}
relay wwwtls {
listen on $addr port 443 tls
protocol https
forward to port 8080
forward to port 8081
}
relay wwwtls2 {
listen on $addr port 4430 tls
protocol https2
forward to port 8080
forward to port 8081
}
# 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"
}
}
Re: relayd forward with tls
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 { 127.0.0.1 }
table { 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
match request header "Host" value "fqdn2" tag "fqdn2"
pass request tagged "fqdn2" forward to
}
relay wwwtls {
listen on egress port 443 tls
protocol https
forward to port 80
forward with tls to 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
relayd forward with tls
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 { 127.0.0.1 }
table { 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
match request header "Host" value "fqdn2" tag "fqdn2"
pass request tagged "fqdn2" forward to
}
relay wwwtls {
listen on egress port 443 tls
protocol https
forward to port 80
forward with tls to port 443
}
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
Re: relayd https inspection certificate issue
On 2023-12-11 14:06, Philipp Benner wrote: Thank you for the infomation Claudio! What a pitty! I thought I found a tiny solution there. Do you have any suggestions for an alternative? I don'´t want to install squid becaus of limited ressources on this machine. Any ideas? Or should I try nginx? Hi list, Just wondering the same question - is there a open source TLS inspection proxy that anyone can recommend besides using relayd's functionality for this ? Thanks, - J
Re: Relayd - block bad bots
> Hey > > I'm running a small VM on OpenBSD where my site resides. My stack is > pf/relayd/httpd. > > I see a significant traffic coming from bad bots, like mj12. I'd love > to completely block them and Relayd seems like the best place. I tried to > block by "User-Agent" header, however there is no support for globs > there. > Has anyone had any success with achieving something similiar? block request header "User-Agent" value "curl*"
Re: relayd https inspection certificate issue
Thank you for the infomation Claudio! What a pitty! I thought I found a tiny solution there. Do you have any suggestions for an alternative? I don'´t want to install squid becaus of limited ressources on this machine. Any ideas? Or should I try nginx? Thank you! -Ursprüngliche Nachricht- Von: Claudio Jeker Gesendet: Samstag, 9. Dezember 2023 10:02 An: Philipp Benner Cc: misc@openbsd.org Betreff: Re: relayd https inspection certificate issue On Fri, Dec 08, 2023 at 10:04:25PM +, Philipp Benner wrote: > Dear all, > > > I would like to use relayd as an outbound https proxy, so I configured it > like shown in the last section of the relayd.conf(5) manpage. > > This works fine for e.g. wikipedia.org. The certificate issued by my relay is > nearly the same as the original, except oft he issuer of course. > > But when I try to visit e.g. heise.de, at least all images refuse to load. > After some research I found out the following. > > When visiting the site directly without proxy, I can see that the > images are loaded from https://heise.cloudimg.io. If I open an image > in a new browser, I can also see that the certificates applicant is > 2e26bae.cloudimg.io, alternative applicants are heise-aws.cloudimg.io > and heise.cloudimg.io > > Now if I use the relayd proxy and try to open an image in a seperate > browser, the url is the same https://heise.cloudimg.io/... but the > certificates is different. Its applicant now is a.248.e.akamai.net and > alternatively *.akamaized.net and some other *.akamai… > > So the self-issued certificate has completely other applicants than > the original and of course doesn‘t match the actual server name and I > get the error ERR_CERT_COMMON_NAME_INVALID > > > Can anybody help or give advice? Don't do it. This "TLS inspection" mode is broken and it is close to impossible to fix it. The way the MITM cert is built is not smart enough and does not consider many special cases like SAN certs and OCSP. It works for simple things but does not work as a generic SSL interceptor. -- :wq Claudio
Re: relayd https inspection certificate issue
On 2023-12-09 04:02, Claudio Jeker wrote: Don't do it. This "TLS inspection" mode is broken and it is close to impossible to fix it. The way the MITM cert is built is not smart enough and does not consider many special cases like SAN certs and OCSP. It works for simple things but does not work as a generic SSL interceptor. Hi Claudio and list, Ah, I was experimenting with this this week and couldn't understand why I was getting similar errors. I'd still like TLS inspection on one of my routers and while I usually try to stick with the tools that ship with each OpenBSD install, I was wondering if anyone could recommend any third party software with a good security track record ? I believe nginx can operate as a reverse proxy / application layer gateway ... can it also do TLS inspection for user traffic ? Thanks, - J
Re: relayd https inspection certificate issue
On Fri, Dec 08, 2023 at 10:04:25PM +, Philipp Benner wrote: > Dear all, > > > I would like to use relayd as an outbound https proxy, so I configured it > like shown in the last section of the relayd.conf(5) manpage. > > This works fine for e.g. wikipedia.org. The certificate issued by my relay is > nearly the same as the original, except oft he issuer of course. > > But when I try to visit e.g. heise.de, at least all images refuse to load. > After some research I found out the following. > > When visiting the site directly without proxy, I can see that the images are > loaded from https://heise.cloudimg.io. If I open an image in a new browser, I > can also see that the certificates applicant is 2e26bae.cloudimg.io, > alternative applicants are heise-aws.cloudimg.io and heise.cloudimg.io > > Now if I use the relayd proxy and try to open an image in a seperate browser, > the url is the same https://heise.cloudimg.io/... but the certificates is > different. Its applicant now is a.248.e.akamai.net and alternatively > *.akamaized.net and some other *.akamai… > > So the self-issued certificate has completely other applicants than the > original and of course doesn‘t match the actual server name and I get the > error ERR_CERT_COMMON_NAME_INVALID > > > Can anybody help or give advice? Don't do it. This "TLS inspection" mode is broken and it is close to impossible to fix it. The way the MITM cert is built is not smart enough and does not consider many special cases like SAN certs and OCSP. It works for simple things but does not work as a generic SSL interceptor. -- :wq Claudio
relayd https inspection certificate issue
Dear all, I would like to use relayd as an outbound https proxy, so I configured it like shown in the last section of the relayd.conf(5) manpage. This works fine for e.g. wikipedia.org. The certificate issued by my relay is nearly the same as the original, except oft he issuer of course. But when I try to visit e.g. heise.de, at least all images refuse to load. After some research I found out the following. When visiting the site directly without proxy, I can see that the images are loaded from https://heise.cloudimg.io. If I open an image in a new browser, I can also see that the certificates applicant is 2e26bae.cloudimg.io, alternative applicants are heise-aws.cloudimg.io and heise.cloudimg.io Now if I use the relayd proxy and try to open an image in a seperate browser, the url is the same https://heise.cloudimg.io/... but the certificates is different. Its applicant now is a.248.e.akamai.net and alternatively *.akamaized.net and some other *.akamai… So the self-issued certificate has completely other applicants than the original and of course doesn‘t match the actual server name and I get the error ERR_CERT_COMMON_NAME_INVALID Can anybody help or give advice? Thank you very much!
Relayd - block bad bots
Hey I'm running a small VM on OpenBSD where my site resides. My stack is pf/relayd/httpd. I see a significant traffic coming from bad bots, like mj12. I'd love to completely block them and Relayd seems like the best place. I tried to block by "User-Agent" header, however there is no support for globs there. This means I would need to constantly adjust my filters when they release new version into the wild. Has anyone had any success with achieving something similiar? Frankly I was a bit surprised that globs in value are not supported. Seems like a great use case. --- Michal
relayd checks and uses disabled hosts
Hi,
I have a strange behavior on my relayd servers. Relayd continues checking
disabled hosts. I see it on backend server's logs.
If relayd detects a down -> up of the service it re-adds the hosts in the table
and passes traffic to the disabled hosts.
Status remains disabled.
Setup is with redirects.
table { ldap1 retry 2, ldap2 retry 2 }
redirect ldap {
listen on $ldap_addr port ldaps
pftag RELAYD_ldap
forward to port 1636 mode least-states check icmp check script
"/usr/local/sbin/check_ldap_c" demote 0relay timeout 2000
session timeout 432600
}
On load balancer hosts I see:
pfctl -a 'relayd/ldap' -t ldap -Tshow
ldap1_IP
ldap2_IP
If I do
relayctl host dis ldap2
I see in logs
Dec 1 13:11:24 relayd[59724]: table ldap: 0 added, 1 deleted, 0 changed, 0
killed
# relayctl show sum|grep ldap
1 redirect ldap active
1 table ldap:1636 active (1 hosts)
1 host ldap1 100.00% up
2 host ldap2 disabled
# pfctl -a 'relayd/ldap' -t ldap -Tshow
ldap1_IP (only)
So far, so good. However...
However, when I actually close the service on server ldap2 I see:
Dec 1 13:12:27 relayd[42873]: host ldap2, check script (766ms,script failed),
state up -> down, availability 98.29%
Dec 1 13:12:27 relayd[71859]: table ldap: 0 added, 0 deleted, 0 changed, 0
killed
Now, when I restart the server or the service on ldap2:
Dec 1 13:17:08 relayd[42873]: host ldap2, check script (987ms,script ok),
state down -> up, availability 98.28%
Dec 1 13:17:12 relayd[71859]: table ldap: 1 added, 0 deleted, 0 changed, 0
killed
# relayctl show sum|grep ldap2
2 host ldap2 disabled
Hosts is shown as disabled, but it's added the table.
# pfctl -a 'relayd/ldap' -t ldap -Tshow
ldap1_IP
ldap2_IP
again:
# relayctl host dis ldap2
command succeeded.
# pfctl -a 'relayd/ldap' -t ldap -Tshow
ldap1_IP
ldap2_IP
During this whole time while ldap2 is disabled I keep seeing in ldap2's logs
connects from the load balancer although it's disabled. Logs from the check
script.
When the check sees the service down->up, it re-enables the host although in
summary it's still stated as disabled.
Clients are also coming now apart from the check script.
If I re-enable the disabled host:
# relayctl host en ldap2
command succeeded
Dec 1 13:24:35 relayd[99810]: host ldap2, check script (796ms,script ok),
state unknown -> up, availability 100.00%
Dec 1 13:24:39 relayd[59724]: table ldap: 0 added, 0 deleted, 0 changed, 0
killed
I checked web csv but can't see any related change on relayd...
On August and 7.3 this didn't happen.
Giannis
Re: relayd checks and uses disabled hosts
On 01/12/2023 13:30, Kapetanakis Giannis wrote: > I checked web csv but can't see any related change on relayd... > > On August and 7.3 this didn't happen. Not relevant. I'm not on current, I run release. G
Relayd routers question for 2 ISPs
Hi folks,
I found the routers section in the man page, and then also found this email.
https://marc.info/?l=openbsd-misc=125232531402942=2
I *think* I got it to work but I want to double check.
Here is a summarization of what I did in Vmware.
Client -> gateway(NAT) -> ISP1
Client -> gateway(NAT) -> ISP2
Gateway has the standard relayd.conf lines.
table { 10.0.3.10 ip ttl 1, 10.0.4.10 ip ttl 1 } router "uplinks"
{
route 0.0.0.0/0
forward to check icmp
}
Gateway also has these pf.conf lines for NAT.
ext_if1="em0"
ext_if2="em1"
int_if="em2"
internal_net="192.0.2.0/24"
match out on $ext_if1 from $internal_net to any nat-to ($ext_if1)
match out on $ext_if2 from $internal_net to any nat-to ($ext_if2)
pass out on {$ext_if1, $ext_if2} from $internal_net to any
pass in on $int_if from $internal_net to any
What I notice is that I can do this:
1) Client: start a ping
2) Gateway: disconnect the first interface
3) Client: ping stops working
4) Client: Control-C and do another ping, ping works
5) Gateway: re-connect the first one
6) Gateway: disconnect the second one
7) Client: ping stops working
8) Client: Control-C and do another ping, ping works
Am I in the right ballpark of how this is supposed to be configured?
Is there any way for the gateway to magically change the same
connection/packets to the other interface when the first interface dies?
Thanks for any help.
V/r,
Bryan
Relayd with 2 interfaces
hi
i would to like setup an vm that run relayd with an inbound interfaces
and an outbound interface.
vm host -> openbsd 7.3
i setup an vm with openbsd 7.3 with 2 interfaces
net.ip.inet.forward=0
vio0 inbound
vio0 outbound, on this interfaces is also setup the default gw for the vm.
both veb's for the vm lives in seperate rdomain . ( inbound rtable 15 ,
outbound rtable 25 )
the relayd destination webserver lives in an aditional rdomain ( rdomain
120 )
i add rdr-rules for the vm vio0 interface inbound ( 10.0.99.2 )
pass in on lan inet proto tcp from lan:network to $my_webserver_domain
port 80 rtable 15 rdr-to 10.0.99.2
i add also rules vor outbound ( rdomain 25 )
pass in quick on vport25 inet proto icmp from any to dmz:network rtable 120
pass in quick on vport25 inet proto tcp from any to 192.168.135.11 port
80 rtable 120
on vm :
i can ping the dmz hosts and also connect port 80 .
i see the incoming packets on vio0 with tcpdump.
vm can reach outbound internet and the dmz systems
on vm host
an connect by telnet -V 15 10.0.99.2 works
relayd conf on vm:
alg# cat relayd.conf
alg_ip4="10.0.99.2"
log connection
log state changes
log host checks
timeout 200
interval 5
domain1="192.168.135.11"
table { $domain1 }
http protocol p_http {
# Return HTTP/HTML error pages to the client
return error
# your web application might need these headers
match request header set "X-Forwarded-For" value "$REMOTE_ADDR"
match request header set "X-Forwarded-By" value
"$SERVER_ADDR:$SERVER_PORT"
match header set "Connection" value "close"
pass
}
relay reverse_proxy_http {
listen on $alg_ip4 port 80
protocol p_http
forward to port 80 check http "/" code 200
}
the problem is , if i try to connect the domain1.de from my lan (
rdr-rule inbound ) the connection
will not work .
on vm:
i see the redirected inbound traffic on vio0 ,
i see traffic between relayd and the backend server on vio1,
but i don't see the backend server answer on vio0.
i try this with inet.forward=1 but same result.
can relayd handle this setup with inbound and outbound traffic on
seperate interfaces ?
if you need addidional informantion please let me know.
thanks for help
Holger
Re: relayd and large POST requests
> before going any deeper in investigating the behaviour I would suggest > to configure this setup with using redirection. > I think you are better with just forwarding on layer 3. > > Or did I miss something? Why did you choose relay here? relayd is used here as tls termination proxy, since varnish does not support tls.
Re: relayd and large POST requests
> Hi,
>
> I'm running a setup on OpenBSD 7.3 (amd64, 16GB RAM) with relayd,
> varnish, httpd and php-fpm. When uploading a large >2GB file through
> ...
>
>
> /etc/relayd.conf:
>
> table { 127.0.0.1 }
>
> log connection
>
> http protocol "https" {
> tls keypair "server"
> return error
> pass
> }
>
> relay "mysite4" {
> listen on xxx port 443 tls
> protocol "https"
> forward to port 8443 check tcp
> }
>
before going any deeper in investigating the behaviour I would suggest
to configure this setup with using redirection.
I think you are better with just forwarding on layer 3.
Or did I miss something? Why did you choose relay here?
Re: relayd and large POST requests
> Actually I can't be sure this the origin of your problem, but the > value of "memory_limit" is wrong. Thank you, I increased php memory limit but the problem persists unfortunately. In fact this 3000M file upload freezes our 16G machine even when there is no other workload, so that's a significant issue. Has anyone else run into this problem?
Re: relayd and large POST requests
Actually I can't be sure this the origin of your problem, but the value of "memory_limit" is wrong. >From the doc: https://www.php.net/manual/en/ini.core.php#ini.post-max-size post_max_size int Sets max size of post data allowed. This setting also affects file upload. To upload large files, this value must be larger than upload_max_filesize. Generally speaking, memory_limit should be larger than post_max_size. When an int is used, the value is measured in bytes. Shorthand notation, as described in this FAQ, may also be used doc for memory_limit: https://www.php.net/manual/en/ini.core.php#ini.memory-limit Take it like one more hint but I personally gave up with *shorthand notation* specifying the value of all these php settings. If you go to complete your php app with a javascript checking your php config the shorthand notation read by ini_gets makes soon fail your javascripts. Erwin Geerdink wrote: > php.ini: > > upload_max_filesize = 4096M > post_max_size = 4096M > memory_limit = 256M > max_execution_time = 300
Re: relayd and large POST requests
> Can you post from your php.ini what you did set for the following
> values?
php.ini:
upload_max_filesize = 4096M
post_max_size = 4096M
memory_limit = 256M
max_execution_time = 300
httpd.conf:
connection {
max request body 4294967296 # 4096M
}
I'm able to reproduce the problem locally with identical setup.
Transfer is then a matter of seconds and timeout should not be an issue.
Uploading a 3000M file with increased login.conf limits succeeds,
but sometimes results in very high memory consumption first by relayd
and then followed by httpd, as observed with top:
PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND
56119 _relayd20 8198M 7117M sleep/1 kqread0:20 25.78% relayd
15048 www20 4101M 4105M sleep/3 kqread0:32 24.71% httpd
As mentioned, other times relayd's memory usage just remains low (few Mb)
while the data is passed on to varnish/httpd (which does have increased
memory usage while flushing the data to disk)
Kind regards,
Erwin
Re: relayd and large POST requests
Can you post from your php.ini what you did set for the following values? upload_max_filesize = post_max_size = memory_limit = Despite the allocation memory problem (from the error message) I would also suggest you to double check %request timeout% settings starting from php.ini: max_execution_time = to end to varnish (passing by httpd). -- Daniele Bonini Erwin Geerdink wrote: > *occassionally* > > relayd[572]: relay mysite4, session 14 (1 active), > 0, xxx -> 127.0.0.1:8443, Cannot allocate memory (500 Internal > Server Error), POST: Undefined error: 0 > > There is no temporary file created in /var/www/tmp.
relayd and large POST requests
Hi,
I'm running a setup on OpenBSD 7.3 (amd64, 16GB RAM) with relayd,
varnish, httpd and php-fpm. When uploading a large >2GB file through
our web application, *occassionally* relayd starts to consume an
increasing amount of memory (as observed with top) until it hits
resource limits from login.conf and the file upload terminates
prematurely. In /var/log/daemon:
relayd[572]: relay mysite4, session 14 (1 active),
0, xxx -> 127.0.0.1:8443, Cannot allocate memory (500 Internal
Server Error), POST: Undefined error: 0
There is no temporary file created in /var/www/tmp.
*Sometimes* the upload does succeed, in that case memory usage of
relayd remains low and the data is being flushed to disk (a growing
temporary file in /var/www/tmp).
File uploads appear to work fine when relayd is taken out of
the loop. Obviously I could tweak login.conf, but the high memory
consumption (although temporary) may also cause other problems.
Why does relayd sometimes buffer "the whole file" in memory? Can this be
configured somehow?
Possibly related but very old, no solution:
https://marc.info/?l=openbsd-misc=132588522002336=2
Kind regards,
Erwin
/etc/relayd.conf:
table { 127.0.0.1 }
log connection
http protocol "https" {
tls keypair "server"
return error
pass
}
relay "mysite4" {
listen on xxx port 443 tls
protocol "https"
forward to port 8443 check tcp
}
Re: relayd ssl termination advice
Oooo I wasn't familiar with sniproxy. I DO have a working haproxy configuration, and even though it is good software, I find myself barely understanding and was wanting something simpler. sniproxy looks to be exactly what I need :) I'm going to give this a try. Thank you for pointing this piece of software out to me! Courtney On 10/10/23 01:29, Stuart Henderson wrote: On 2023-10-10, Courtney wrote: Maybe I am wrong, but I thought that relayd was not capable of doing TLS pass through? That would be preferable if it is possible. If you do TLS passthrough (i.e. passing packets directly to the origin rather than doing "back to back" and terminating one TLS connection and making a second one) then the renewed certs need to be copied on to the backend machines, which was a thing you were asking about avoiding. Obviously you don't have access to HTTP headers at that point so you can't inspect Host, but you can look at SNI from the TLS ClientHello. (encrypted SNI doesn't matter much here - a small server will be sufficiently identifiable from the IP address alone so there's little benefit in using eSNI, so you can simply not configure tge server to use it). If you *do* want that, sniproxy is made for doing just that, so should be simple to configure, but it's also possible with at least haproxy and nginx. https://www.haproxy.com/blog/enhanced-ssl-load-balancing-with-server-name-indication-sni-tls-extension https://nginx.org/en/docs/stream/ngx_stream_ssl_preread_module.html Passing the client's source IP through to the origin server can be a bit fiddly with this method. haproxy has a proxy protocol which can be used to pass it through but the origin server needs to understand it. It can also be done by essentially 'spoofing' the original client IP for the TCP connection to the origin - which works with any origin server software, but the proxy needs to be on a machine on the normal network path between the client and origin. (For a normal "back to back" proxy with two separate TLS connections, for https this would normally be done by adding X-Forwarded-For or similar header). relayd can definitely pass a TCP connection to a different backend based on IP address or port. There should probably be a way to use https Host headers as part of the decision by doing back-to-back TLS connections though like everything with relayd filters it will probably require hitting your head against a wall repeatedly before getting it to work ;) I don't _think_ there's any way to use SNI to make that decision in relayd. On 10/9/23 00:42, Kapetanakis Giannis wrote: On 08/10/2023 04:00, Courtney wrote: Ultimately, I want to serve a handful of services on 80/443 that are easily accessible internally and externally, and I don't want to have unencrypted traffic between relayd and my server for the services that are passing sessions and such. Then don't terminate the connection on relayd. Use redirect instead of a relay and terminate on the web server itself. It will also be a little faster since the router/relayd will only route/pass the packets to the appropriate backend server. For internal traffic you have to use appropriate DNS (local IP) and maybe a different certificate. G
Re: relayd ssl termination advice
On 2023-10-10, Courtney wrote: > Maybe I am wrong, but I thought that relayd was not capable of doing > TLS pass through? That would be preferable if it is possible. If you do TLS passthrough (i.e. passing packets directly to the origin rather than doing "back to back" and terminating one TLS connection and making a second one) then the renewed certs need to be copied on to the backend machines, which was a thing you were asking about avoiding. Obviously you don't have access to HTTP headers at that point so you can't inspect Host, but you can look at SNI from the TLS ClientHello. (encrypted SNI doesn't matter much here - a small server will be sufficiently identifiable from the IP address alone so there's little benefit in using eSNI, so you can simply not configure tge server to use it). If you *do* want that, sniproxy is made for doing just that, so should be simple to configure, but it's also possible with at least haproxy and nginx. https://www.haproxy.com/blog/enhanced-ssl-load-balancing-with-server-name-indication-sni-tls-extension https://nginx.org/en/docs/stream/ngx_stream_ssl_preread_module.html Passing the client's source IP through to the origin server can be a bit fiddly with this method. haproxy has a proxy protocol which can be used to pass it through but the origin server needs to understand it. It can also be done by essentially 'spoofing' the original client IP for the TCP connection to the origin - which works with any origin server software, but the proxy needs to be on a machine on the normal network path between the client and origin. (For a normal "back to back" proxy with two separate TLS connections, for https this would normally be done by adding X-Forwarded-For or similar header). relayd can definitely pass a TCP connection to a different backend based on IP address or port. There should probably be a way to use https Host headers as part of the decision by doing back-to-back TLS connections though like everything with relayd filters it will probably require hitting your head against a wall repeatedly before getting it to work ;) I don't _think_ there's any way to use SNI to make that decision in relayd. > > > On 10/9/23 00:42, Kapetanakis Giannis wrote: >> On 08/10/2023 04:00, Courtney wrote: >>> Ultimately, I want to serve a handful of services on 80/443 that are >>> easily accessible internally and externally, and I don't want to have >>> unencrypted traffic between relayd and my server for the services that >>> are passing sessions and such. >> >> Then don't terminate the connection on relayd. Use redirect instead of a >> relay and terminate on the web server itself. >> >> It will also be a little faster since the router/relayd will only route/pass >> the packets to the appropriate backend server. >> >> For internal traffic you have to use appropriate DNS (local IP) and maybe a >> different certificate. >> >> G >> > > -- Please keep replies on the mailing list.
Re: relayd ssl termination advice
Maybe I am wrong, but I thought that relayd was not capable of doing TLS pass through? That would be preferable if it is possible. Courtney On 10/9/23 00:42, Kapetanakis Giannis wrote: On 08/10/2023 04:00, Courtney wrote: Ultimately, I want to serve a handful of services on 80/443 that are easily accessible internally and externally, and I don't want to have unencrypted traffic between relayd and my server for the services that are passing sessions and such. Then don't terminate the connection on relayd. Use redirect instead of a relay and terminate on the web server itself. It will also be a little faster since the router/relayd will only route/pass the packets to the appropriate backend server. For internal traffic you have to use appropriate DNS (local IP) and maybe a different certificate. G
Re: relayd ssl termination advice
On 08/10/2023 04:00, Courtney wrote: > Ultimately, I want to serve a handful of services on 80/443 that are > easily accessible internally and externally, and I don't want to have > unencrypted traffic between relayd and my server for the services that > are passing sessions and such. Then don't terminate the connection on relayd. Use redirect instead of a relay and terminate on the web server itself. It will also be a little faster since the router/relayd will only route/pass the packets to the appropriate backend server. For internal traffic you have to use appropriate DNS (local IP) and maybe a different certificate. G
Re: relayd ssl termination advice
On 08.10.2023 03:00, Courtney wrote: Hello everyone, I'm seeking an ideal way to make secure https connections to a handful of web servers in my house. Currently I have a Nextcloud server and a gitea server, but only the Nextcloud server is being port forwarded on 80/443. I want to make my gitea server publicly visible as well as a couple other projects. My thought is to have relayd running on my router and match Host headers and forward it to my servers based on the Host. This will also conveniently let me handle renewing Let's Encrypt certs in one place. I already do this right now with a VPS, but I have a wireguard tunnel to my house in this case to access the backend, which is encrypting the traffic from my relayd server to my backend web server. With my Nextcloud and gitea server, if I terminate SSL at my router, the connection between my router and Nextcloud/gitea web servers would be unencrypted. Even though it is in my own house, I don't really like that idea. It seems to be overkill too to do peer to peer wireguard between my Nextcloud/gitea servers in my house. I was wondering if this would actually be proper or if there are any other ideas you all might have. Ultimately, I want to serve a handful of services on 80/443 that are easily accessible internally and externally, and I don't want to have unencrypted traffic between relayd and my server for the services that are passing sessions and such. Thank you, Courtney I have a similar situation at home. I use TLS to encrypt the traffic between relayd(8) and the actual web servers. On the web servers I use self-signed certificates which are valid for several decades. When it comes to administrative access on the web servers I use my router as ProxyJump and/or configure local tunnel(s) in ssh(1). Cheers, Bruno
Re: relayd ssl termination advice
On 10/7/2023 9:00 PM, Courtney wrote: Hello everyone, I'm seeking an ideal way to make secure https connections to a handful of web servers in my house. I'm currently doing this with haproxy by having it inspect the SNI on the incoming traffic and route based on that. At the time I set it up relayd didn't support SNI inspection, not sure if it's been added since. The main downsides to doing this: - haproxy has to be in the traffic path - haproxy has to run as root (ick) The traffic isn't decrypted by haproxy at all. I'm not sure how this will be affected by encrypted SNI/encrypted client hello. Relayd can also decrypt the traffic, then re-encrypt it from relayd to the web server. See "TLS RELAYS" in the man page.
relayd ssl termination advice
Hello everyone, I'm seeking an ideal way to make secure https connections to a handful of web servers in my house. Currently I have a Nextcloud server and a gitea server, but only the Nextcloud server is being port forwarded on 80/443. I want to make my gitea server publicly visible as well as a couple other projects. My thought is to have relayd running on my router and match Host headers and forward it to my servers based on the Host. This will also conveniently let me handle renewing Let's Encrypt certs in one place. I already do this right now with a VPS, but I have a wireguard tunnel to my house in this case to access the backend, which is encrypting the traffic from my relayd server to my backend web server. With my Nextcloud and gitea server, if I terminate SSL at my router, the connection between my router and Nextcloud/gitea web servers would be unencrypted. Even though it is in my own house, I don't really like that idea. It seems to be overkill too to do peer to peer wireguard between my Nextcloud/gitea servers in my house. I was wondering if this would actually be proper or if there are any other ideas you all might have. Ultimately, I want to serve a handful of services on 80/443 that are easily accessible internally and externally, and I don't want to have unencrypted traffic between relayd and my server for the services that are passing sessions and such. Thank you, Courtney
relayd not retrying relay's server-side connections
I'm running relayd with the following relayd.conf on OpenBSD 7.3.
relay forward_http {
listen on ::1 port 7200
forward to 127.0.0.1 port 7204 retry 30
}
I was hoping it would do this:
- Listen for connections on ::1 port 7200.
- Each time a connection comes in, try up to 31 times to connect
to 127.0.0.1, and if one of those tries succeeds, forward the
connection.
(My goal is to smooth over intervals where the 127.0.0.1:7204 service
is restarting: I want connections from outside to stall rather than
fail.)
The forwarding is working, but as far as I can tell relayd is only
trying once to connect to 127.0.0.1:7204. My evidence is that if
nothing is listening on 127.0.0.1:7204 when I try to connect to ::1
port 7200, I get a failure instantly, and "tcpdump -ilo0 tcp" only
shows a couple of messages exchanged rather than 31 attempts.
Am I doing something wrong, or misunderstanding what that "retry"
option is supposed to do?
Optional bonus question:
Even if get that working, I have a further problem: I actually want
to use "forward to " syntax, but there doesn't seem to be a
place for a "retry" option there. The reason I want to use "forward
to " syntax is that want to direct the connection based on
http parameters, and as far as I know that's not possible with
"forward to address" syntax.
Here's a more complete version of what I'm trying to do. It does
what I want, except for retrying when connecting to . (In
practice I add three more "relay" stanzas, for all combinations of
http/https and inet/inet6.)
Is there some way to add retries to this?
table { ::1 }
table { 127.0.0.1 }
http protocol reverse_proxy {
match request header append "X-Forwarded-For" value "$REMOTE_ADDR"
match request header append "X-Forwarded-Port" value "$SERVER_PORT"
pass forward to
pass request header "Host" value "fossil.falsifian.org" \
forward to
tls { keypair "falsifian.org" }
}
relay reverse_proxy_https_6 {
listen on ::1 port 7201 tls
protocol reverse_proxy
forward to port 7203
forward to port 7204
}
--
James
Re: relayd: pfe_route: failed to add gateway 22 Invalid argument
On Thu, Jun 29, 2023 at 09:34:10AM +0200, Jörg Streckfuß wrote: > Hi Claudio, > > Am 29.06.23 um 09:01 schrieb Claudio Jeker: > > On Thu, Jun 29, 2023 at 08:53:05AM +0200, Jörg Streckfuß wrote: > > > > > > Hi list, > > > > > > here is a small addition. Adding and deleting the route to and from > > > routing > > > table on the command line works as expected: > > > > > > fw1 # route add 2001:::::4/128 2001:::::4 -label > > > geo_service > > > add host 2001:::::4/128: gateway 2001:::::4 > > > > > > fw# route -n show -inet6 | grep 2001:::::4 > > > 2001:::::4 52:01:8d:e4:fd:63 UHLch > > > 123015 - 3 vlan18 > > > 2001:::::4 2001:::::4 UGHS > > > 00 - 8 vlan18 > > > > > > fw1 # route del 2001:::::4/128 2001:::::4 -label > > > geo_service > > > del host 2001:::::4/128: gateway 2001:::::4 > > > > > > fw1# route -n show -inet6 | grep 2001:::::4 > > > > > > 2001:638:dfce:3000::4 52:01:8d:e4:fd:63 UHLc > > > 0 > > > 23015 - 3 vlan18 > > > > > > > > > Why can't relayd add the route to the table and what does the following > > > log > > > concretely mean: > > > > > > > > > pfe_route: failed to add gateway 2001:638:dfce:3000::4: 22 Invalid > > > argument > > > > > > > > > > Run route -n monitor will give you more insights at what is sent to the > > kernel. At least unless the route message is so mangled that the kernel > > fails to parse it. > > This is interesting. I ran route -n monitor and run relayd but it says > nothing. No output at all. Ugh, relayd pfe_route is utterly broken for IPv6. That code never worked, the encoded message is not properly aligned because struct sockaddr_in6 does not align to a long word boundary. This function requires a rewrite. -- :wq Claudio
Re: relayd: pfe_route: failed to add gateway 22 Invalid argument
Hi Claudio, Am 29.06.23 um 09:01 schrieb Claudio Jeker: On Thu, Jun 29, 2023 at 08:53:05AM +0200, Jörg Streckfuß wrote: Hi list, here is a small addition. Adding and deleting the route to and from routing table on the command line works as expected: fw1 # route add 2001:::::4/128 2001:::::4 -label geo_service add host 2001:::::4/128: gateway 2001:::::4 fw# route -n show -inet6 | grep 2001:::::4 2001:::::4 52:01:8d:e4:fd:63 UHLch 123015 - 3 vlan18 2001:::::4 2001:::::4 UGHS 00 - 8 vlan18 fw1 # route del 2001:::::4/128 2001:::::4 -label geo_service del host 2001:::::4/128: gateway 2001:::::4 fw1# route -n show -inet6 | grep 2001:::::4 2001:638:dfce:3000::4 52:01:8d:e4:fd:63 UHLc 0 23015 - 3 vlan18 Why can't relayd add the route to the table and what does the following log concretely mean: pfe_route: failed to add gateway 2001:638:dfce:3000::4: 22 Invalid argument Run route -n monitor will give you more insights at what is sent to the kernel. At least unless the route message is so mangled that the kernel fails to parse it. This is interesting. I ran route -n monitor and run relayd but it says nothing. No output at all. Also all IPs does not help to understand what is going on. I will rebuild my setup to 2001:db adresses so I can post the full ipv6 address. Sorry this is because of a company policy. Why do you add /128 route with the same IP as the gateway? That just makes no sense. The idea is to check the availability of a service and announce the ip address to a bgp peer only if the service is up. I know it looks weird but for ipv4 it works. My naive assumption was to simply adopt it to IPv6. Is there a more elegant way to do this? Regards Joerg
Re: relayd: pfe_route: failed to add gateway 22 Invalid argument
On Thu, Jun 29, 2023 at 08:53:05AM +0200, Jörg Streckfuß wrote: > > Hi list, > > here is a small addition. Adding and deleting the route to and from routing > table on the command line works as expected: > > fw1 # route add 2001:::::4/128 2001:::::4 -label > geo_service > add host 2001:::::4/128: gateway 2001:::::4 > > fw# route -n show -inet6 | grep 2001:::::4 > 2001:::::4 52:01:8d:e4:fd:63 UHLch > 123015 - 3 vlan18 > 2001:::::4 2001:::::4 UGHS > 00 - 8 vlan18 > > fw1 # route del 2001:::::4/128 2001:::::4 -label > geo_service > del host 2001:::::4/128: gateway 2001:::::4 > > fw1# route -n show -inet6 | grep 2001:::::4 > > 2001:638:dfce:3000::4 52:01:8d:e4:fd:63 UHLc 0 > 23015 - 3 vlan18 > > > Why can't relayd add the route to the table and what does the following log > concretely mean: > > > pfe_route: failed to add gateway 2001:638:dfce:3000::4: 22 Invalid argument > > Run route -n monitor will give you more insights at what is sent to the kernel. At least unless the route message is so mangled that the kernel fails to parse it. Also all IPs does not help to understand what is going on. Why do you add /128 route with the same IP as the gateway? That just makes no sense. -- :wq Claudio
Re: relayd: pfe_route: failed to add gateway 22 Invalid argument
Hi list,
here is a small addition. Adding and deleting the route to and from
routing table on the command line works as expected:
fw1 # route add 2001:::::4/128 2001:::::4 -label
geo_service
add host 2001:::::4/128: gateway 2001:::::4
fw# route -n show -inet6 | grep 2001:::::4
2001:::::4 52:01:8d:e4:fd:63 UHLch
123015 - 3 vlan18
2001:::::4 2001:::::4 UGHS
00 - 8 vlan18
fw1 # route del 2001:::::4/128 2001:::::4 -label
geo_service
del host 2001:::::4/128: gateway 2001:::::4
fw1# route -n show -inet6 | grep 2001:::::4
2001:638:dfce:3000::4 52:01:8d:e4:fd:63 UHLc
023015 - 3 vlan18
Why can't relayd add the route to the table and what does the following
log concretely mean:
pfe_route: failed to add gateway 2001:638:dfce:3000::4: 22 Invalid argument
Am 28.06.23 um 16:57 schrieb Joerg Streckfuss:
Hello,
I'm trying to use the relayd router function to add host routes to the
routing table with a route label for further processing by bgpd. The
host ist directly connected to the firewall.
relayd.conf:
table { 2001:::::4 }
router "service_v6" {
route 2001:::::4/128
forward to port 80 check tcp
rtlabel geo_service
}
fw1# relayd -vvvd
startup
socket_rlimit: max open files 1024
pfe: filter init done
socket_rlimit: max open files 1024
socket_rlimit: max open files 1024
socket_rlimit: max open files 1024
parent_tls_ticket_rekey: rekeying tickets
hce_notify_done: 2001:::::4 (tcp connect ok)
host 2001:::::4, check tcp (0ms,tcp connect ok), state
unknown -> up, availability 100.00%
pfe_dispatch_hce: state 1 for host 1 2001:::::4
sync_routes: router service_v6 route 2001:::::4/128 gateway
2001:::::4 up priority 0
hce_notify_done: 2001:::::4 (tcp connect ok)
pfe_route: failed to add gateway 2001:::::4: 22 Invalid
argument
hce_notify_done: 2001:::::4 (tcp connect ok)
hce_notify_done: 2001:::::4 (tcp connect ok)
hce_notify_done: 2001:::::4 (tcp connect ok)
The route with the route label never pops up in the routing table. With
IPv4 addresses the setup works as expected.
Any suggestions?
relayd: pfe_route: failed to add gateway 22 Invalid argument
Hello,
I'm trying to use the relayd router function to add host routes to the routing
table with a route label for further processing by bgpd. The host ist directly
connected to the firewall.
relayd.conf:
table { 2001:::::4 }
router "service_v6" {
route 2001:::::4/128
forward to port 80 check tcp
rtlabel geo_service
}
fw1# relayd -vvvd
startup
socket_rlimit: max open files 1024
pfe: filter init done
socket_rlimit: max open files 1024
socket_rlimit: max open files 1024
socket_rlimit: max open files 1024
parent_tls_ticket_rekey: rekeying tickets
hce_notify_done: 2001:::::4 (tcp connect ok)
host 2001:::::4, check tcp (0ms,tcp connect ok), state unknown ->
up, availability 100.00%
pfe_dispatch_hce: state 1 for host 1 2001:::::4
sync_routes: router service_v6 route 2001:::::4/128 gateway
2001:::::4 up priority 0
hce_notify_done: 2001:::::4 (tcp connect ok)
pfe_route: failed to add gateway 2001:::::4: 22 Invalid argument
hce_notify_done: 2001:::::4 (tcp connect ok)
hce_notify_done: 2001:::::4 (tcp connect ok)
hce_notify_done: 2001:::::4 (tcp connect ok)
The route with the route label never pops up in the routing table. With IPv4
addresses the setup works as expected.
Any suggestions?
smime.p7s
Description: S/MIME Cryptographic Signature
Re: IP6 redirects through relayd no longer working reliably
Just for the record: The problem was caused by a malfunctioning upstream gateway, which did no longer respond properly to neighbor solicitation requests. The SYN ACK from the server was dropped because the firewall had already removed the state created by the SYN. On 6/23/23 22:51, Markus Wernig wrote: pflog shows that the IPv6 SYN-ACK replies from the backend servers are being dropped by pf. But weirdly the blocks are logged over 30 seconds after the SYN is allowed through:
IP6 redirects through relayd no longer working reliably
Hi all
(Sorry for flooding, this seems related to the question I asked earlier.
Please bear with me.)
I am using relayd on 7.3-release as an IP loadbalancer in front of some
dualstack backend hosts. This setup has worked for some years now.
After upgrading to 7.3 about 4 weeks ago I noticed a steady decline of
IPv6 sessions coming into the backend servers, up to the point where
none arrive at all (for 2 days now).
Now users start complaining that their connections to the servers
(public IP) are either timing out or are established only after a very
long time (usually the tcp start timeout when the client switches from
IPv6 to trying IPv4). The IPv4 connections succeed immediately.
pflog shows that the IPv6 SYN-ACK replies from the backend servers are
being dropped by pf. But weirdly the blocks are logged over 30 seconds
after the SYN is allowed through:
Jun 20 14:12:49.489707 rule 2/(match) [uid 0, pid 85766] pass out on
vlanX: [Client.IP6].50210 > [Server.IP6].443:
S 2508622700:2508622700(0) win 64800 <[|tcp]> [flowlabel 0xd4400] (len
32, hlim 52)
Jun 20 14:12:49.493267 rule 2/(match) [uid 0, pid 85766] pass out on
vlanX: [Client.IP6].50211 > [Server.IP6].443:
S 806421981:806421981(0) win 64800 <[|tcp]> [flowlabel 0x162e5] (len 32,
hlim 52)
Jun 20 14:12:49.507508 rule 2/(match) [uid 0, pid 85766] pass out on
vlanX: [Client.IP6].50212 > [Server.IP6].443:
S 3945655871:3945655871(0) win 64800 <[|tcp]> [flowlabel 0x8abc6] (len
32, hlim 52)
Jun 20 14:12:49.517783 rule 2/(match) [uid 0, pid 85766] pass out on
vlanX: [Client.IP6].50213 > [Server.IP6].443: S 1191028748:1191028748(0)
win 64800 <[|tcp]> [flowlabel 0xa7d6] (len 32, hlim 52)
Jun 20 14:13:20.943370 rule 2/(match) [uid 0, pid 85766] block in on
vlanX: [Server.IP6].443 > [Client.IP6].50213: S 3650589557:3650589557(0)
ack 209077342 win 64800 <[|tcp]> [flowlabel 0xd922c] (len 32, hlim 64)
Jun 20 14:13:20.943433 rule 2/(match) [uid 0, pid 85766] block in on
vlanX: [Server.IP6].443 > [Client.IP6].50212: S 2068945110:2068945110(0)
ack 2313561433 win 64800 <[|tcp]> [flowlabel 0xf8c9c] (len 32, hlim 64)
Jun 20 14:13:20.943476 rule 2/(match) [uid 0, pid 85766] block in on
vlanX: [Server.IP6].443 > [Client.IP6].50211: S 3395939328:3395939328(0)
ack 1849611325 win 64800 <[|tcp]> [flowlabel 0xb519e] (len 32, hlim 64)
Jun 20 14:13:20.943518 rule 2/(match) [uid 0, pid 85766] block in on
vlanX: [Server.IP6].443 > [Client.IP6].50210: S 106368970:106368970(0)
ack 1534267447 win 64800 <[|tcp]> [flowlabel 0xca19a] (len 32, hlim 64)
(The rule 2 that is logged is the rule number of the relayd/* anchor.)
tcpdump on vlanX shows the backend server sends the SYN-ACK immediately.
The IPv4 addresses are natted from public to rfc-1918 space and work.
For IPv6, the address of backend server.A is used as the public IP
(service.pub). Only if server.A becomes unavailable, are packets
redirected to server.B.
relayd.conf:
...
table {
Server.A.IP6 retry 2
}
table {
Server.B.IP6 retry 2
}
redirect "service.pub.80.v6" {
listen on Server.A.IP6 tcp port 80 interface trunk0
forward to port 80 \
check http "/" host "server.A" code 200
forward to port 80 \
check http "/" host "server.B" code 200
}
redirect "service.pub.443.v6" {
listen on Server.A.IP6 tcp port 443 interface trunk0
forward to port 443 \
check https "/" host "server.A" code 200
forward to port 443 \
check https "/" host "server.B" code 200
}
I am not 100% sure that the IPv6 failover actually worked before, but
the connections to Server.A.IP6 were definitely working.
I do see the http and https checks succeed on both backend servers.
I've tried flushing the states and rebooting the firewall, to no avail.
relayctl shows all redirects/tables as active and all hosts as up:
2 redirectservice.pub.80.v6 active
3 table server.A:80active (1 hosts)
3 hostServer.A.IP6 100.00% up
4 table server.B:80active (1 hosts)
4 hostServer.B.IP6 100.00% up
3 redirectservice.pub.443.v6 active
5 table server.A:443 active (1 hosts)
5 hostServer.A.IP6 100.00% up
6 table server.B:443 active (1 hosts)
6 host Server.B.IP6 100.00% up
Now I'm out of ideas on how to debug this further.
Has anyone been experiencing something similar?
Has something fundamental changed in relayd or pf that could cause this?
Does anybody spot an error in my configuration?
Thanks for any pointer!
Best regards
Markus
All packets logged with relayd/* anchor rule number
Hi all I am using relayd on 7.3-release as an incoming IP loadbalancer and therefore have this line near the beginning of the filter section of pf.conf: anchor "relayd/*" It shows up as rule number 2 in pfctl -vv -s rules: @0 match all scrub (no-df reassemble tcp) [ Evaluations: 89452 Packets: 545363Bytes: 161423157 States: 1772 ] [ Inserted: uid 0 pid 59061 State Creations: 0 ] @1 match out all scrub (random-id) [ Evaluations: 89452 Packets: 295160Bytes: 98671558 States: 921 ] [ Inserted: uid 0 pid 59061 State Creations: 0 ] @2 anchor "relayd/*" all [ Evaluations: 89452 Packets: 576068Bytes: 163171696 States: 1772 ] [ Inserted: uid 0 pid 59061 State Creations: 58739 ] But now all packets get logged with rule no. 2 in pflog, regardless of whether or not they match any relayd redirect. Here's an example of an outgoing natted NTP query, which has nothing whatsoever to do with the relayd rules/redirects: # tcpdump -e -vvv -ttt -n -i pflog0 port ntp Jun 23 20:07:56.377848 rule 2/(match) [uid 0, pid 59061] pass in on vlanX: 192.168.x.y.123 > a.b.c.d.123: v4 client strat 2 poll 10 prec -24 dist 0.006881 disp 0.034591 ref a.b.c.d@3896531217.384170621 orig 3896531389.381188988 [|ntp] (DF) [tos 0xb8] (ttl 64, id 1236, len 76) Jun 23 20:07:56.377928 rule 2/(match) [uid 0, pid 59061] pass out on trunk0: [rewritten: src n.m.p.o:55798, dst a.b.c.d:123] 192.168.x.y.123 > a.b.c.d.123: v4 client strat 2 poll 10 prec -24 dist 0.006881 disp 0.034591 ref a.b.c.d@3896531217.384170621 orig 3896531389.381188988 [|ntp] [tos 0xb8] (ttl 63, id 1236, len 76, bad ip cksum dd99! -> de99) Is this the expected behaviour? Is there any way to get the actual rule numbers back? I am quite sure this was different in earlier releases. Thank you in advance Markus
Re: relayd filter
On 06/06/2023 16:49, Paul Pace wrote:
> On 6/5/23 3:15 PM, Nick Bouliane wrote:
>> Hi,
>>
>> in relayd.conf I'm trying to do :
>>
>> pass from 192.168.1.1 path "/something.html"
>>
>> If I individually specify the "from" or the "path", it works
>> but when I combine both, it doesn't work.
>
> Nowadays, when I come upon this I just use tags and move on.
>
> Something like this might work:
>
> match path "/something.html" tag something
> pass from 192.168.1.1 tagged something
>
>>
>> Am I missing something or if it's just not possible ?
>> Or is there another way to express this another way ?
>>
>> thank you,
>> Nick
Although this is probably a more elegant solution, relayd also supports
filtering.
I'm doing this in my http protocol {}
pass quick from _admin_ip_address
block quick path "/admin"
block quick path "/admin.html"
block quick path "/admin/"
G
Re: paket tag, veb0, virtual machine and relayd
On Wed, Jun 7, 2023 at 4:38 AM Stuart Henderson wrote: > On 2023-06-07, Nick Bouliane wrote: > > I have a bridge veb0 to which is connected tap1, the interface of a > virtual > > machine. > > On the bridge I have a rule for tap1: > > pass in on tap1 src 11:22:33:44:55:66 tag VM1 > > > > In the bridge I also have an interface vport0 with the IP address > > 1921.168.0.1 > > This virtual machine has the IP 192.168.0.2 > > > > When a packet comes out of the VM (i.e: curl) it gets tagged by the rule > > that I have on the veb bridge. > > I know the tag is working because I can drop packets with pf (pf.conf) > if I > > add that rule: > > block in on tap1 tagged VM1 > > > > I have relayd listening on vport0 and in my relayd.conf I have this > filter: > > pass path "/something.html" tagged VM1 > > Those "rule tags" are specific to relayd and are not connected with the > PF tags at all. > > The only place relayd interacts with PF tags is if you use "pftag" in a > relayd redirection. > Thank you for enlightening me ! > > > -- > Please keep replies on the mailing list. > >
Re: paket tag, veb0, virtual machine and relayd
On 2023-06-07, Nick Bouliane wrote: > I have a bridge veb0 to which is connected tap1, the interface of a virtual > machine. > On the bridge I have a rule for tap1: > pass in on tap1 src 11:22:33:44:55:66 tag VM1 > > In the bridge I also have an interface vport0 with the IP address > 1921.168.0.1 > This virtual machine has the IP 192.168.0.2 > > When a packet comes out of the VM (i.e: curl) it gets tagged by the rule > that I have on the veb bridge. > I know the tag is working because I can drop packets with pf (pf.conf) if I > add that rule: > block in on tap1 tagged VM1 > > I have relayd listening on vport0 and in my relayd.conf I have this filter: > pass path "/something.html" tagged VM1 Those "rule tags" are specific to relayd and are not connected with the PF tags at all. The only place relayd interacts with PF tags is if you use "pftag" in a relayd redirection. -- Please keep replies on the mailing list.
paket tag, veb0, virtual machine and relayd
I have a bridge veb0 to which is connected tap1, the interface of a virtual machine. On the bridge I have a rule for tap1: pass in on tap1 src 11:22:33:44:55:66 tag VM1 In the bridge I also have an interface vport0 with the IP address 1921.168.0.1 This virtual machine has the IP 192.168.0.2 When a packet comes out of the VM (i.e: curl) it gets tagged by the rule that I have on the veb bridge. I know the tag is working because I can drop packets with pf (pf.conf) if I add that rule: block in on tap1 tagged VM1 I have relayd listening on vport0 and in my relayd.conf I have this filter: pass path "/something.html" tagged VM1 It doesn't work. If I try to match only the path it works, only the IP it works, etc... but the tag doesn't match. Is it supposed to work ? Does the veb strips the tag ? thank you, Nick
Re: relayd filter
On Tue, Jun 6, 2023 at 11:08 AM Paul Pace wrote: > On 6/5/23 3:15 PM, Nick Bouliane wrote: > > Hi, > > > > in relayd.conf I'm trying to do : > > > > pass from 192.168.1.1 path "/something.html" > > > > If I individually specify the "from" or the "path", it works > > but when I combine both, it doesn't work. > > Nowadays, when I come upon this I just use tags and move on. > > Something like this might work: > > match path "/something.html" tag something > pass from 192.168.1.1 tagged something > oh, it works well, thank you ! > > > > > Am I missing something or if it's just not possible ? > > Or is there another way to express this another way ? > > > > thank you, > > Nick > >
Re: relayd filter
On 6/5/23 3:15 PM, Nick Bouliane wrote: Hi, in relayd.conf I'm trying to do : pass from 192.168.1.1 path "/something.html" If I individually specify the "from" or the "path", it works but when I combine both, it doesn't work. Nowadays, when I come upon this I just use tags and move on. Something like this might work: match path "/something.html" tag something pass from 192.168.1.1 tagged something Am I missing something or if it's just not possible ? Or is there another way to express this another way ? thank you, Nick
relayd filter
Hi, in relayd.conf I'm trying to do : pass from 192.168.1.1 path "/something.html" If I individually specify the "from" or the "path", it works but when I combine both, it doesn't work. Am I missing something or if it's just not possible ? Or is there another way to express this another way ? thank you, Nick
Re: [WIP PATCH] relayd: check for any certificate before inheriting default
Josuah Demangeon wrote:
> I think I found a bug in relayd, but maybe I misunderstood
> how to configure it:
If I duplicate each "relay { ... }" section instead of using
two "listen on" within the same "relay", it works.
It suggests that there is indeed something fishy with the
relay having two "listen on".
[WIP PATCH] relayd: check for any certificate before inheriting default
Hello!
I think I found a bug in relayd, but maybe I misunderstood
how to configure it:
Bug reproduced (with a cert setup) as below:
$ cat /etc/relayd.conf:
table <"http"> { 127.0.0.1 }
http protocol "https" {
tls keypair "lap1.josuah.net"
}
relay "https" {
listen on 127.0.0.1 port 443 tls
listen on ::1 port 443 tls
protocol "https"
forward to <"http"> port 80 check tcp
}
$ ktrace relayd -dvv # without the patch applied
...
87874 relayd CALL open(0x7f7e76d0,0)
87874 relayd NAMI "/etc/ssl/::1:443.crt"
87874 relayd RET open -1 errno 2 No such file or directory
87874 relayd CALL open(0x7f7e76d0,0)
87874 relayd NAMI "/etc/ssl/::1.crt"
87874 relayd RET open -1 errno 2 No such file or directory
...
The second "listen" block inherit its configuration from the
first, and /etc/ssl/::1.crt as certificate instead of the
keypair list.
Although, even with the patch it does not work on the extra
listen address (the one replicated):
$ openssl s_client -connect ::1:443 -servername lap1.josuah.net
CONNECTED(0003)
5110093530528:error:1400A410:SSL routines:CONNECT_CR_CERT_REQ:sslv3 alert
handshake failure:/usr/src/lib/libssl/tls13_lib.c:129:SSL alert number 40
---
no peer certificate available
If anyone has an idea on how to allow multiple listen
as shown in the example, I am interested.
The patch:
Check that there are no certificates in the keypair list
before searching the default /etc/ssl/$address.crt
certificate.
Index: src/usr.sbin/relayd/parse.y
===
RCS file: /cvs/src/usr.sbin/relayd/parse.y,v
retrieving revision 1.253
diff -u -r1.253 parse.y
--- src/usr.sbin/relayd/parse.y 15 Oct 2021 15:01:28 - 1.253
+++ src/usr.sbin/relayd/parse.y 17 Aug 2022 11:52:34 -
@@ -3421,7 +3421,8 @@
goto err;
}
- if (relay_load_certfiles(conf, rb, NULL) == -1) {
+ if (TAILQ_EMPTY(>rl_proto->tlscerts) &&
+ relay_load_certfiles(conf, rb, NULL) == -1) {
yyerror("cannot load certificates for relay %s",
rb->rl_conf.name);
Re: Relayd Questions
I don't think you can do this using SPI directly.
If you use IKE then you might be able to do something in iked or isakmpd
config to set PF tags, and then use PF rules to rewrite the dest port
to point at something else to select a different relay in relayd..
On 2022/08/09 12:53, Todd Carpenter wrote:
> I just wanted to clarify, for relayd..
>
> Is it possible to filter / loadbalance based on the SPI information of the 4
> byte
> headers within ipsec?
> https://en.wikipedia.org/wiki/IPsec#Encapsulating_Security_Payload
>
> Security Parameters Index (32 bits)
> Arbitrary value used (together with the destination IP address) to
> identify the security
> association of the receiving party
>
> I could not find any information that relates specifically to ipsec
> traffic
>
> Thanks Again.
>
> On Sun, Aug 7, 2022 at 3:59 AM Stuart Henderson
> wrote:
>
> On 2022-08-06, Todd Carpenter wrote:
> > Hi all,
> >
> > I've been trying to get relayd up and running on my configuration and
> had a
> > couple of questions I could not find answers for.
> >
> > As I understand it, relayd is capable of making a "protocol" where you
> > could essentially take connection details and call it whatever you like,
> > then create rules in pf via that protocol.
> >
> > for example, in mwl's relayd book he creates a "dns fix protocol"
> > relay dns {
> > listen on 203.0.113.213 port 53
> > forward to check tcp
> > protocol dnsfix
> > }
> >
> > questions:
> > how can I pass this to pf.conf and apply stickines to it to ensure that
> if
> > the protocol dnsfix was routed to server 52 on the back end.. that all
> > future requests are sent to server 52 and not server 17 (ie is this a
> > relayd.conf thing.. or a pf.conf thing)?
>
> Relays are userland TCP proxies done inside relayd. Configuring them
> is done in relayd.conf. See
>
> man relayd.conf | less "+/set the scheduling algorithm"
>
> > is it possible to have multiple ports and protocols wrapped into a new
> > protocol?
> > for example I need port 443 tcp, 10443 tcp, 8000 udp and 8001 tcp ..
> to be
> > treated as a single connection. Is a protocol even the right tool for
> the
> > job? If so, how do you add multiple ports? or does each rule need to be
> > seperate? (an example would be awesome)
>
> As a single protocol definition? You can't, you need separate ones.
>
> > Next question, in regards to the previous question. How would you apply
> a
> > stickiness state to ensure that all 4 ports from the same client are
> sent
> > to the same server?
>
> "mode source-hash" is probably the only option.
>
> > last question..
> > how do you decide what configuration should be placed in pf.conf vs
> > relayd.conf? and if your using an anchor like relayd .. in terms of
> pf, is
> > there 1 config or are they seperate?
> >
> > IE: if i have a in relayd.conf that defines {server1,2,3,4} do
> I
> > need the same table in my pf.conf file? or should I make the exact same
> > table with a unique name? or are the relayd.conf tables used as both an
> > anchor and expanded into the default pf.conf?
>
> For the main part relayd loads what it needs into PF under the anchor.
>
> If you're using _redirections_ with sticky-address and want that to
> persist
> across multiple connections then see "src.track" in pf.conf(5).
>
>
> --
> Please keep replies on the mailing list.
>
>
Re: Relayd Questions
I just wanted to clarify, for relayd..
Is it possible to filter / loadbalance based on the SPI information of the
4 byte headers within ipsec?
https://en.wikipedia.org/wiki/IPsec#Encapsulating_Security_Payload
*Security Parameters Index* (32 bits)Arbitrary value used (together with
the destination IP address) to identify the security association
<https://en.wikipedia.org/wiki/Security_association> of the receiving party
I could not find any information that relates specifically to ipsec traffic
Thanks Again.
On Sun, Aug 7, 2022 at 3:59 AM Stuart Henderson
wrote:
> On 2022-08-06, Todd Carpenter wrote:
> > Hi all,
> >
> > I've been trying to get relayd up and running on my configuration and
> had a
> > couple of questions I could not find answers for.
> >
> > As I understand it, relayd is capable of making a "protocol" where you
> > could essentially take connection details and call it whatever you like,
> > then create rules in pf via that protocol.
> >
> > for example, in mwl's relayd book he creates a "dns fix protocol"
> > relay dns {
> > listen on 203.0.113.213 port 53
> > forward to check tcp
> > protocol dnsfix
> > }
> >
> > questions:
> > how can I pass this to pf.conf and apply stickines to it to ensure that
> if
> > the protocol dnsfix was routed to server 52 on the back end.. that all
> > future requests are sent to server 52 and not server 17 (ie is this a
> > relayd.conf thing.. or a pf.conf thing)?
>
> Relays are userland TCP proxies done inside relayd. Configuring them
> is done in relayd.conf. See
>
> man relayd.conf | less "+/set the scheduling algorithm"
>
> > is it possible to have multiple ports and protocols wrapped into a new
> > protocol?
> > for example I need port 443 tcp, 10443 tcp, 8000 udp and 8001 tcp .. to
> be
> > treated as a single connection. Is a protocol even the right tool for
> the
> > job? If so, how do you add multiple ports? or does each rule need to be
> > seperate? (an example would be awesome)
>
> As a single protocol definition? You can't, you need separate ones.
>
> > Next question, in regards to the previous question. How would you apply a
> > stickiness state to ensure that all 4 ports from the same client are sent
> > to the same server?
>
> "mode source-hash" is probably the only option.
>
> > last question..
> > how do you decide what configuration should be placed in pf.conf vs
> > relayd.conf? and if your using an anchor like relayd .. in terms of pf,
> is
> > there 1 config or are they seperate?
> >
> > IE: if i have a in relayd.conf that defines {server1,2,3,4} do I
> > need the same table in my pf.conf file? or should I make the exact same
> > table with a unique name? or are the relayd.conf tables used as both an
> > anchor and expanded into the default pf.conf?
>
> For the main part relayd loads what it needs into PF under the anchor.
>
> If you're using _redirections_ with sticky-address and want that to persist
> across multiple connections then see "src.track" in pf.conf(5).
>
>
> --
> Please keep replies on the mailing list.
>
>
Re: Relayd Questions
thank you for your comments, I will dig into it.
cheers
Get Outlook for iOS<https://aka.ms/o0ukef>
From: owner-m...@openbsd.org on behalf of Stuart
Henderson
Sent: Sunday, August 7, 2022 3:56:16 AM
To: misc@openbsd.org
Subject: Re: Relayd Questions
On 2022-08-06, Todd Carpenter wrote:
> Hi all,
>
> I've been trying to get relayd up and running on my configuration and had a
> couple of questions I could not find answers for.
>
> As I understand it, relayd is capable of making a "protocol" where you
> could essentially take connection details and call it whatever you like,
> then create rules in pf via that protocol.
>
> for example, in mwl's relayd book he creates a "dns fix protocol"
> relay dns {
> listen on 203.0.113.213 port 53
> forward to check tcp
> protocol dnsfix
> }
>
> questions:
> how can I pass this to pf.conf and apply stickines to it to ensure that if
> the protocol dnsfix was routed to server 52 on the back end.. that all
> future requests are sent to server 52 and not server 17 (ie is this a
> relayd.conf thing.. or a pf.conf thing)?
Relays are userland TCP proxies done inside relayd. Configuring them
is done in relayd.conf. See
man relayd.conf | less "+/set the scheduling algorithm"
> is it possible to have multiple ports and protocols wrapped into a new
> protocol?
> for example I need port 443 tcp, 10443 tcp, 8000 udp and 8001 tcp .. to be
> treated as a single connection. Is a protocol even the right tool for the
> job? If so, how do you add multiple ports? or does each rule need to be
> seperate? (an example would be awesome)
As a single protocol definition? You can't, you need separate ones.
> Next question, in regards to the previous question. How would you apply a
> stickiness state to ensure that all 4 ports from the same client are sent
> to the same server?
"mode source-hash" is probably the only option.
> last question..
> how do you decide what configuration should be placed in pf.conf vs
> relayd.conf? and if your using an anchor like relayd .. in terms of pf, is
> there 1 config or are they seperate?
>
> IE: if i have a in relayd.conf that defines {server1,2,3,4} do I
> need the same table in my pf.conf file? or should I make the exact same
> table with a unique name? or are the relayd.conf tables used as both an
> anchor and expanded into the default pf.conf?
For the main part relayd loads what it needs into PF under the anchor.
If you're using _redirections_ with sticky-address and want that to persist
across multiple connections then see "src.track" in pf.conf(5).
--
Please keep replies on the mailing list.
Re: Relayd Questions
On 2022-08-06, Todd Carpenter wrote:
> Hi all,
>
> I've been trying to get relayd up and running on my configuration and had a
> couple of questions I could not find answers for.
>
> As I understand it, relayd is capable of making a "protocol" where you
> could essentially take connection details and call it whatever you like,
> then create rules in pf via that protocol.
>
> for example, in mwl's relayd book he creates a "dns fix protocol"
> relay dns {
> listen on 203.0.113.213 port 53
> forward to check tcp
> protocol dnsfix
> }
>
> questions:
> how can I pass this to pf.conf and apply stickines to it to ensure that if
> the protocol dnsfix was routed to server 52 on the back end.. that all
> future requests are sent to server 52 and not server 17 (ie is this a
> relayd.conf thing.. or a pf.conf thing)?
Relays are userland TCP proxies done inside relayd. Configuring them
is done in relayd.conf. See
man relayd.conf | less "+/set the scheduling algorithm"
> is it possible to have multiple ports and protocols wrapped into a new
> protocol?
> for example I need port 443 tcp, 10443 tcp, 8000 udp and 8001 tcp .. to be
> treated as a single connection. Is a protocol even the right tool for the
> job? If so, how do you add multiple ports? or does each rule need to be
> seperate? (an example would be awesome)
As a single protocol definition? You can't, you need separate ones.
> Next question, in regards to the previous question. How would you apply a
> stickiness state to ensure that all 4 ports from the same client are sent
> to the same server?
"mode source-hash" is probably the only option.
> last question..
> how do you decide what configuration should be placed in pf.conf vs
> relayd.conf? and if your using an anchor like relayd .. in terms of pf, is
> there 1 config or are they seperate?
>
> IE: if i have a in relayd.conf that defines {server1,2,3,4} do I
> need the same table in my pf.conf file? or should I make the exact same
> table with a unique name? or are the relayd.conf tables used as both an
> anchor and expanded into the default pf.conf?
For the main part relayd loads what it needs into PF under the anchor.
If you're using _redirections_ with sticky-address and want that to persist
across multiple connections then see "src.track" in pf.conf(5).
--
Please keep replies on the mailing list.
Relayd Questions
Hi all,
I've been trying to get relayd up and running on my configuration and had a
couple of questions I could not find answers for.
As I understand it, relayd is capable of making a "protocol" where you
could essentially take connection details and call it whatever you like,
then create rules in pf via that protocol.
for example, in mwl's relayd book he creates a "dns fix protocol"
relay dns {
listen on 203.0.113.213 port 53
forward to check tcp
protocol dnsfix
}
questions:
how can I pass this to pf.conf and apply stickines to it to ensure that if
the protocol dnsfix was routed to server 52 on the back end.. that all
future requests are sent to server 52 and not server 17 (ie is this a
relayd.conf thing.. or a pf.conf thing)?
is it possible to have multiple ports and protocols wrapped into a new
protocol?
for example I need port 443 tcp, 10443 tcp, 8000 udp and 8001 tcp .. to be
treated as a single connection. Is a protocol even the right tool for the
job? If so, how do you add multiple ports? or does each rule need to be
seperate? (an example would be awesome)
Next question, in regards to the previous question. How would you apply a
stickiness state to ensure that all 4 ports from the same client are sent
to the same server?
last question..
how do you decide what configuration should be placed in pf.conf vs
relayd.conf? and if your using an anchor like relayd .. in terms of pf, is
there 1 config or are they seperate?
IE: if i have a in relayd.conf that defines {server1,2,3,4} do I
need the same table in my pf.conf file? or should I make the exact same
table with a unique name? or are the relayd.conf tables used as both an
anchor and expanded into the default pf.conf?
Apologies if my questions seem silly, I'm still kind of new to pf/openbsd.
Kind regards
Re: relayd macros
Did you try it with quotes only and expand the variables with $var as in the
manpage?
This would point out if there is a bug in the -n check option and/or in the
parsing code of relayd.
-Stefan
Le 17 juil. 2022 16:08, Paul Pace a écrit :
On 2022-07-17 06:51, Stuart Henderson wrote:
> On 2022-07-17, Paul Pace wrote:
>> On 2022-07-17 00:28, Kapfhammer, Stefan wrote:
>>> You need to define a table.
>>> See relayed.conf manual page
>>> Section macros
>>
>> The macros section does include include creating tables that contain a
>> macro:
>>
>>
>> MACROS
>> Macros can be defined that will later be expanded in context.
>> Macro
>> names must start with a letter, digit, or underscore, and may
>> contain any
>> of those characters. Macro names may not be reserved words (for
>> example,
>> table, relay, or timeout). Macros are not expanded inside
>> quotes.
>>
>> For example:
>>
>> www1="10.0.0.1"
>> www2="10.0.0.2"
>> table {
>> $www1
>> $www2
>> }
>>
>>
>> I have created macros and tables:
>>
>> adminip1 = 203.0.113.5
>> adminip2 = 195.51.100.103
>
> Don't they need to be in quotes?
The configurations pass relayd -n checks and services work as expected
with
the following macro syntax:
adminip1=203.0.113.5
adminip2 = 203.0.113.6
adminip3="203.0.113.7"
adminip4 = "203.0.113.8"
>
>> table { 203.0.113.5 }
>> table {
>> $adminip1
>> $adminip2
>> }
>>
>> When I replace $adminip1 with or in a working
>> protocol
>> filter rule on line 20, I get a bunch of syntax errors beginning on
>> line
>> 20.
>>
>> Thank you,
>>
>> Paul
>>
>>
>>>
>>> -Stefan
>>>
>>>
>>>
>>>
>>> Le 16 juil. 2022 22:09, Paul Pace a écrit :
>>> Hello!
>>>
>>> I'm working on a relayd.conf configuration where I want to limit
>>> access
>>> to the path of an admin panel at /admin/ by using the from parameter
>>> in
>>> a protocol filter rule.
>>>
>>> I expect more than one IP address so want to use a macro with more
>>> than
>>> one IP address (or even more than one macro), similar to how I use
>>> them
>>> in httpd.conf and pf.conf:
>>>
>>> admin_ips = "{ 203.0.113.5, 198.51.100.103 }"
>>>
>>> When I add this to line 4 of relayd.conf and before creating a rule,
>>> I
>>> get:
>>>
>>> relayd -n
>>> /etc/realyd.conf:4: syntax error
>>>
>>> Have I just merely made a syntax error or is what I want to do not
>>> possible in relayd.conf?
>>>
>>> Thank you,
>>>
>>>
>>> Paul
>>
>>
Re: relayd macros
On 2022-07-17, Paul Pace wrote:
> On 2022-07-17 00:28, Kapfhammer, Stefan wrote:
>> You need to define a table.
>> See relayed.conf manual page
>> Section macros
>
> The macros section does include include creating tables that contain a
> macro:
>
>
> MACROS
> Macros can be defined that will later be expanded in context.
> Macro
> names must start with a letter, digit, or underscore, and may
> contain any
> of those characters. Macro names may not be reserved words (for
> example,
> table, relay, or timeout). Macros are not expanded inside quotes.
>
> For example:
>
> www1="10.0.0.1"
> www2="10.0.0.2"
> table {
> $www1
> $www2
> }
>
>
> I have created macros and tables:
>
> adminip1 = 203.0.113.5
> adminip2 = 195.51.100.103
Don't they need to be in quotes?
> table { 203.0.113.5 }
> table {
> $adminip1
> $adminip2
> }
>
> When I replace $adminip1 with or in a working
> protocol
> filter rule on line 20, I get a bunch of syntax errors beginning on line
> 20.
>
> Thank you,
>
> Paul
>
>
>>
>> -Stefan
>>
>>
>>
>>
>> Le 16 juil. 2022 22:09, Paul Pace a écrit :
>> Hello!
>>
>> I'm working on a relayd.conf configuration where I want to limit access
>> to the path of an admin panel at /admin/ by using the from parameter in
>> a protocol filter rule.
>>
>> I expect more than one IP address so want to use a macro with more than
>> one IP address (or even more than one macro), similar to how I use them
>> in httpd.conf and pf.conf:
>>
>> admin_ips = "{ 203.0.113.5, 198.51.100.103 }"
>>
>> When I add this to line 4 of relayd.conf and before creating a rule, I
>> get:
>>
>> relayd -n
>> /etc/realyd.conf:4: syntax error
>>
>> Have I just merely made a syntax error or is what I want to do not
>> possible in relayd.conf?
>>
>> Thank you,
>>
>>
>> Paul
>
>
--
Please keep replies on the mailing list.
Re: relayd macros
You need to define a table.
See relayed.conf manual page
Section macros
-Stefan
Le 16 juil. 2022 22:09, Paul Pace a écrit :
Hello!
I'm working on a relayd.conf configuration where I want to limit access
to the path of an admin panel at /admin/ by using the from parameter in
a protocol filter rule.
I expect more than one IP address so want to use a macro with more than
one IP address (or even more than one macro), similar to how I use them
in httpd.conf and pf.conf:
admin_ips = "{ 203.0.113.5, 198.51.100.103 }"
When I add this to line 4 of relayd.conf and before creating a rule, I get:
relayd -n
/etc/realyd.conf:4: syntax error
Have I just merely made a syntax error or is what I want to do not
possible in relayd.conf?
Thank you,
Paul
Re: relayd blocking by IP
fosf...@gmail.com (Fabio Martins), 2022.05.06 (Fri) 00:43 (CEST):
> On Thursday, May 5, 2022, Stuart Henderson
> wrote:
> > not quite, PF is looking up the IP in the table to decide which port
> > number to use
> > then the different port number is handled in relayd to pick between
> > two contexts:
> > one does not inspect Host (for those requests coming from
> > addresses on "geoallow")
> > the other (for all other requests) does inspect Host
> >
> > Understood. Also possible this way.
Just got around to implement it, this is for the archives:
(Thanks again for the hint, sthen@)
pf.conf(5):
table persist file "/etc/pf/geoallow"
pass in on egress proto tcp from any port > 1023 \
to (self) port { http https }
pass in on egress proto tcp from port > 1023 \
to (self) port http rdr-to 127.0.0.1 port 8880
pass in on egress proto tcp from port > 1023 \
to (self) port https rdr-to 127.0.0.1 port 8443
relayd.conf(5):
relay httpredir { # without geoblocking
listen on 0.0.0.0 port http
listen on 0.0.0.0 port https tls
protocol httpproto
forward to port 19000
forward to port 17000
}
http protocol httpproto {
return error
block
match request header "Host" value "somesite.somewhere" \
forward to tag httpd
match request path "/.well-known/acme-challenge/*" \
forward to tag acme
pass request tagged httpd method HEAD
pass request tagged httpd method GET
pass request tagged httpd method POST
pass request tagged acme method GET
}
relay httpredirgeo {# with geoblocking
listen on 0.0.0.0 port 8880
listen on 0.0.0.0 port 8443 tls
protocol httpprotogeo
forward to port 19000
forward to port 8083
forward to port 80
forward to port 2
forward to port 18000
forward to port 17000
}
http protocol httpprotogeo {
return error
block
match request header "Host" value "somesite.somewhere" \
forward to tag httpd
match request path "/.well-known/acme-challenge/*" \
forward to tag acme
match request header "Host" value "webm.somesite" path "/SOGo/*" \
forward to tag dav
match request tagged dav header set "X-Real-IP" \
value "https://$REMOTE_ADDR;
match request tagged dav header set "X-Forwarded-By" \
value "$SERVER_ADDR:$SERVER_PORT"
match request tagged dav header set "X-Forwarded-For" \
value "$REMOTE_ADDR"
match request tagged dav header set \
"x-webobjects-server-protocol" value "HTTP/1.0"
match request tagged dav header set \
"x-webobjects-remote-host" value "127.0.0.1"
match request tagged dav header set \
"x-webobjects-server-name" value "webm.somesite"
match request tagged dav header set "x-webobjects-server-port" \
value "$SERVER_PORT"
pass request tagged httpd method HEAD
pass request tagged httpd method GET
pass request tagged httpd method POST
pass request tagged acme method GET
pass request tagged dav method HEAD
pass request tagged dav method GET
pass request tagged dav method POST
pass request tagged dav method PUT
pass request tagged dav method DELETE
pass request tagged dav method MKCOL
pass request tagged dav method MOVE
pass request tagged dav method OPTIONS
pass request tagged dav method PROPFIND
pass request tagged dav method REPORT
pass request tagged dav method PROPPATCH
}
Strange relayd(8) logs meaning?
Hello, I have relayd(8) in front of nginx(8) to render a local Nextcloud instance. From time to time, the Nextcloud client fails saying "Host not found" which has no sense. The whole workstation still accesses the network and can resolve anything. relayd(8) listens on em1 IP and uses http protocol. nginx(8) listens on localhost. I have noted that relayd(8) writes such following entries in syslog when the Nextcloud client fails: May 18 16:45:54 server relayd[39533]: relay https_lan_relay, session 2816 (1 active), nextcloud, 192.168.0.48 -> :9081, done, PROPFIND -> 127.0.0.1:9081; PROPFIND; PROPFIND; PROPFIND; PROPFIND; PROPFIND; PROPFIND; REPORT; May 18 16:46:42 server relayd[97191]: relay https_lan_relay, session 3091 (1 active), nextcloud, 10.15.5.76 -> :9081, done, GET -> 127.0.0.1:9081; GET; PROPFIND; GET; GET; PROPFIND; GET; Are such logs (the HTTP commands pipelined with ;) indicating something weird happening on relayd or isn't it a clue for anything ; and I must dig somewhere else? Thank you, Joel C.
Re: A speed test with Iperf , Relayd and PF
On 2022-05-13, Fabrizio Francione wrote:
> Code:
> tcp connection fixup {
> tcp nodelay
> }
>
> relay IPERF_TEST{
> listen on 10.10.10.2 port 6740
> forward to 192.168.20.9 port 6670
> protocol fixup
> }
> With IPERF I obtain a speed of 144Mbps .
Why use nodelay? That disables Nagle and is normally only wanted for
interactive protocols like SSH. High chance that will be slowing
things down.
https://en.m.wikipedia.org/wiki/Nagle%27s_algorithm
> If instead, I deactivate the relayd function and using a simple PF
> redirecting with
>
> Code:
>
> pass in on em0 proto {tcp} from any to em0 port 6740 rdr-to 192.168.20.9
> port 6670
>
> I obtain a speed of 892 Mbps.
rdr-to and relayd TCP proxies are totally different things.
--
Please keep replies on the mailing list.
Re: relayd blocking by IP
On Thursday, May 5, 2022, Stuart Henderson wrote: > > > not quite, PF is looking up the IP in the table to decide which port > number to use > > then the different port number is handled in relayd to pick between > two contexts: > > one does not inspect Host (for those requests coming from > addresses on "geoallow") > > the other (for all other requests) does inspect Host > > > Understood. Also possible this way. -- Atenciosamente, Fabio Martins (+5521) 97914-8106 (Signal) https://www.linkedin.com/in/fabio1337br/
Re: relayd blocking by IP
On 2022-05-05, Fabio Martins wrote: > On Thursday, May 5, 2022, Marcus MERIGHI wrote: > >> Hello Stuart, Hello Fabio, >> >> thanks for reading and suggesting! >> >> >> Exactly, though it is going to be relayd that is listening and >> forwarding to the application (or not, in case of geoblocking). >> >> Marcus >> > > This way you are only blocking per IP, not Host. not quite, PF is looking up the IP in the table to decide which port number to use then the different port number is handled in relayd to pick between two contexts: one does not inspect Host (for those requests coming from addresses on "geoallow") the other (for all other requests) does inspect Host
Re: relayd blocking by IP
On Thursday, May 5, 2022, Marcus MERIGHI wrote: > Hello Stuart, Hello Fabio, > > thanks for reading and suggesting! > > > Exactly, though it is going to be relayd that is listening and > forwarding to the application (or not, in case of geoblocking). > > Marcus > This way you are only blocking per IP, not Host. I thought you needed to analyze the "Host: " inside the request before taking the decision, per this statement: - I need to block http/s traffic, but only for some Host: header values. I.e. domain "xyz.abc" should be reachable, domain "klm.opq" not, both behind the same IP. -- If https traffic inspection is not necessary, no need to add a reverse proxy/httpd. -- Atenciosamente, Fabio Martins (+5521) 97914-8106 (Signal) https://www.linkedin.com/in/fabio1337br/
Re: relayd blocking by IP
Hello Stuart, Hello Fabio, thanks for reading and suggesting! fosf...@gmail.com (Fabio Martins), 2022.05.04 (Wed) 22:29 (CEST): > On Wednesday, May 4, 2022, Stuart Henderson > wrote: > > On 2022-05-04, Marcus MERIGHI wrote: > > > I need to block http/s traffic, but only for some Host: header values. > > > I.e. domain "xyz.abc" should be reachable, domain "klm.opq" not, both > > > behind the same IP. > > > > > > This rules out blocking with PF. > > > > > ... > > > > > > Thanks in advance for any pointers! > > > > Maybe redirect connections from the PF table to a different port, then > > handle the two ports differently in relayd? This is one of the "OMG, why didn't i think of that myself" moments. Thanks for the clue stick! pseudo code, order matters: pass in on egress from any to port 443 rdr-to $relayd port 8443 pass in on egress from to port 443 rdr-to $relayd port 9443 > This may be possible to do via httpd listening on different ports for each > domain, since they share the same IP address. Exactly, though it is going to be relayd that is listening and forwarding to the application (or not, in case of geoblocking). Marcus
Re: relayd blocking by IP
On Wednesday, May 4, 2022, Stuart Henderson wrote: > On 2022-05-04, Marcus MERIGHI wrote: > > Hello! > > > > I need to block http/s traffic, but only for some Host: header values. > > I.e. domain "xyz.abc" should be reachable, domain "klm.opq" not, both > > behind the same IP. > > > > This rules out blocking with PF. > > > ... > > > > Thanks in advance for any pointers! > > Maybe redirect connections from the PF table to a different port, then > handle the two ports differently in relayd? > > -- > Please keep replies on the mailing list. This may be possible to do via httpd listening on different ports for each domain, since they share the same IP address. -- Fabio Martins -- Atenciosamente, Fabio Martins (+5521) 97914-8106 (Signal) https://www.linkedin.com/in/fabio1337br/
Re: relayd blocking by IP
On 2022-05-04, Marcus MERIGHI wrote: > Hello! > > I need to block http/s traffic, but only for some Host: header values. > I.e. domain "xyz.abc" should be reachable, domain "klm.opq" not, both > behind the same IP. > > This rules out blocking with PF. > > I looked at relayd(8)/relayd.conf(5) next. > I found "from address[/prefix]" in the "FILTER RULES" section. > But relayd.conf(5) does not seem to have a table option for this > purpose, as pf.conf(5) does. > > So it would take one config line per IP or Network; with > > $ wc -l /etc/pf/geoallow > 20649 /etc/pf/geoallow > > this would bloat my relayd.conf quite a bit :-) > > Have I missed something in relayd.conf(5)? > Any other ideas to solve the task? > > Thanks in advance for any pointers! Maybe redirect connections from the PF table to a different port, then handle the two ports differently in relayd? -- Please keep replies on the mailing list.
