Re: Communication between hosts on different network interfaces
On 1/6/24 15:09, Ibsen S Ripsbusker wrote: Dear colleagues, I have various network appliances that I don't really trust, like a printer. I have these plugged into an unmanaged switch and connected to network interface igc2. I want to allow the igc1 network to make web requests to the igc2 network, and I want the igc2 network to have very restricted access outside of igc2. what does a printer need internet access for? nevermind. Don't answer that. It's the 21st century. Many people think their bloomin' thermostats should have Internet access...(I'm really close to replacing my non-internet connected digital programmable thermostat with a 100% mechanical. Because...they don't suck) (My main computer is connected to network interface igc1. And the egress interface is igc0.) MY QUESTION: What would be a normal way of achieving this? let's abstract this a bit... (in large part because a sequence of letters and numbers confuses me quickly.) So you have a trusted network, an untrusted network, and of course, the Internet, which we will just call "The Evil". While you can do it with a bridge, I don't want to think that hard. And it would be a lot of work. [snip bridge stuff] I also tried setting different subnets. yeah. that's the way I'd go. trusted: /etc/hostname.igc1:>inet 192.168.2.1/24 untrusted: /etc/hostname.igc2: inet 192.168.3.1/24 With this everything works as I want except that the only way I figured out to allow hosts on 192.168.2.1/24 to access 192.168.3.1/24 was with NAT, and that can't be right. yeah, the problem is, it sounds like your barrier machine is not your primary gateway/firewall. So when your trusted machine in 192.168.2/24 talks to an address in 192.168.3/24, it talks to your primary gateway, and your gateway says, "whoa, dude. wazzat?" I'd fix this by making your main firewall the barrier machine. This would require a three or more port firewall. Pass in from trusted to anywhere. block in quick on untrusted to trusted Pass from untrusted to anywhere (but trusted is already blocked) Failing that, with a separate barrier machine, you will need to add a static route for the 192.168.3/24 subnet to point to the "trusted" address of your barrier machine. That way, when your trusted network machines try to access the untrusted network, they know to route through your barrier machine. Every single trusted machine that wants to access something in that subnet will need that extra route added. Clumsy at best (probably doable with the DHCP server. I just glanced, looks kinda ugly). I guess if there is only one untrusted device, you could just use an inbound NAT tunnel for whatever ports need to access that device, then just use the barrier's IP address to access the device. But I don't normally think in quantities of one, and this doesn't scale well. But if there's only one device, or several devices, but they can all be hit on different ports, that's an option. Another way to do it is with two NATting firewalls: Evil <--[NAT-FW] <- untrusted network [NAT-FW] <- trusted network. (internet) (192.168.3/24) (192.168.2/24) traffic flows unimpeded in the direction of the arrows, and is blocked going backwards. Your trusted machines can hit untrused machines or the internet, untrusted machines can hit the Internet, but they can't dig through to your trusted network. Yeah, the down side is that the trusted network has to jump through two routers, so the untrusted network potentially has better access than the trusted network, and that's just not fair. But ... it's easy. I've done the opposite, what I call "portable DMZ"s, where untrusted machines need access to the Internet but shouldn't be allowed to touch the trusted machines, but unlike your situation, the untrusted machines don't need to be accessed by the trusted. Small machine, two NICs. One NIC is DHCP to the trusted network, NAT and DCHP server on the untrustedv side, maybe a logging DNS server. Block all from the untrusted to the trusted subnet, pass everything else (internet). These don't need those inbound static routes. Nick.
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: Communication between hosts on different network interfaces
On Sat, Jan 6, 2024, at 2:09 PM, Ibsen S Ripsbusker wrote: > I also tried setting different subnets. > > /etc/hostname.igc1: > inet 192.168.2.1/24 > > /etc/hostname.igc2: > inet 192.168.3.1/24 This is what I have done, with a pf rule to block connections originating from my less-trusted network to my more-trusted network. With the IP forwarding sysctl set, no routing magic or NAT is required. It works well for both IPv4 and IPv6. Brian
Re: chrome + twm -> context menus disappear
On Sat, Jan 06, 2024 at 01:19:24PM +, Roderick wrote: When I use chrome with twm, context menus, for example the ones that appear by clicking the right mouse button on a link, disappear immediately after clicking, so that I do not have time to select anything. This does not happen with fvwm or cwm. And if I leave twm, run cwm or fvwm, and come back to twm, the problem I saw in the vtwm mailing list a similar issue occurs in Firefox if "AutoRaise" is set. This issue also occurs in twm. I do not know about chrome, but to correct Firefox you can try this: 1. In Firefox go to "about:config" 2. set "widget.gtk.grab-pointer" equal to "1" 3. Restart Firefox Maybe chrome has a similar setting ? HTH John
Communication between hosts on different network interfaces
Dear colleagues,
I have various network appliances that I don't really trust, like
a printer. I have these plugged into an unmanaged switch and
connected to network interface igc2.
I want to allow the igc1 network to make web requests to the igc2
network, and I want the igc2 network to have very restricted access
outside of igc2.
(My main computer is connected to network interface igc1.
And the egress interface is igc0.)
MY QUESTION: What would be a normal way of achieving this?
For further clarification, I provide what I have tried so far that
did not turn out as I wanted.
I tried with bridging igc1 and igc2 and setting tags
in hostname.igc{1,2}. I configured the bridge as specified
in the FAQ except I also added lines like this
in /etc/hostname.bridge0.
rule pass in on igc1 tag white
rule pass in on igc2 tag yellow
(The tag names are the colors of the ethernet cables.)
The bridge worked exactly like I expected except that it seemed
tags weren't applied, based on what I saw in pfctl and tcpdump.
Since the tags weren't applied, I couldn't restrict
the communication as I wanted.
I also tried setting different subnets.
/etc/hostname.igc1:
inet 192.168.2.1/24
/etc/hostname.igc2:
inet 192.168.3.1/24
With this everything works as I want except that
the only way I figured out to allow hosts on 192.168.2.1/24
to access 192.168.3.1/24 was with NAT, and that can't be right.
With appreciation,
Ibsen
Re: chrome + twm -> context menus disappear
It seems the bug (or feature?) is known since long ago: https://bugs.chromium.org/p/chromium/issues/detail?id=388924 Indeed, when I apply twm f.focus to the chrome window, the problem disappears. I had also the problem with the newest version of firefox on FreeBSD, but did not try other wm than twm. I use there freebsd-esr that till now does not have the problem. What did change with chrome on 2014 and with firefox jet? Rod. Am Sa., 6. Jan. 2024 um 13:19 Uhr schrieb Roderick : > > Not only on a Samsung nc10 nettop with OpenBSD 7.4 I have the following > problem: > > When I use chrome with twm, context menus, for example the ones that > appear by clicking the right mouse button on a link, > disappear immediately after clicking, so that I do not have time to > select anything. ...
Re: Support Update
Hello once more, Ingo Schwarze wrote on Sat, Jan 06, 2024 at 03:16:49PM +0100: > Kihaguru Gathura wrote > on Tue, Jan 02, 2024 at 03:53:21PM +0300: >> 0 >> C Kenya >> P >> T Nairobi >> Z P.O. Box 30164-00100 >> O IFINAX Ltd >> I Kihaguru Njenga Gathura >> A Bishops Road >> M info@ifinax. net > As far as i can see, this is the only line you want to change, > but the new version of the line is malformed: it must not contain > angle brackets. > > It is not clear to me whether you want > > M i...@ifinax.net > > or > > M i...@pqscript.com > > or even something else? Apart from the HTTP issues reported earlier, i see issues with your SMTP configuration as well: $ date Sat Jan 6 15:21:00 CET 2024 $ host -t any pqscript.com Host pqscript.com not found: 3(NXDOMAIN) This is not good because a domain must have at least SOA and MX records to be usable for SMTP. $ host -t soa ifinax.net ifinax.net has SOA record ns1.safaricombusiness.co.ke. \ EnterpriseISPSystems.Safaricom.co.ke. 2023121202 3600 1800 1209600 86400 $ host -t mx ifinax.net ns1.safaricombusiness.co.ke Using domain server: Name: ns1.safaricombusiness.co.ke Address: 41.203.208.129#53 Aliases: ifinax.net mail is handled by 0 rat-03.safaricombusiness.co.ke. ifinax.net mail is handled by 0 rat-04.safaricombusiness.co.ke. ifinax.net mail is handled by 0 rat-01.safaricombusiness.co.ke. ifinax.net mail is handled by 0 rat-02.safaricombusiness.co.ke. $ telnet rat-03.safaricombusiness.co.ke smtp Trying 41.203.208.141... Connected to rat-03.safaricombusiness.co.ke. Escape character is '^]'. 220 thk-tes-rat05.safaricombusiness.co.ke ESMTP MAIL From: 250 sender ok RCPT To: 550 #5.1.0 Address rejected. QUIT 221 thk-tes-rat05.safaricombusiness.co.ke Connection closed by foreign host. The identical problem occurs when i relay the mail via the official outgoing mailserver of the Karlsruhe Institute of Technology: Reporting-MTA: dns; smarthost.kit.edu Action: failed Final-Recipient: rfc822;i...@ifinax.net Status: 5.0.0 Remote-MTA: dns; rat-02.safaricombusiness.co.ke Diagnostic-Code: smtp; 550 #5.1.0 Address rejected. So please fix your mail server first, and then tell me which email address you want listed after that. Yours, Ingo >> U > > While we are sorting this out, can we please also add a working > WWW URI? I mean, a "Ltd" company almost certainly has a website > nowadays, and listing that would be very helpful for users. > > However, this does not look good: > >$ date > Sat Jan 6 15:01:57 CET 2024 >$ printf "GET / HTTP/1.0\r\n\r\n" | nc ifinax.net http > HTTP/1.0 302 Found > Connection: close > Content-Length: 486 > Content-Type: text/html > Date: Sat, 06 Jan 2024 14:02:15 GMT > Location: https://ifinax.com/ > Server: OpenBSD httpd > > > [ ... snip ... ] > >$ printf "GET / HTTP/1.0\r\n\r\n" | nc -cvD ifinax.com https > Connection to ifinax.com (41.90.23.242) 443 port [tcp/https] succeeded! > TLS handshake negotiated TLSv1.3/TLS_AES_256_GCM_SHA384 with host ifinax.com > Peer name: ifinax.com > Subject: /CN=ifinax.com > Issuer: /C=US/O=Let's Encrypt/CN=R3 > Valid From: Fri Nov 3 08:43:56 2023 > Valid Until: Thu Feb 1 08:43:55 2024 > Cert Hash: > SHA256:aa6ea558a0d1e76067225762f3dbd8982cf5cbc73f1c66b9cc47111db05f65b0 > OCSP URL: http://r3.o.lencr.org >$ echo $? > 0 > > It appears the TLS TCP connection to the https port works, but then > the web server immediately closes the connection instead of waiting > for HTTP requests. > > Can you fix the server such that we can add > > U https://ifinax.com/ > > or should a different URI be listed? > > Until these issues are worked out, i refrain from touching the existing > entry for Kihaguru Njenga Gathura, for now. > >> B +254 7 0697 0697 >> X >> N OpenBSD consulting. Speciality in web applications >> development with OpenBSD-httpd web server, PostgreSQL DBMS, FastCGI >> protocol and C programming language.
Re: Support Update
Hello, Kihaguru Gathura wrote on Tue, Jan 02, 2024 at 03:53:21PM +0300: > 0 > C Kenya > P > T Nairobi > Z P.O. Box 30164-00100 > O IFINAX Ltd > I Kihaguru Njenga Gathura > A Bishops Road > M info@ifinax. net As far as i can see, this is the only line you want to change, but the new version of the line is malformed: it must not contain angle brackets. It is not clear to me whether you want M i...@ifinax.net or M i...@pqscript.com or even something else? > U While we are sorting this out, can we please also add a working WWW URI? I mean, a "Ltd" company almost certainly has a website nowadays, and listing that would be very helpful for users. However, this does not look good: $ date Sat Jan 6 15:01:57 CET 2024 $ printf "GET / HTTP/1.0\r\n\r\n" | nc ifinax.net http HTTP/1.0 302 Found Connection: close Content-Length: 486 Content-Type: text/html Date: Sat, 06 Jan 2024 14:02:15 GMT Location: https://ifinax.com/ Server: OpenBSD httpd [ ... snip ... ] $ printf "GET / HTTP/1.0\r\n\r\n" | nc -cvD ifinax.com https Connection to ifinax.com (41.90.23.242) 443 port [tcp/https] succeeded! TLS handshake negotiated TLSv1.3/TLS_AES_256_GCM_SHA384 with host ifinax.com Peer name: ifinax.com Subject: /CN=ifinax.com Issuer: /C=US/O=Let's Encrypt/CN=R3 Valid From: Fri Nov 3 08:43:56 2023 Valid Until: Thu Feb 1 08:43:55 2024 Cert Hash: SHA256:aa6ea558a0d1e76067225762f3dbd8982cf5cbc73f1c66b9cc47111db05f65b0 OCSP URL: http://r3.o.lencr.org $ echo $? 0 It appears the TLS TCP connection to the https port works, but then the web server immediately closes the connection instead of waiting for HTTP requests. Can you fix the server such that we can add U https://ifinax.com/ or should a different URI be listed? Until these issues are worked out, i refrain from touching the existing entry for Kihaguru Njenga Gathura, for now. Yours, Ingo > B +254 7 0697 0697 > X > N OpenBSD consulting. Speciality in web applications > development with OpenBSD-httpd web server, PostgreSQL DBMS, FastCGI > protocol and C programming language.
chrome + twm -> context menus disappear
Not only on a Samsung nc10 nettop with OpenBSD 7.4 I have the following problem: When I use chrome with twm, context menus, for example the ones that appear by clicking the right mouse button on a link, disappear immediately after clicking, so that I do not have time to select anything. This does not happen with fvwm or cwm. And if I leave twm, run cwm or fvwm, and come back to twm, the problem disappears for a while, but after one, two or three context menus properly displayed, then the problem is again there. Running with env XDG_SESSION_TYPE=x11 XDG_SESSION_DESKTOP=twm chrome does not help. Do someone have any idea what is happening? I used for a while fvwm, I like cwm, but I used twm the most of my life, configured it during years to work comfortable with it, I would prefer to continue use it and not allow Google to decide what wm I use. Rod.
