Re: Encrypt traffic using one interface
On 2021-11-03, naib+li...@xn--bimann-cta.de
wrote:
> I'm running two remote 7.0 OpenBSD boxes at a hosting provider. Both are
> connected via LAN (vio1) over a shared switch. This is a connection I do not
> trust. Thus, I want to properly secure traffic flowing over this connection.
>
> Currently I managed to set up an SA with iked. I am not able to ping the
> other host. Utilizing tcpdump, no traffic is seen on enc0 and no esp traffic
> is seen on vio1.
>
> Is there anything I've missed?
>
> /etc/iked.conf@host1:
> ikev2 \
> passive esp proto tcp \
You only have TCP in the flow config, so ping won't be covered.
I have had very strange problems with IPsec flows restricted to certain
protocols/ports before so I would try without that restriction first.
Also try with net.inet.ip.forwarding=1 if you don't already have it, I
don't think you are actually forwarding in this configuration but you
might need "weak host model" and there's no way to change that on
OpenBSD other than enabling forwarding.
> enc chacha20-poly1305 \
> group curve25519 \
> ikelifetime 12h \
> lifetime 2h bytes 2G
It won't be stopping things working here, but a 2G lifetime is really low.
> ikectl show sa@host1:
btw "ipsecctl -sa" is way easier to read if you just want to check that
flows are setup, i"ikectl show sa" output is more formatted for code debug
than user fault diagnosis.
> iked_sas: 0xc8e656727b0 rspi 0xe3281f62f2f15c57 ispi 0x0df250d3e7e7d95c
> 192.168.1.1:500->192.168.1.2:500[] ESTABLISHED r udpecap nexti
> 0x0 pol 0xc8e691ab000
> sa_childsas: 0xc8e65660b00 ESP 0x80127fcd in 192.168.1.2:500 ->
> 192.168.1.1:500 (LA) B=0x0 P=0xc8e65660100 @0xc8e656727b0
> sa_childsas: 0xc8e65660100 ESP 0xcfcdf2e0 out 192.168.1.1:500 ->
> 192.168.1.2:500 (L) B=0x0 P=0xc8e65660b00 @0xc8e656727b0
> sa_flows: 0xc8e65681000 ESP out 192.168.1.1/32 -> 192.168.1.2/32 [6]@-1 (L)
> @0xc8e656727b0
> sa_flows: 0xc8e65675400 ESP in 192.168.1.2/32 -> 192.168.1.1/32 [6]@-1 (L)
> @0xc8e656727b0
> iked_activesas: 0xc8e65660b00 ESP 0x80127fcd in 192.168.1.2:500 ->
> 192.168.1.1:500 (LA) B=0x0 P=0xc8e65660100 @0xc8e656727b0
> iked_activesas: 0xc8e65660100 ESP 0xcfcdf2e0 out 192.168.1.1:500 ->
> 192.168.1.2:500 (L) B=0x0 P=0xc8e65660b00 @0xc8e656727b0
> iked_flows: 0xc8e65675400 ESP in 192.168.1.2/32 -> 192.168.1.1/32 [6]@-1 (L)
> @0xc8e656727b0
> iked_flows: 0xc8e65681000 ESP out 192.168.1.1/32 -> 192.168.1.2/32 [6]@-1 (L)
> @0xc8e656727b0
> iked_dstid_sas: 0xc8e656727b0 rspi 0xe3281f62f2f15c57 ispi 0x0df250d3e7e7d95c
> 192.168.1.1:500->192.168.1.2:500[] ESTABLISHED r udpecap nexti
> 0x0 pol 0xc8e691ab000
>
> /etc/pf.conf@host1:
> [...]
> set skip on lo
> set skip on enc0
> match in all scrub (no-df)
>
> block return
> block in from { $ipv4_exthost, $ipv6_exthost }
> block in quick on egress from $localIPs
> block out quick on egress to $localIPs
> block in quick from
>
> pass in on $int_if proto udp from 192.168.1.2 to 192.168.1.1 port 500
> pass out on $int_if proto udp from 192.168.1.1 to 192.168.1.2 port 500
> pass in on $int_if proto esp from 192.168.1.2 to 192.168.1.1
> pass out on $int_if proto esp from 192.168.1.1 to 192.168.1.2
> [...]
That looks alright from what you've shown, but we can't check anything
about the macros or which interface/s are in the "egress" group.
Use "log" on the default block rule and check tcpdump -neipflog0.
--
Please keep replies on the mailing list.
Re: mmap with the arguments PROT_NONE and MAP_STACK
overcq wrote: > However, I need to know how much of the stack is currently allocated > and how much remains only reserved. Why?
Re: Asyncronous IO
On Wed, Nov 03, 2021 at 03:37:01PM +, cho...@jtan.com wrote: > I program on OpenBSD and am writing a library which presents an API > for IO. POSIX defines an API[*] for asyncronous IO and I would like > my code to support it but this API is unavailable in OpenBSD. > > Is the lack intentional (perhaps there are other plans) or is it > simply the case that no-one has sat down and written it yet? A bit of both. AIO is not often used. Using basic poll/select or the use of libevent is much preferred to build an async API. AIO is complex and in most cases not needed. > I don't mind that the async parts will not (yet) work on OpenBSD > because I can always test them elsewhere but I would like to know > which backend API(s) I should write against and therefore what > OpenBSD intends to do regarding AIO in the future. > > Cheers, > > Matthew > > [*] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/aio.h.html > -- :wq Claudio
Re: mmap with the arguments PROT_NONE and MAP_STACK
overcq wrote: > >> However, I need to know how much of the stack is currently allocated > >> and how much remains only reserved. > > > Why? > > To be able to release reservations from the beginning of the stacks > when new in-program tasks are created. So that you can create any number > of these tasks at runtime. You are attempting to micromanage physical memory in a program which can only allocate/deallocate virtual memory address space. In any case, I would never want to run any piece of software like yours which is undoubtably pulling software with unknown memory damage into a single address space. I'm reading your approach is anti-security. And I'm giving up.
Syspatch -R failed after upgrading to 7.0, possible LLVM error
Relinking to create unique kernel failed; after applying /var/db/kernel.SHA256 /bsd> and , this
is what my relink.log looks like:
(SHA256) /bsd: OK
LD="ld" sh makegap.sh 0x gapdummy.o
ld -T ld.script -X --warn-common -nopie -o newbsd ${SYSTEM_HEAD} vers.o
${OBJS}
LLVM ERROR: out of memory
PLEASE submit a bug report to https://bugs.llvm.org/ and include the
crash backtrace.
Stack dump:
0. Program arguments: ld -T ld.script -X --warn-common -nopie -o
newbsd locore0.o [1946 object files later...] swapgeneric.o
Abort trap (core dumped)
*** Error 134 in /usr/share/relink/kernel/GENERIC.MP (Makefile:1788
'newbsd': @echo ld -T ld.script -X --warn-common -nopie -o newbsd '${SYS...)
I would include recent dmesg output but it doesn't describe anything
useful and shows a different problem in itself: Several instances of
wsmouse0 detached
ums0 detached
uhidev0 detached
uhidev0 at uhub0 port 7 configuration 1 interface 0 "Logitech USB
Optical Mouse" rev 2.00/72.00 addr 2
uhidev0: iclass 3/1
ums0 at uhidev0: 3 buttons, Z dir
wsmouse0 at ums0 mux 0
on repeat.
And here's some sysctl output:
hw.machine=amd64
hw.model=Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz
hw.ncpu=12
hw.byteorder=1234
hw.pagesize=4096
hw.disknames=sd0:c1ee24af7681944d,sd1:,sd2:af97cb0c91508e2d
hw.diskcount=3
...
hw.sensors.softraid0.drive0=online (sd2), OK
hw.cpuspeed=3192
hw.setperf=99
hw.vendor=CyberPowerPC
hw.product=C Series
hw.physmem=17071558656
hw.usermem=17071542272
hw.ncpufound=12
hw.allowpowerdown=1
hw.perfpolicy=manual
hw.smt=1
hw.ncpuonline=12
--
**/slrn is to pan as Purgatory is to Hell/**
OpenPGP_0xCB87D5427864E937.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
nvidia graphics cards: one ok, two slow: how to determine for others?
The graphics card in my PC broke (no "signal" after a few minutes) It is an NVIDIA GeForce 7100 GS. I replaced it with an NVIDIA GeForce GT 240 which I found in my "stock". But with this card I get the very slow scrolling under X again (which I posted about with a different card before: NVIDIA GeForce 8500 GT). So this is a bit confusing: why is a GeForce 7100 GS fine, while the other two are "bad"? I know I should buy an ATI card, but that's not available here. I could get a Geforce GT 710 2GB but without knowing whether it will be another "slow scrolling" card I don't want to waste 100 EUR (!) on it. Does someone have experience with this card? It seems buying a "new" PC is also not a good option right now (barely anything is available or only with very high prices). -- Address is valid for this mailing list only, please do not reply to it direcly, but to the list.
Re: futex(2) not working in inherited mmap'd anon memory
On Tue, Oct 26, 2021 at 11:29 PM Thomas Munro wrote: > When I do mmap(MAP_ANONYMOUS | MAP_SHARED) and then fork(), it seems > that futex(2) wakeups are not delivered between child and parent in > that memory. It does work as expected if I instead use > shmget(IPC_PRIVATE). Hello, This seems to be because such memory objects have no uvm_obj, which is needed by futex_get() to identify futexes. Could they have one? Or perhaps there is some other way to make a futex key in this case?
Re: dhcpleased(8) not renewing leases
On Mittwoch, 3. November 2021 14:41:08 -03 Zack Newman wrote: > dhcpleased(8) is unable to renew DHCP leases from my ISP, > Xfinity/Comcast. This in turn is causing leases to expire leading to > IPv4 drops that last between 15 and 20 seconds until a new lease can > be binded. Note that lease binding does succeed. Hi Zack, Similarily here. Did you specify a lladdr in your hostname.if after "dhcp"? I get a lease with my hardware MAC address without specifying lladdr, but it is not the right one of course. If I force the fake MAC address and then I ask for a new lease I get nothing. I'm going to write about it later together with all the pertinent infomation. Just now I am too busy with other disasters. Cheers Eike > > For about a month before the release of OpenBSD 7.0, I had been using > dhcpleased(8) instead of dhclient(8) on OpenBSD 6.9 as I wanted to be > "ahead of the curve" before the eventual release of OpenBSD 7.0. > During that time, there were no problems with lease renewals. I have > not made any hardware or software changes other than the upgrade to > 7.0. > > I've factory reset my bridge modem about a dozen times, I've changed > the MAC address of the interface connected to the modem, I've > experimented using different NICs altogether, and nothing has worked. > At the time, I "knew" it was Xfinity; so I demanded that a tech come > over and inspect the cable lines and modem. They said it was fine; > although based on Internet reviews, that doesn't say much as they are > often wrong. It wasn't until I had a slice of humble pie and actually > considered that the problem was indeed my router that I was able to > fix the problem by switching to dhcpcd which I have been already > using for DHCPv6. Sure enough, I have had no issues with IPv4 > renewals since then. > > I do know that Xfinity, at least where I am, does NOT respond to > unicast renewals for both DHCP and DHCPv6, but I am unsure if that is > relevant. Before I successfully switched to dhcpcd, I made sure to > log dhcpleased(8) over night. Here are the results: [snip]
