Re: mountd
On Tue, Jan 09, 2024 at 04:16:43AM +0300, 4 wrote: > i'm quoting the man page for mountd: > The -n flag historically allowed clients to use non-reserved ports when > communicating with mountd. In OpenBSD, a reserved port is always used. > "reserved port". "always".. however the port is different each time. how to > deal with this? > resreved means that the port number is below 1024. The RPC system, (which is used to implement NFS) iuses portmapper to determine which service runs on which port. What problem are you trying to solve? -Otto
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: 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...
>> > *
TSO and LRO while forwarding traffic
Hello Misc, I've got a question about TSO and LRO: How does enabling TSO and/or LRO on the Ethernet cards of a network device that will serve as a router and firewall affect the forward traffic of users accessing the internet behind this device? In short, should I keep these features on or turn them off in my OpenBSD firewall? What is the OpenBSD recommendation? Thank you in advance for your answers.
mountd
i'm quoting the man page for mountd: The -n flag historically allowed clients to use non-reserved ports when communicating with mountd. In OpenBSD, a reserved port is always used. "reserved port". "always".. however the port is different each time. how to deal with this?
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
> > * 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 /
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 verbose and then monitor with something like:
relayctl log verbose
tail -f /var/log/daemon | grep relay
You could also add a first server block that is only served when other
blocks
OpenBSD 7.4 USB-Tethering Google Pixel with GrapheneOS
Hi guys
Happy New Year! Hope you all started well ;-)
Unfortunately the USB-Tethering does not work on OpenBSD7.4-stable with
Google Pixel 6a or Google Pixel 8 pro, both running latest stable
GrapheneOS.
1. Laptop running OpenBSD 7.4-stable with latest patches and updates:
kern.osrelease=7.4
kern.version=OpenBSD 7.4 (GENERIC.MP) #2: Fri Dec 8 15:39:04 MST 2023
hw.machine=amd64
hw.model=Intel(R) Core(TM) i5-4310U CPU @ 2.00GHz
hw.vendor=Hewlett-Packard
hw.product=HP EliteBook 840
2. Smartphones running latest stable GrapheneOS:
Google Pixel 6a
Google Pixel 8 pro
dmesg on OpenBSD (Pixel 6a):
ugen0 at uhub0 port 2 "Google Pixel 6a" rev 2.10/5.10 addr 7
dmesg on OpenBSD (Pixel 8 pro):
ugen0 at uhub0 port 2 "Google Pixel 8 Pro" rev 2.10/5.15 addr 7
Unfortunately no access to 'File Transfer' or 'USB tethering'.
('ifconfig' shows no additional interface and 'mtp-connect' exits with
error):
23:11 root@hp:~# mtp-connect
libmtp version: 1.1.21
Device 0 (VID=18d1 and PID=4ee1) is a Google Inc Nexus/Pixel (MTP).
libusb_detach_kernel_driver() failed, continuing anyway...: Device not
configured
Android device detected, assigning default bug flags
23:13 root@hp:~#
I tested the USB-Cable and -ports, they are working ;-)
It seems like something is missing?
Can you help me or point me into the right direction?
Please let me know if you need any further information.
Thanks a lot
Klaus
P.S. btw.
Same constellation (Multi-OS-Boot on same Laptop, same Phones, same
USB-cable) on Linux is working:
dmesg on Devuan GNU/Linux daedalus
Linux hp840 6.1.0-17-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.69-1
(2023-12-30) x86_64 GNU/Linux
[ 2855.880610] usb 2-2: new high-speed USB device number 25 using
xhci_hcd
[ 2856.032202] usb 2-2: New USB device found,
idVendor=18d1,idProduct=4eeb, bcdDevice= 5.10[ 2856.032215] usb 2-2:
New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2856.032221] usb 2-2: Product: Pixel 6a
[ 2856.032225] usb 2-2: Manufacturer: Google
[ 2856.032229] usb 2-2: SerialNumber: 28011JEGR10193
[ 2856.058155] cdc_ncm 2-2:1.0: MAC-Address: a6:16:d2:6e:fa:eb
[ 2856.058396] cdc_ncm 2-2:1.0 usb0: register 'cdc_ncm' at usb
:00:14.0-2, CDC NCM (NO ZLP), a6:16:d2:6e:fa:eb
