RPKI Lab setup (rpki-client)
Dear All, I wrote a small article regarding setting up a Lab environment using rpki-client to be able to test RPKI against different vendors (eventually including OpenBGP). I thought it might be of your interest: https://medium.com/@salvatore.cuzzilla/rpki-my-lab-environment-b23804a278c0 Of course your feedback is most then welcome! Regards, Salvatore.
Re: Resolved - Was: Performance tuning PF.
On 27.7.2021. 17:36, Christopher Sean Hilton wrote: > On Sat, Jul 24, 2021 at 10:24:28AM -, Stuart Henderson wrote: >> On 2021-07-23, Christopher Sean Hilton wrote: >>> On Fri, Jul 23, 2021 at 11:19:35AM -0400, Chris Hilton wrote: > > [ ...snip... ] > >>> >>> Answering my own question, it looks like the Xeon D is intels newest >>> low power stuff. I'll look there. >> >> Not particularly new, Xeon D 1500 series are from 2016 or so and still >> seem to be the range to go for if you care about good power use. Look >> at supermicro X10SDV (Xeon D 1500 series) or M11SDV (AMD EPYC). Sadly >> the M11SDV only has copper nics, X10SDV have decent ix(4) SFP+ plus >> some copper. (X10 is an older supermicro range, I'm not sure what the >> availability is like). >> >> supermicro, if you're reading, an EPYC board with a couple of SFP28 >> onboard would be nice... >> >> Sample dmesg from one of the X10SDV models - em and ix are onboard, >> ixl is a card: >> >> OpenBSD 6.8-current (GENERIC.MP) #220: Thu Dec 10 20:03:29 MST 2020 >> dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > [ ...snip ] > > Thanks to everyone for the answers that they provided. Just a late > followup here. I thought through my testing rig and realized that it > was slightly flawed. I was originally using one of the Atoms as an > iperf endpoint. That obviously messed up the tests. I retested using a > pair of machine which I know can saturate a 1Gb/s connection. My > new test rig is a pair of MacBook Pro's with Thunderbolt Ethernet > adapters: > > * With just a GigE switch connecting the test machines, I measured a > transfer rate of 942 Mb/s. The test program was iperf3. > > * With OpenBSD 6.8 running a bridged configuration on an Intel Atom > D525 with internal and external "em" nics, and filtering using pf. > I measured a rate of 775 ~ 850 Mb/s. Again, the test program was > iperf3. > maybe you can update to snapshot or 6.9 and try veb(4) instead of bridge(4) ? > Testing the routed configuration on my Atom C2758 is a little more > difficult. I'll set that up next week. I expect that the transfer rate > through that combination will be a little lower since routing is more > difficult than bridging. > > I am currently shopping Intel Xeon-D hardware. I plan to eventually > replace the D525 bridge with the C2758 running in a bridged > configuration and use new Xeon-D hardware for the router. > > -- Chris > >
Resolved - Was: Performance tuning PF.
On Sat, Jul 24, 2021 at 10:24:28AM -, Stuart Henderson wrote: > On 2021-07-23, Christopher Sean Hilton wrote: > > On Fri, Jul 23, 2021 at 11:19:35AM -0400, Chris Hilton wrote: [ ...snip... ] > > > > Answering my own question, it looks like the Xeon D is intels newest > > low power stuff. I'll look there. > > Not particularly new, Xeon D 1500 series are from 2016 or so and still > seem to be the range to go for if you care about good power use. Look > at supermicro X10SDV (Xeon D 1500 series) or M11SDV (AMD EPYC). Sadly > the M11SDV only has copper nics, X10SDV have decent ix(4) SFP+ plus > some copper. (X10 is an older supermicro range, I'm not sure what the > availability is like). > > supermicro, if you're reading, an EPYC board with a couple of SFP28 > onboard would be nice... > > Sample dmesg from one of the X10SDV models - em and ix are onboard, > ixl is a card: > > OpenBSD 6.8-current (GENERIC.MP) #220: Thu Dec 10 20:03:29 MST 2020 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP [ ...snip ] Thanks to everyone for the answers that they provided. Just a late followup here. I thought through my testing rig and realized that it was slightly flawed. I was originally using one of the Atoms as an iperf endpoint. That obviously messed up the tests. I retested using a pair of machine which I know can saturate a 1Gb/s connection. My new test rig is a pair of MacBook Pro's with Thunderbolt Ethernet adapters: * With just a GigE switch connecting the test machines, I measured a transfer rate of 942 Mb/s. The test program was iperf3. * With OpenBSD 6.8 running a bridged configuration on an Intel Atom D525 with internal and external "em" nics, and filtering using pf. I measured a rate of 775 ~ 850 Mb/s. Again, the test program was iperf3. Testing the routed configuration on my Atom C2758 is a little more difficult. I'll set that up next week. I expect that the transfer rate through that combination will be a little lower since routing is more difficult than bridging. I am currently shopping Intel Xeon-D hardware. I plan to eventually replace the D525 bridge with the C2758 running in a bridged configuration and use new Xeon-D hardware for the router. -- Chris -- -- Chris __o "All I was trying to do was get home from work." _`\<,_ -Rosa Parks ___(*)/_(*)_ Christopher Sean Hilton[chris/at/vindaloo/dot/com]
Re: iked choosing the wrong policy?
On Tue, Jul 27, 2021 at 11:18:53AM +0200, Patrick Wildt wrote: > On Tue, Jul 27, 2021 at 09:55:34AM +0200, Claudio Jeker wrote: > > On Tue, Jul 27, 2021 at 07:32:09AM -, Stuart Henderson wrote: > > > On 2021-07-27, Vladimir Nikishkin wrote: > > > > Hello, everyone. > > > > > > > > This is my iked.conf: > > > > > > > > ``` > > > > ikev2 "for-phone" passive esp \ > > > > from any to 10.0.3.2/32 \ > > > > local egress peer any \ > > > ... > > > > dstid phone.mine \ > > > > > > > ikev2 "for-laptop" passive esp \ > > > > from any to 10.0.3.3/32 \ > > > > local egress peer any \ > > > ... > > > > dstid laptop.mine \ > > > > > > Two policies with "peer any" doesn't work. > > > > > > > How to correct the setup? > > > > > > Maybe it's possible by modifying the code, I'm not sure if the > > > id is sent early enough though so it might not be possible. > > > > This is one of the biggest annoyances of iked. It does not even help to > > use different IPs and 'local' to split up the rules. Would love if someone > > would fix this. > > Using differnt IPs for local should work. The trouble is not in iked, > but in the IKEv2 protocol. The IDs are only shared in the second part > of the handshake. So until then, there's no way for the daemon to find > the correct policy, apart from looking at local or peer address. > > That's why the settings for the IKE-SA should be similar across all > policies thate could be valid, and the Child-SA can then (afaik) have > different settings. > > But still, using different IPs for local should work in -current. > The protocol is tricky but this SHOULD work as long as the policies use different dstids and it does so in my tests. I am not sure what exactly causes it to fail in this particular setup. Some more info such as a verbose log of the handshake and the OpenBSD version would be helpful to figure out what's wrong.
Re: iked choosing the wrong policy?
On Tue, Jul 27, 2021 at 09:55:34AM +0200, Claudio Jeker wrote: > On Tue, Jul 27, 2021 at 07:32:09AM -, Stuart Henderson wrote: > > On 2021-07-27, Vladimir Nikishkin wrote: > > > Hello, everyone. > > > > > > This is my iked.conf: > > > > > > ``` > > > ikev2 "for-phone" passive esp \ > > > from any to 10.0.3.2/32 \ > > > local egress peer any \ > > ... > > > dstid phone.mine \ > > > > > ikev2 "for-laptop" passive esp \ > > > from any to 10.0.3.3/32 \ > > > local egress peer any \ > > ... > > > dstid laptop.mine \ > > > > Two policies with "peer any" doesn't work. > > > > > How to correct the setup? > > > > Maybe it's possible by modifying the code, I'm not sure if the > > id is sent early enough though so it might not be possible. > > This is one of the biggest annoyances of iked. It does not even help to > use different IPs and 'local' to split up the rules. Would love if someone > would fix this. Using differnt IPs for local should work. The trouble is not in iked, but in the IKEv2 protocol. The IDs are only shared in the second part of the handshake. So until then, there's no way for the daemon to find the correct policy, apart from looking at local or peer address. That's why the settings for the IKE-SA should be similar across all policies thate could be valid, and the Child-SA can then (afaik) have different settings. But still, using different IPs for local should work in -current.
Re: iked choosing the wrong policy?
On Tue, Jul 27, 2021 at 07:32:09AM -, Stuart Henderson wrote: > On 2021-07-27, Vladimir Nikishkin wrote: > > Hello, everyone. > > > > This is my iked.conf: > > > > ``` > > ikev2 "for-phone" passive esp \ > > from any to 10.0.3.2/32 \ > > local egress peer any \ > ... > > dstid phone.mine \ > > > ikev2 "for-laptop" passive esp \ > > from any to 10.0.3.3/32 \ > > local egress peer any \ > ... > > dstid laptop.mine \ > > Two policies with "peer any" doesn't work. > > > How to correct the setup? > > Maybe it's possible by modifying the code, I'm not sure if the > id is sent early enough though so it might not be possible. This is one of the biggest annoyances of iked. It does not even help to use different IPs and 'local' to split up the rules. Would love if someone would fix this. -- :wq Claudio
Re: rdr-to across wg tunnel
And if that's not it, check wgaip settings. On 2021-07-26, deich...@placebonol.com wrote: > Did you enable forwarding? > > On July 25, 2021 10:22:58 PM MDT, Vincent Lee wrote: >>Hi all, I'm running into some trouble trying to configure a >>network. I'll try to keep it concise: >> >>Background: >> >>1. I have an OpenBSD Vultr VPS. It serves various odds and ends on >>external IP address $foo, and runs 6.9 + syspatches. >> >>2. I have a second Linux machine located on a residential network with >>unstable external IP. I'd like to avoid dynamic DNS services, having to >>configure port-forwarding, etc. >> >>3. The two machines are linked by a confirmed-working Wireguard >>tunnel. The VPS has address 10.0.0.1 and the Linux machine has address >>10.0.0.2 in the tunnel. >> >>Objective: >> >>1. I want to expose a stable, routable IP address for the Linux machine, >>regardless of the state of the residential network, by proxying through >>my VPS. >> >>2. This address should be logically distinct from the existing address >>for the VPS, as there is an overlap in the services each will >>serve. (e.g. I could plausibly serve one website from the VPS and a >>separate one from the Linux machine.) >> >>What I've tried: >> >>1. I've requested a second IP address $bar for my VPS and added it as an >>inet alias address in hostname.if. With only this configuration, pinging >>address $bar (which routes to the VPS) works. >> >>2. Next, I tried adding a pf redirect on the VPS: pass in from any to >>$bar rdr-to 10.0.0.2 >> >>3. I tried pinging and ssh-ing to address $bar after adding this rule >>and reloading pf rules, but traffic don't seem to be getting to the >>Linux box. >> >>4. I tried also a binat rule: pass on egress from 10.0.0.2 to any >>binat-to $bar with the same result. >> >>Any obvious problems, and is there an easier way to achieve my >>objective? >> >
Re: iked choosing the wrong policy?
On 2021-07-27, Vladimir Nikishkin wrote: > Hello, everyone. > > This is my iked.conf: > > ``` > ikev2 "for-phone" passive esp \ > from any to 10.0.3.2/32 \ > local egress peer any \ ... > dstid phone.mine \ > ikev2 "for-laptop" passive esp \ > from any to 10.0.3.3/32 \ > local egress peer any \ ... > dstid laptop.mine \ Two policies with "peer any" doesn't work. > How to correct the setup? Maybe it's possible by modifying the code, I'm not sure if the id is sent early enough though so it might not be possible.
Re: Permit to reprint tshirt artwork
On 2021-07-27, Tito Mari Francis Escaño wrote: > If no response on the permit to reprint, does silence means yes? No, that is not how copyright works.
Re: Permit to reprint tshirt artwork
If no response on the permit to reprint, does silence means yes? On my part there’s no plan to commercialize this and will produce nothing more than 10 shirts. Thanks so much. On Mon, Jul 26, 2021 at 2:54 PM Marcus MERIGHI wrote: > Good morning! > > titomarifran...@gmail.com (Tito Mari Francis Escaño), 2021.07.26 (Mon) > 04:28 (CEST): > > I really like the tshirt design as illustrated here: > > https://www.openbsd.org/images/tshirt-23.gif > > The most recent similar thread I could find: > > https://marc.info/?l=openbsd-misc=155439809001096 > > Marcus > > > I bought this shirt before and I was hoping to buy at least one but as > per > > https://www.openbsd.org/tshirts.html this is out of print. > > > > Can you please point me to whom I should ask permission to reprint > > t-shirts with this design? > > > > Thanks and regards. >
Re: How to use macros in acme-client.conf?
Am 25.07.21 18:54 schrieb Wolf:
> (...)
> api_url="https://acme-v02.api.letsencrypt.org/directory;
> authority letsencrypt {
> api url $api_url
> account key "/etc/acme/letsencrypt-privkey.pem"
> }
please check if you accidently inserted some control characters when
copy the snippet from the manpage to test.conf.
To test you can remove all whitespace before the word "api" and after
"$api_url".
> It fails with a syntax error:
>
> $ ./acme-client -vvv -f ../test.conf
> api_url = "https://acme-v02.api.letsencrypt.org/directory;
> ../test.conf:3: syntax error
What is "-vvv"?
Manpage on my 6.9-STABLE mentions "Specify twice..."
> It looks like the macro is loaded correctly, but the expansion fail. Are
> the macros just bugged? If not, could someone please advice me on what I
> am doing wrong?
>
macro expansion works on all of my systems.
So they are not "just bugged" ;-)
