Background:
beta# uname -a
OpenBSD beta.philomathiclife.com 6.9 GENERIC.MP#3 amd64
beta# dhcpcd --version
dhcpcd 9.4.0
Copyright (c) 2006-2020 Roy Marples
Compiled in features: INET ARP ARPing IPv4LL INET6 DHCPv6 AUTH PRIVSEP
beta# cat /etc/hostname.alc0
dhcp
group egress
!/etc/rc.d/dhcpcd star
Excellent reply. Thank you Stuart. Unfortunately, changing "rm -rf -- *” to “rm
-rf — !(dhcpcd)” and rebooting now causes the command to timeout:
beta# dhcpcd -U6 /var/db/dhcpcd/alc0.lease6
dhcpcd_readdumptimeout
Like before, IPv6 seems to be working fine otherwise. Any further insight?
> On Jul 2, 2021, at 8:22 AM, jslee wrote:
>
> On Fri, 2 Jul 2021, at 10:29, Zack Newman wrote:
>> When I start dhcpcd during booting the “normal” way (i.e., rcctl enable
>> dhcpcd), I am able to successfully dump the lease information
>> associated with t
According to DHCPCD(8):
-U, --dumplease [interface]
Dumps the current lease for the interface to stdout. If no
interface is given then all interfaces are dumped. Use the -4 or
-6 flags to specify an address family. If a lease is piped in
via s
> On Jul 2, 2021, at 2:15 PM, Zack Newman wrote:
>
> According to DHCPCD(8):
>
> -U, --dumplease [interface]
> Dumps the current lease for the interface to stdout. If no
> interface is given then all interfaces are dumped. Use the -4 or
>
When I was with Vultr—keyword there being “was”—I simply set up NAT66 for
Wireguard to work. I believe that if you want NDP proxying to work you need
something like ndppd (https://github.com/DanielAdolfsson/ndppd). Personally,
depending on how big of an IPv6 “snob” you are, I would leave Vultr f
Before I raise a bug report, I wanted to pass it by @misc in case I'm
confused. It appears there is an issue with link-local addresses at
least as far as route(8) is concerned. Since May 2, /var/log/messages
has been getting spammed with the following:
router$ tail -6 /var/log/messages
Jul 12 03:
Huh? Please read what I said. I literally mentioned RFC 4291 Section
2.5.6. Additionally, fe80::/10 _is_ defined by RFC 4291 Section 2.4 as
"Link-Local unicast" addresses. Section 2.5.6 does not redefine that but
instead states that, at least as of now, only fe80::/64 is allowed to be
used. The po
On 7/12/23 10:20, Claudio Jeker wrote:
You are missing something. It is called the KAME hack or embedded scope.
The KAME IPv6 implementation hijacks the 2nd 16bit addr part to store the
scope_id. In some cases this embedded scope escapes in the addrs printed.
Especially the "ndp info overwritten
LOL, fair enough. Feel free to yell at me for this third question and
tell me to start a new thread.
How do you recommend I should proceed in diagnosing these "ndp info
overwritten" messages? It seems bizarre they started out of nowhere.
Before May 2, I didn't have any; but since, I get them ever
On 7/25/23 06:03, Stuart Henderson wrote:
217.169.18.56 is a network address (mask it out against the netmask,
the remaining "host bits" are all zeroes), you cannot use this (or the
broadcast address) as a host address
I am sure you were not trying to be "technical"; but for people that
don't a
An individual was kind enough to reach out and inform me that they
believe I should have not said "I am sure you were not trying to be
'technical'..." but instead "I am sure you were trying not to be
'technical'..." as the former sounded like I was suggesting Stuart was
giving bad advice by being
On 7/25/23 16:55, Polarian wrote:
Also, I didn't choose OpenBSD cause it was easy, I choose it for
security, if I slapped OpenWrt I could be done in seconds, but I want to
learn and I want to use OpenBSD for security, even at the hit of
performance, so I don't care about the complexity, only to k
I have two wg(4) interfaces: one that is a site-to-site tunnel (i.e.,
exactly one wgpeer where both sides have wgendpoint configured) in
rdomain(4) 1, and another that is used as the "server" for roaming VPN
clients in rdomain(4) 0. Last week I ran ifconfig wg1 destroy, replaced
the wgkey and wgps
On 3/20/2024 20:56 Kirill Miazine wrote:
Like in this thread, I guess:
https://marc.info/?t=16964239631&r=1&w=2
Indeed. Thanks for the link.
If anyone's got any good suggestions on how to do VPNs with 2FA
on an OpenBSD gateway for non-technical users to access (iOS, Android,
Windows clients) I'd love to hear them.
I could bodge something together with openvpn and TOTP but it doesn't
exactly spark joy.
Ideally the VPN server would be
For the past 1.5 years or more, I have dealt with consistent
terminations of dhcpcd(8). I "solved" this by having a ksh(1) script
that runs every 30 minutes that starts it anytime it is not running.
/var/log/daemon shows the following when it terminates:
Jan 4 11:00:37 router dhcpcd[34862]: ps_
I forgot to mention that dhcpcd terminates every 5 days or so. The
timestamps of the last two times it terminated were the following:
Fri Dec 30 01:13:06 MST 2022
Wed Jan 4 11:13:09 MST 2023
Ugh, I apologize for flooding the mailing list; but I made a mistake
in my follow-up. The timestamps I provided were the timestamps I log
when my ksh script runs and detects that dhcpcd is no longer running.
The actual times per /var/log/daemon were the following:
Dec 30 00:48:15 router dhcpcd[47
On 2023-01-05, Stuart Henderson wrote:
Assuming you don't already have a dhcpcd.core somewhere from a
non-suid process, try sysctl.kern.nosuidcoredump=2, mkdir
/var/crash/dhcpcd, and see if a $PID.core shows up there.
I set the kernel state as specified and made that directory. As
mentioned be
I cannot comment on PPPoE, but I do know you have misspelled
"persistent" in your dhcpcd.conf(5) file. I don't know if it will help,
but you may try explicitly assigning an IAID to pppoe0 and perhaps use
that same IAID for ia_na and ia_pd. You say you are delegated a /48,
but you don't state how y
it's the correct spelling as in the man page and the example config file
Nope. Look again. We are not psychic, so we don't know what you
_actually_ have on your machine but instead can only go by what you
report. You _might_ have it spelled correctly on your machine, but
your initial e-mail has
Jan 27 20:59:41 nc10 unbound: [72478:0] error: udp connect failed: No
route to host for 2001:4860:4802:36::a port 53 (len 28)
Jan 27 20:59:41 nc10 unbound: [72478:0] error: udp connect failed: No
route to host for 2001:4860:4802:32::a port 53 (len 28)
Jan 27 20:59:41 nc10 unbound: [72478:0] error:
I am pretty sure it's a display/video driver issue and would like to
just disable anything I could to that effect since this will be a
headless system. Any suggestions on what I can do to troubleshoot
this further?
Have you tried booting bsd in single-user mode? Have you tried booting a
differ
I also got other tips outside the email list, and this got me going
down a rabbit hole within the BIOS. After clearing nvram, and
resetting to defaults, somehow this got it to boot up just fine. I'm
part relieved that it works, and part concerned that I have no idea
why, so I've spent the weeken
Wondering if anyone has a "best practice" for pealing IP traffic off
(in this case an AppleTV) and routing all the traffic across a
Wireguard tunnel.
Not sure what you mean by "pealing [sic] IP traffic off"; but when I
need source-based routing, I prefer using rdomain(4)s and rtable(4)s.
wg(4) i
Hey Zach
It's actually "Zack".
I thought I would try to use the pf routing option `route-to` to
accomplish this as it seemed like it might be a simple solution.
You might be able to, but I prefer using pf to only filter traffic when
I can get away with it-obviously for things like NAT I use
On 3/23/23 21:22, Jared Harper wrote:
On my server (7.2 amd64) I have gzip-static set in the server block as
documented, and it appears to work as expected. I am sorry that it
probably doesn't help your situation, but maybe the differences in
configuration can help point you in the right direction
On 2023-05-09, Stuart Henderson wrote:
Ed25519 is used for signing not encrypting. But Ed25519 keys can be
converted and used for encryption; "age" has convenience support
for doing this with Ed25519 ssh keys, and might generally be something
that works for your use case. It's not in base though
On 2023-05-14, Joel Carnat wrote:
I have unbound listening on lo0 (127.0.0.1, rdomain0) and resolv.conf
configured with "nameserver 127.0.0.1".
You can also have unbound(8) listen on lo1.
Without more information-for example, showing what pf.conf(5) contains-
there is no way we can help you.
On 6/23/23 11:19, Stephan Neuhaus wrote:
# Rule 5
match out log on em0 from athn0:network to any nat-to (em0)
# Rule 6
pass out log on em0 from athn0:network to any
Rule 5 replaces the source IP address with the IP address assigned to
em0-as well as replaces the source port (for TCP and UDP) w
Just wanted to reply that that was an excellent rebuttal. Looks like I
should have put my foot in my mouth. I am now keenly interested-and
disappointed in my (lack) of knowledge. I will practice with pf on my
machine to better understand what is happening. If/when I have something
meaningful to sa
There do appear to be contradictions in documentation as well as the pf
book. The Configuring NAT section is correct as you have seen with your
own rules.
Here is the minimum set of stateless rules that allows ICMP traffic
between my laptop and Cloudflare.
# Options.
set block-policy drop
# Mac
On 6/2l/23 9:01, Stephan Neuhaus wrote:
I'm not sure about the Configuring NAT section being
correct. I still maintain that the documentation and
observed behaviour are different.
I was lazy when I said that. I meant the example I quoted from that
section in the original reply is correct. Every
On 2023-05-15, Stuart Henderson wrote:
pass out quick on rdomain 2 to 127.0.0.1 nat-to 127.0.0.1 rtable 0
Not sure what the proper etiquette is here-in particular if I should
start a new thread seeing how this reply is over a month late-so feel
free to yell at me.
What is the purpose of the "
On 6/28/23 14:03, Rachel Roch wrote:
Running "doas ifconfig ixl3 media 10GbaseLR" gives me "SIOCSIFMEDIA:
Operation not supported" and I'm not sure why.
I don't have time to re-test this now, but I will when I do. I have an
Intel X710-DA2 flashed with the most recent firmware-the same firmware
Just checked again, and my memory did not betray me: I am unable to set
the media let alone media options. It is likely the API being too new.
ixl(4) does state that one should flash their card with "the most recent
(stable) firmware", but it appears this firmware is too new. You can
try progressi
On 6/29/23 16:34, Rachel Roch wrote:
Looking at some of the release notes staying on newer firmware would
obviously be more preferable, but I'll keep downgrading as a
last-resort if the other side of the link can't turn on autoneg.
If you end up downgrading, I would be interested in knowing the
I don't have any 10 Gbps NICs, so I cannot comment on that level of
throughput. I do have a couple 2.5 Gbps machines, and my system
saturates them with ease. No way to know if there is 7.5 Gbps more I
could get out of them without actually testing it.
Motherboard: Supermicro X13SAE flashed with n
On 7/1/23 18:26, Zack Newman wrote:
As Rachel pointed out, OpenBSD 7.3 does not work with the API of that
NIC when the newest firmware is flashed. Not sure what the most recent
version of firmware that has a working API is, but it is not a problem
for me since autonegotiation works just fine. If
On 7/3/23 11:25, Mark wrote:
I'm getting (I think once per day) "dhcpleased[59824]: sendto: Permission
denied" error message in my daemon and messages log files.
I think that's happening due to my PF configuration.
Certainly could be. If this happens consistently around a particular
time, you
On 7/3/23 12:59, Rachel Roth wrote:
For the record, "API not working" is not exclusively about mediaopt
settings. "API not working" also kills SFP DOM stats, something which
is quite useful when troubleshooting with third-parties on the other
side of your fibre link.
When someone on the othe
On 7/3/23 21:14, Mark wrote:
I really do remember, under FreeBSD, I was having a similar "dmesg -a"
output
telling about DHCP's permission denied issue, and finally
I solved it with a pass rule like:
"pass log quick on $ext_if proto udp from any to any port = 67 keep state"
in /usr/local/etc/
On 7/4/23 13:08, rat1 wrote:
How do I block the network access completely for a certain program with a
blacklist or whitelist, whitelist prefered, with OpenBSD's pf(4)? My pdf
reader, music player, video player, vim and much more shouldnt have access
to networking at all. I remember it being pos
On 7/4/23 10:36, "Why 42? The lists account.":
While trying to debug the issue, it occurred to me that it could be a
network / pf problem. This doesn't seem to be the issue though, even
after I disable pf (pfctl -d), the scanner is still not seen.
However, running "tcpdump -n -e -ttt -i pflog0"
On 7/4/23 10:16, Kapetanakis Giannis wrote:
pf.conf(5) has option for user
user user
This rule only applies to packets of sockets owned by the
specified user. For outgoing connections initiated from the
firewall, this is the user that opened the co
On 7/4/23 11:51, Mark wrote:
Hi again, thanks for your detailed and very informative reply, Zack.
Much appreciated!
I wanted to re-try the fact (memories), on FreeBSD 13.2-RELEASE-p1;
I removed the pass line from my pf.conf;
"pass log quick on $ext_if proto udp from any to any port = 67"
relo
On 7/4/23 12:41, Otto Moerbeek wrote:
That may be true for reading dhcp packets, but in some cases
dhcpleased sends UDP datagram lika any ordinary program, for other
cases it uses BPF for sending. As the error reported is for sending,
it *is* possible that pf plays a role.
-Otto
I know
On 7/6/23 06:14, Why 42? The lists account. wrote:
Hi,
I see that I was not clear enough.
You were not. One of the first things in your initial e-mail was the
following:
"While trying to debug the issue, it occurred to me that it could be a
network / pf problem. This doesn't seem to be the is
While I suppose the /64 your VPS provider gives you is "enormous"
compared to IPv4, I don't find such a comparison relevant since IPv6
and IPv4 are entirely different protocols. In fact I actually think it
is small. Why? RFC 6177 (https://datatracker.ietf.org/doc/html/rfc6177)
recommends that /48
Yeah, I don't have the interest to get into it about this; but I find
it (informally) inconsistent to take an ideological stance against NAT
and not have a similar stance against NDP proxying. Networking is a lot
cleaner when it can be reasoned about with a rudimentary grasp of graph
theory where
I am only replying to this in the interest of closure since I am
already part of this thread, but disclaimer here is some tough love.
You need to stop being lazy and actually understand your network
topology, the security/privacy real or contrived-I see you adhere to
the whole security by obscuri
Clearly you cannot read either. Please show me where I said "it's -no
way- related to PF". I'm waiting...
I'll do the work for you.
"Certainly could be. If this happens consistently around a particular
time, you can 'live dangerously' and allow all traffic temporarily to
see if the issue is reso
In the interest of transparency, an individual was kind enough to teach
me that the term "martian" is in fact defined in RFC 1812:
https://www.rfc-editor.org/rfc/rfc1812#page-149
Thank you for the information.
Before I essentially echo back what Stuart said, let me clarify
something. I don't really recommend NAT over NDP proxying more than the
other way around. I was merely stating that a hack is a hack is a hack.
If you are forced to use a hack, then insisting on one over the other
is bizarre unless on
I'm sure this is obvious to people, but just in case it is not:
I pay $25/month for my VPS, and I think I could bring that down to $10
or $15 if I wanted. My VPS routes me a /48 IPv6 network...
I clearly meant "My VPS _provider_ routes me...".
> > Does that prevent dhcpd from listening on any virtual interface? I'm trying
> > to have it listen for requests on a vether in a bridge, and that fails (or
> > I'm making a mistake).
> It should work, unless are running dhclient/dhcpleased on the same machine,
> because the bpf filter will eat D
I've already upgraded the NVM firmware on the Intel card to the
latest, no change in behavior
Are you sure about that? Your dmesg says differently:
ixl0 at pci1 dev 0 function 0 "Intel X710 SFP+" rev 0x02: port 0,
FW 6.0.48442 API 1.7, msix, 8 queues, address 40:a6:b7:b3:4b:28
In contrast my
> I'd not like to rely on "something you have" and "something else you have" as
> two separate factors
Using a FIDO key (e.g., sk-ssh-ed25...@openssh.com) is two factors so long as
user verification is required. This can be enforced on the server by enabling
the PubkeyAuthOptions verify-require
Claudio Jeker :
No, this is not right. rtables are part of rdomains. So rdomain 0 has
rtable 0. rdomain 1 uses rtable 1. rdomain 2 uses rtable 2 and so on.
Now it is possible to assign an extra rtable to an rdomain but as you
found out there is no tool right now to allow this for any rdomain !=
Yes, the firmware was ancient! You'll notice the later boots
included in my dmesg show the interfaces with the latest firmware:
That's why one should exercise patience when replying. Apologize for
misreading the dmesg.
Can it run in two different rdomain(4)s? Yes, but not "natively". You'll
have to run separate copies of it for each rdomain(4). If you don't need
to actually run it in different rdomain(4)s but instead only need it
accessible, then pf(4) is your friend. Something like below should work:
pass out
62 matches
Mail list logo
