Re: Communication between hosts on different network interfaces

2024-01-07 Thread All
This is very much doable with DHCP one liner:
add the following to your dhcpd.conf ((!) inside the block of your 
192.168.2.0/24 network)
option classless-static-routes 192.168.3.0/24 192.168.2.1;

This will install static route into all machines in 192.168.2.0/24 network.
When they will try to reach 192.168.3.0/24 machines they will send packets to 
192.168.2.1






On Sunday, January 7, 2024 at 02:03:10 p.m. GMT+9, Nick Holland 
 wrote: 





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: gre over carp

2023-12-13 Thread All
Yes, exactly. The fail-back never worked. All SAs would disappear 
and subsequent failover to slave dropped SAs there too.
There was a story behind this from the developer
somewhere in the mail archives. A while back. 






On Wednesday, December 13, 2023 at 05:55:50 p.m. GMT+9, Janne Johansson 
 wrote: 





Den ons 13 dec. 2023 kl 04:15 skrev All :

>
> >I'd like to add sasyncd in the mix and a 2nd router for higher
> availability.
> Don't do it. sasyncd is known not to work properly in failover scenarios.
>

When I ran it it did work fine for the first fail-over, but seldom (or
perhaps never?) on fail-back when the master returned, so it was ok for
giving me nice redundancy if the current carp master died, then I could
choose a suitable time after fixing this node when to take a the hit of a
new tunnel-setup as I flipped back. Never knew why it would only work
one-way for me, but we had certain issues with broadcom bnx(4) cards and
multicast at the time, so it could have been related to that.



> >Will gre over carp work?
> I think you can just try out in a vm. Don't see the reason why it would
> not.
> But perhaps there are some features that CARP interface doesn't support
> for gre.

>

Do mind that carp on software-defined switch networks might need some
settings in order to allow the virtual eth cards to send out frames with
"bogus" mac-addresses, since some hypervisors keep good track of which macs
they have given to a VM and drop ethernet frames sent with not-those
mac-addresses as source.

But to add to the original reply, I would probably go for two gre's towards
the non-carp ips, since you are using ospf anyhow, you might just tell
ospfd that one gre has a slightly higher cost than the other, and let it
deal with the new network map when one of them fails.

-- 
May the most significant bit of your life be positive.



Re: gre over carp

2023-12-12 Thread All


>I'd like to add sasyncd in the mix and a 2nd router for higher availability.
Don't do it. sasyncd is known not to work properly in failover scenarios.

>Will gre over carp work?
I think you can just try out in a vm. Don't see the reason why it would not.
But perhaps there are some features that CARP interface doesn't support for gre.



On Tuesday, December 12, 2023 at 09:01:53 p.m. GMT+9, Kapetanakis Giannis 
 wrote: 





I was wondering if anyone runs gre tunnels over carp.

We have an OpenBSD router that does ipsec over gre tunnels with remote location 
routers in order to pass voip traffic.

Routing is done with ospf on top of gre.

I'd like to add sasyncd in the mix and a 2nd router for higher availability.

Will gre over carp work? I'd prefer to use the carped IP in the tunnel and not 
the real IP of each server, so eventually 1 tunnel (active) per remote router.
How will this work when I demote master and go via backup?

Thanks,

G



Re: OpenBSD xen and AWS

2023-10-26 Thread All
Antoine, I actually did use that repo for building and running openbsd on AWS.

Unfortunately, I don't have access to physical openbsd machine to create vmdk 
now.
So, I had to resort to running qemu and installing openbsd there, followed by 
the 
steps I outlined below.

There was a community AMI in us-east-1 till about last week (openbsd 7.0). 
It is now gone though.




On Friday, October 27, 2023 at 12:21:45 a.m. GMT+9, Antoine Jacoutot 
 wrote: 





On Thu, Oct 26, 2023 at 12:01:06PM +, All wrote:

> OK, thanks to Mike and Antoine!
> I tried with t2 instances (current generation - the only choice present), yet
> still no dice. Perhaps, the issue is with how I created the image.
> I used qemu, created qcow2, installed openbsd, converted qcow2 to raw 
> and then with vmdktool converted raw to vmdk.
> AWS recognized vmdk with out any issue and booted it. But no xnf0 interfaces 
> were detected.


Try this. Somehat ugly but it works for me (tm).
https://github.com/ajacoutot/aws-openbsd





Re: OpenBSD xen and AWS

2023-10-26 Thread All
OK, thanks to Mike and Antoine!
I tried with t2 instances (current generation - the only choice present), yet
still no dice. Perhaps, the issue is with how I created the image.
I used qemu, created qcow2, installed openbsd, converted qcow2 to raw 
and then with vmdktool converted raw to vmdk.
AWS recognized vmdk with out any issue and booted it. But no xnf0 interfaces 
were detected.




On Thursday, October 26, 2023 at 04:47:18 p.m. GMT+9, Antoine Jacoutot 
 wrote: 





On Tue, Oct 24, 2023 at 10:40:34PM +, All wrote:
> Hi,
> 
> There was a time when we could run OpenBSD on AWS.
> Antoine Jacoutot did a great work to make that possible.
> These days, xnf0 interface is not being initialized. Xen is being
> identified as Xen 4.11 (12?) but no xnf interfaces are sowing up
> after boot. NetBSD has xennet0 being initiated and FreeBSD (I guess) xnb.
> 
> Did anyone else faced similar problem? 

Actually Mike Belopuhov (mikeb@) did all the work, I just assembled things.
For me me it still works with old generation of ec2 instances (e.g. t2).
New generations are using KVM but we are missing the ENA driver for network 
(and maybe other things).

Cheers!


-- 
Antoine



OpenBSD xen and AWS

2023-10-24 Thread All
Hi,

There was a time when we could run OpenBSD on AWS.
Antoine Jacoutot did a great work to make that possible.
These days, xnf0 interface is not being initialized. Xen is being
identified as Xen 4.11 (12?) but no xnf interfaces are sowing up
after boot. NetBSD has xennet0 being initiated and FreeBSD (I guess) xnb.

Did anyone else faced similar problem? 



Re: I need help to see if I can reboot new network OK. Wild misadventures with non-OpenBSD support and bad IPMI

2023-07-28 Thread All
Your network has first usable IP address 108.181.26.177, not
108.181.26.178. Also, your broadcast address is 108.181.26.191 and not
108.181.26.190






On Saturday, July 29, 2023 at 12:17:47 p.m. GMT+9, Chris Bennett 
 wrote: 





Hi.

My server company either was bought by another company or just hooked up
new IP ranges.
I have a super cheap server with 13 IP addresses. This only has ancient
Java KVM which I can't hook up to, but I can use the console preview
only as single refreshable images.

So I had to coach them along. I had to really rush due to the cutoff
date. I made a few mistakes, inet isn't spelled ine, etc.
A power screwup, my fault. Watching someone trying to use ed was
amusing. I had to get /home commented out since it needed manual fsck.

It was a long day and all night and morning today.

Everything is apparently working fine, but a little different than my
previous setup.
I would like some help to know if this setup will work after a reboot.
I really don't want to ask for more help from support.

The network is 108.181.26.176/28.

Right now,the first IP is 108.181.26.178 and the last regular address is
108.181.26.190, which might be wrong. I'm too tired to read any more
man pages or web pages. I needed more than 2hrs of sleep.
I'm super worn out, so forgive my mistakes.

Any help appreciated. I don't want the next syspatch reboot to fail.

Chris Bennett


cat /etc/hostname.em1

inet 108.181.26.178 0xfff0 108.181.26.190
inet alias 108.181.26.179 255.255.255.255
inet alias 108.181.26.180 255.255.255.255
inet alias 108.181.26.181 255.255.255.255
inet alias 108.181.26.182 255.255.255.255
inet alias 108.181.26.183 255.255.255.255
inet alias 108.181.26.184 255.255.255.255
inet alias 108.181.26.185 255.255.255.255
inet alias 108.181.26.186 255.255.255.255
inet alias 108.181.26.187 255.255.255.255
inet alias 108.181.26.188 255.255.255.255
inet alias 108.181.26.189 255.255.255.255
#inet alias 108.181.26.190 255.255.255.255

cat /etc/hosts

127.0.0.1    localhost
::1        localhost

#108.181.26.177  gateway
108.181.26.178    bennettconstruction.us
108.181.26.179    strengthcouragewisdom.rocks
108.181.26.180    mail.strengthcouragewisdom.rocks
108.181.26.181    freedomforlife.rocks
108.181.26.182    mx.freedomforlife.rocks
108.181.26.183    bsd-sec.dev
108.181.26.184    mx.bennettconstruction.us
108.181.26.185    bsd-sec.com
108.181.26.186    mail.bsd-sec.com
108.181.26.187    cowboyup.xyz
108.181.26.188    mail.cowboyup.xyz
108.181.26.189    capuchado.com
108.181.26.190    # Using for development, unassigned

cat /etc/myname

bennettconstruction.us

cat /etc/mygate

108.181.26.177
route -n show
Routing tables

Internet:
Destination        Gateway            Flags  Refs      Use  Mtu  Prio Iface
default            108.181.26.177    UGS      11    25504    -    8 em1  
108/8              108.181.26.179    UCn      11        0    -    4 em1  
108.136.59.3      00:1f:6d:eb:60:00  UHLc      0        4    -    3 em1  
108.136.125.137    00:1f:6d:eb:60:00  UHLc      0        2    -    3 em1  
108.136.179.191    00:1f:6d:eb:60:00  UHLc      0        9    -    3 em1  
108.136.182.161    00:1f:6d:eb:60:00  UHLc      0        9    -    3 em1  
108.136.235.206    00:1f:6d:eb:60:00  UHLc      0        8    -    3 em1  
108.136.238.232    00:1f:6d:eb:60:00  UHLc      0      10    -    3 em1  
108.136.248.92    00:1f:6d:eb:60:00  UHLc      0        9    -    3 em1  
108.137.2.3        00:1f:6d:eb:60:00  UHLc      0        3    -    3 em1  
108.137.73.28      00:1f:6d:eb:60:00  UHLc      0      15    -    3 em1  
108.137.74.160    00:1f:6d:eb:60:00  UHLc      0        4    -    3 em1  
108.137.155.209    00:1f:6d:eb:60:00  UHLc      0        3    -    3 em1  
108.181.26.176/28  108.181.26.178    UCn        1        2    -    4 em1  
108.181.26.177    00:1f:6d:eb:60:00  UHLch      1      44    -    3 em1  
108.181.26.178    00:25:90:6c:43:43  UHLl      0    4741    -    1 em1  
108.181.26.179    00:25:90:6c:43:43  UHLl      0    3443    -    1 em1  
108.181.26.180    00:25:90:6c:43:43  UHLl      0    4510    -    1 em1  
108.181.26.180/32  108.181.26.180    UCn        0        0    -    4 em1  
108.181.26.181    00:25:90:6c:43:43  UHLl      0    3004    -    1 em1  
108.181.26.181/32  108.181.26.181    UCn        0        0    -    4 em1  
108.181.26.182    00:25:90:6c:43:43  UHLl      0    4192    -    1 em1  
108.181.26.182/32  108.181.26.182    UCn        0        0    -    4 em1  
108.181.26.183    00:25:90:6c:43:43  UHLl      0    4767    -    1 em1  
108.181.26.183/32  108.181.26.183    UCn        0        0    -    4 em1  
108.181.26.184    00:25:90:6c:43:43  UHLl      0    8119    -    1 em1  
108.181.26.184/32  108.181.26.184    UCn        0        0    -    4 em1  
108.181.26.185    00:25:90:6c:43:43  UHLl      0    4902    -    1 em1  
108.181.26.185/32  108.181.26.185    UCn        0        0    -    4 em1  
108.181.26.186    00:25:90:6c:43:43  UHLl      0    3049    -    1 em1  
108.181.26.186

Re: libvirtd on openbsd

2023-07-27 Thread All
For some reason I didn't get reply from Stuart to my inbox. 
Its on the mailing lists though.

Thank you for your reply. I guess there are no solutions to run
VMs with a graphical interface yet. Unless, I run qemu and vnc
to a VM. 






On Monday, July 24, 2023 at 09:21:58 p.m. GMT+9, All  wrote: 





Hi,

I have installed libvirtd and virt-manager on 7.3.
It seems not matter what I do, libvirtd doesn't not want to start.
It always errors with no such group "root". I have changed unix_group
to wheel and tried staff also, but it seems no matter which group I specify
in .conf files (libvirtd.conf, qemu.conf, etc) it complains about "root" group.

Did anyone managed to run libvirtd under Openbsd? 



libvirtd on openbsd

2023-07-24 Thread All
Hi,

I have installed libvirtd and virt-manager on 7.3.
It seems not matter what I do, libvirtd doesn't not want to start.
It always errors with no such group "root". I have changed unix_group
to wheel and tried staff also, but it seems no matter which group I specify
in .conf files (libvirtd.conf, qemu.conf, etc) it complains about "root" group.

Did anyone managed to run libvirtd under Openbsd? 



Re: syslog.conf syntax to specify several clients

2023-03-09 Thread All
Thank you. I was still guessing if my understanding
was correct about !, !!, + and ++ being respectively same
but for prog vs host.
It is nice to have ti clarified.






On Thursday, March 9, 2023 at 06:16:04 p.m. GMT+9, Paul de Weerd 
 wrote: 





On Thu, Mar 09, 2023 at 04:00:24AM +, All wrote:
| Right. 
| That is what I was suspecting. I did use wildcard, but some hosts
| use completely different fqdns, so...
| Anyway, thank you and blocks per host it is then.
| 
| One question. 
| What is the difference between ++host and +host?

Same effect as !prog vs !!prog, as mentioned in the documentation:
"work the same way as their prog counterparts".  Again, from the same
syslog.conf(5) manpage:

> !!prog causes the subsequent block to abort evaluation when a message
> matches, ensuring that only a single set of actions is taken.  !* can be
> used to ensure that any ensuing blocks are further evaluated (i.e.
> cancelling the effect of a !prog or !!prog).

Please carefully read that page, it has all the information you need.


Cheers,

Paul 'WEiRD' de Weerd

-- 
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
                http://www.weirdnet.nl/                



Re: syslog.conf syntax to specify several clients

2023-03-08 Thread All
Right. 
That is what I was suspecting. I did use wildcard, but some hosts
use completely different fqdns, so...
Anyway, thank you and blocks per host it is then.

One question. 
What is the difference between ++host and +host?






On Thursday, March 9, 2023 at 01:47:44 a.m. GMT+9, Paul de Weerd 
 wrote: 





On Wed, Mar 08, 2023 at 03:39:07PM +0100, Noth wrote:
| On 07/03/2023 06:35, All wrote:
| 
| > Hi all,
| > 
| > I have a server that acts as a syslog aggregator
| > for several other servers. I was trying to see whether
| > clients can be specified on one line but I can't see anything
| > regarding syntax for such cases in man pages.
| > 
| > Do we need to specify each client on the separate line?
| > Like:
| > 
| Hi, yes you do.
| > I tried several kinds of semicolon, comma and plus syntax
| > but have not being able to make it work.
| > I can only see the very first host (eg. server1) in the log, not others.
| 
| From the man page for syslog.conf:
| 
|  # Log everything coming from host bastion to a separate file.
|  ++bastion
|  *.* /var/log/bastion
|  +*

If you look closely at the manpage[1], it says:

> Blocks starting with +host or ++host or +* work the same way as their
> prog counterparts, but they match on the hostname instead of the program
> name.

And for the 'prog counterparts' there's this bit:

> Each block of lines is separated from the previous block by a tag.  The
> tag is a line beginning with !prog and each block will be associated with
> calls to syslog from that specific program (matched using glob(7) rules).

Note the '(matched using glob(7) rules)' bit.

I have this in my /etc/syslog.conf:

--- syslog.conf snippet --
# - send logs from ubiquiti wifi access points to their own logfiles
++ubiquiti-*.alm.weirdnet.nl
*.*                                                    /var/log/ubi
+*
--

Which sends the logs from ubiquiti-1, ubiquiti-2, ubiquiti-3 and so on
and so forth to /var/log/ubi.

So, no, you do NOT need to specify each client on a separate line, but
you may have to do so if you can't glob(7) the systems together.

Cheers,

Paul 'WEiRD' de Weerd

[1]: https://man.openbsd.org/syslog.conf.5

-- 
>[<++>-]<+++.>+++[<-->-]<.>+++[<+
+++>-]<.>++[<>-]<+.--.[-]
                http://www.weirdnet.nl/                



syslog.conf syntax to specify several clients

2023-03-06 Thread All
Hi all,

I have a server that acts as a syslog aggregator
for several other servers. I was trying to see whether
clients can be specified on one line but I can't see anything 
regarding syntax for such cases in man pages.

Do we need to specify each client on the separate line?
Like:

+server1
*.blah /some/dir

+server2
*.blah /some/dir

Or can we do something like this?
+server1, +server2
*.blah /some/dir

or

+server1,server2
*.blah /some/dir

I tried several kinds of semicolon, comma and plus syntax
but have not being able to make it work.
I can only see the very first host (eg. server1) in the log, not others.



Re: Stretch/L2VPN between two datacenters

2023-01-19 Thread All
As far as I remember, I could only get gre to work over wg.
Anything that is ethernet (like tmpr, etherip, etc) didn't work.
My wild guess is that packet overhead is becoming to big as 
there is a lot of encapsulation. Also, wg interfaces do not have
same features like normal interfaces so for example you can't 
add them to bridges and the like.





On Friday, January 20, 2023 at 08:48:58 a.m. GMT+9, Lars Bonnesen 
 wrote: 





I have been fighting with this for a while now, trying to make it work
reading man pages... But it does not work as I want it to work. tcpdump can
see a lot of arp requests on bridge0, egre0, vlan172 - but nothing seems to
get to wg0. This is my ifconfig filtered for public IPs:

lo0: flags=8049 mtu 32768
        index 5 priority 0 llprio 3
        groups: lo
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
        inet 127.0.0.1 netmask 0xff00
vmx0: flags=8843 mtu 1500
        lladdr 00:50:56:b4:a5:ab
        index 1 priority 0 llprio 3
        groups: egress
        media: Ethernet autoselect (10GbaseT)
        status: active
        inet qq.ww.ee.rr netmask 0xff00 broadcast ee.rr.tt.yy
vmx1: flags=8802 mtu 1500
        lladdr 00:50:56:b4:0d:26
        index 2 priority 0 llprio 3
        media: Ethernet autoselect (10GbaseT)
        status: active
vmx2: flags=8b43
mtu 1600
        lladdr 00:50:56:b4:ef:b4
        description: corp
        index 3 priority 0 llprio 3
        media: Ethernet autoselect (10GbaseT)
        status: active
enc0: flags=0<>
        index 4 priority 0 llprio 3
        groups: enc
        status: active
pflog0: flags=141 mtu 33136
        index 6 priority 0 llprio 3
        groups: pflog
lo1: flags=8008 rdomain 1 mtu 32768
        index 8 priority 0 llprio 3
        groups: lo
wg0: flags=80c3 mtu 1420
        index 9 priority 0 llprio 3
        wgport 51820
        wgpubkey GIWFxfaaxt1VmURRvEtJkG/mZQgVLNtHuEtPa6vt/kM=
        wgpeer MSS4DjJjPtp9DsTpMbNQ1ict6jEx07DICfipOpnOUR4=
                wgendpoint aa.bb.cc.dd 51820
                tx: 1690108800, rx: 2934539600
                last handshake: x seconds ago
                wgaip 192.168.5.1/32
        groups: wg
        inet 192.168.5.2 netmask 0xff00 broadcast 192.168.5.255
egre0: flags=8943 mtu 1500
        lladdr fe:e1:ba:d0:31:5b
        index 14 priority 0 llprio 3
        encap: vnetid 172 txprio 0 rxprio packet
        groups: egre
        tunnel: inet 172.24.90.92 --> 172.24.90.91 ttl 64 nodf
vlan172: flags=8943 mtu 1500
        lladdr 00:50:56:b4:ef:b4
        index 24 priority 0 llprio 3
        encap: vnetid 172 parent vmx2 txprio packet rxprio outer
        groups: vlan
        media: Ethernet autoselect (10GbaseT)
        status: active
        inet 172.24.90.94 netmask 0xff00 broadcast 172.24.90.255
bridge0: flags=41 mtu 1500
        index 25 llprio 3
        groups: bridge
        priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto
rstp
        vlan172 flags=3
                port 24 ifpriority 0 ifcost 0
        egre0 flags=3
                port 14 ifpriority 0 ifcost 0
        vmx2 flags=3
                port 3 ifpriority 0 ifcost 0

On the other end the ifconfig is similar

wg0 is working. I can ping 192.168.5.1 from 192.168.5.2 and visa versa.

172.24.90.0/24 (vlan172) is the network that I want to strech... and is
presented to the obsd as vmx2 connected to an access port on a switch

Can anyone guide me in the right direction, thx?

Regards, Lars.

On Wed, Jan 4, 2023 at 7:24 AM Lars Bonnesen 
wrote:

> Thanks for your replies. It has been Xmas and I have been delayed, but I
> have now read up upon it. I am going for the tpmr(4). We are going to
> replicate a lot of live data from Site1 to Site2, and my experiences with
> OpenVPN is that it is great, but not high performing. So I have established
> a WireGuard connection with one OBSD on each site, and I am planning to
> tunnel tpmr through this - I guess that tpmr itself is not encrypted in any
> way?
>
> Regards, Lars.
>
> On Fri, Dec 16, 2022 at 4:30 PM deich...@placebonol.com <
> deich...@placebonol.com> wrote:
>
>> I've run L2 over an IPsec tunnel using egre (gre(4)) and bridge (bridge
>> (4)) to connect systems in different locations together.
>>
>> This was done before David Gwynne created tpmr(4).  I've been to lazy to
>> reimplement my current configuration.
>>
>> 73
>> diana
>>
>



Re: rdist remove option and default behaviour

2022-12-13 Thread All
Hmm. OK... perhaps I was not clear enough.
I was not really reporting an issue (did not think it was an issue yet)
more like I wanted to see if my understanding was correct.

I thought we could specify "destination" folder to be different from
the one used in the source (hence dest_opt_name), but I can see it is there
for a different reason.

Yes rsync is there, but I thought rdist is still being used. openbsd.amsterdam
is using it and some other folks.

Anyhow, I guess I now confirmed rdist behaviour, so all is well, thank you.






On Wednesday, December 14, 2022 at 03:08:33 p.m. GMT+9, Philip Guenther 
 wrote: 





On Mon, Dec 12, 2022 at 9:02 PM All  wrote:

> I wanted to clarify.
>
> In manpage for rdist I see that we can use option -o remove .
> remove  Remove extraneous files.  If a directory is being
>                      updated, any files that exist on the remote host that
> do
>                      not exist in the master directory are removed.  This
> is
>                      useful for maintaining truly identical copies of
>                      directories.
> However, this seems to be the default anyway.
>
> If I specify "install /tmp/" and try to copy /tmp/test.file all the files
> in /tmp/
> on the remote host will be wiped out and only test.file will remain there
> after copy.
> This behaviour seems to fit with "directory update" feature of "remove"
> (like
> if we do "install -o remove /tmp/"). Yet, "remove" was not specified above.
>
> Is my understanding of default behaviour correct?  This how it supposed to
> be working?
>

When reporting an issue, please include precise information about both
* what your desired end result / goal was, and
* what you tried, including how you invoked the command and/or the config
used.

If you leave out the former, then we'll be guessing as to why the result
wasn't what you wanted.
If you leave out the latter, then we'll be guessing as to what you did that
didn't work as desired.
...or be prepared to be accepting of people guessing wrong.

ALSO: rdist has been largely superseded by rsync, which has a much more
efficient underlying protocol and, in my experience, a more regular set of
behaviors.  Before committing to rdist and its (limited by history)
behavior, you should consider using rsync instead.


It seems you
* wanted to copy /tmp/test.file to /tmp/test.file on one or more other
hosts?
* you tried a distfile like this:
      whatever:  ( /tmp/test.file ) -> HOSTNAME
            install /tmp/;
    ?

You're correct that the latter does not achieve the former.  To achieve the
former, you would need to either
* leave off the opt_dest_name from the 'install' directive, so that rdist
would know to install the source to
  the exact same path on the target host
* specify the full target path in the 'install' directive, ala "install

/tmp/test.file"

* have multiple source files, so that it treated opt_dest_name as a target
directory and not a target path (like cp)


So, what happened with what you _did_ try?  Well, it was taken as a request
install the contents of the file "/tmp/test.file" as a file "/tmp/"!  rdist
is smart enough to know that it can't remove a directory without first
removing its contents, so it tried that and presumably failed.  If it
_could_ remove the contents it would then remove the directory...and then
fail when it tried to create a tempfile with prefix "/tmp/".

Could rdist's behavior be improved?  In some ways, yes, but lots of
sharp corners (e.g., single vs multiple source handling) would remain.
Frankly, if rsync serves your purposes, you should use it instead.


Philip Guenther



rdist remove option and default behaviour

2022-12-12 Thread All
Hi,

I wanted to clarify.

In manpage for rdist I see that we can use option -o remove .
remove  Remove extraneous files.  If a directory is being
                     updated, any files that exist on the remote host that do
                     not exist in the master directory are removed.  This is
                     useful for maintaining truly identical copies of
                     directories.
However, this seems to be the default anyway.

If I specify "install /tmp/" and try to copy /tmp/test.file all the files in 
/tmp/
on the remote host will be wiped out and only test.file will remain there
after copy. 
This behaviour seems to fit with "directory update" feature of "remove" (like 
if we do "install -o remove /tmp/"). Yet, "remove" was not specified above.

Is my understanding of default behaviour correct?  This how it supposed to be 
working? 



Re: dhcpinform only on dhcpd -u

2022-12-11 Thread All
Hi,

Perhaps I was not really clear about this.
What is the rationale to only have DHCP server
to reply to DHCPINFORM messages and never serve any ip leases
while we bind it to UDP socket? 

Currently, dhcp server will only serve ip addresses if its using raw sockets,
replaying to broadcasts etc. 



 On Wednesday, October 26, 2022 at 08:43:16 p.m. GMT+9, All  
wrote: 





Hi,

in dhcpd.c we have:

if (is_udpsock && packet->packet_type != DHCPINFORM) {
log_info("Unable to handle a DHCP message type=%d on UDP "
"socket", packet->packet_type);
return;
}

Why do we not want to process normal dhcp messages like discover/request?
If you want dhcpd to not bother with raw packets and broadcasts and just focus
on unicasts this would be a logical option. 



Re: PF rules to block out every IP from a given country

2022-12-06 Thread All
Considering you solved the issue with getting all IPs
for a given country correctly (and perhaps updating it sometimes):
1. Dump all IP addresses/ranges into a file (eg. blocked.ips)
2. add table  file  /path/to/blocked.ips
add "persist" if you want.
3. create rule to block all incoming connections from  

Alternatively, you can just create a file with IPs you allow, 
create table and write rules to allow connections from IPs
in that file. 

On Wednesday, December 7, 2022 at 09:44:34 a.m. GMT+9, Damian McGuckin 
 wrote: 






Has anybody created rules such as this and if so, do you have an example?

Stay safe - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer



Recouvrement de creances : service TOUT COMPRIS

2011-03-03 Thread Annie ALL
Si vous ne visualisez pas ce message, suivez ce lien


Pour chaque dossier transmis par Internet, 1 ? est versi ` l'association + 
Entrepreneurs du Monde ;, qui accompagne des dizaines de milliers de 
micro-entreprises dans le monde par l'attribution de microcridits accordis aux 
entrepreneurs les plus dishiritis. Le slogan de l'association est Avec presque 
rien on peut changer presque tout.







Recouvrement de criances amiable et judiciaire, France  International







depuis 1970











Pour l'encaissement de vos impayis : 
PAS DE SUCCHS, PAS D'HONORAIRES

Binificiez en plus de l'option TOUT COMPRIS
Les frais de procidure judiciaire sont avancis par FRANCE CREANCES. 


L'option TOUT COMPRIS vous est offerte ` la remise du dossier.



















Sociiti spicialisie depuis 1970, en recouvrement amiable et judiciaire, en 
France et ` l'international, FRANCE CREANCES est membre de l'ANCR et signataire 
de la charte de diontologie professionnelle qui implique la couverture par une 
assurance responsabiliti professionnelle souscrite auprhs de la Cie MMA. La 
certification ISO 9001 (dilivrie par l'AFAQ) garantit le respect des procidures 
de traitement des dossiers de recouvrement confiis ` FRANCE CREANCES. Le 
montant des encaissements est reversi au 30 de chaque mois et le bilan de la 
sociiti fait apparantre trhs clairement les sommes disponibles pour le compte 
de ses clients, en sus d'une caution bancaire. Rifirencie par des centaines de 
PME#8260;PMI, FRANCE CREANCES intervient aussi pour des grands groupes, des 
banques et des Etablissements Publics Industriels et Commerciaux. Le centre de 
traitement International de FRANCE CREANCES travaille en Anglais, Allemand, 
Espagnol, Italien, Polonais.


Pour vous disabonner, collez ce lien dans votre navigateur : 
http://www.gce-mailer-3.com/unsuscribe.asp?lang=francaisid_formulaire=4email=misc@openbsd.orgid_message=810



Visit us at http://www.aboutyoga.go.ro

2010-10-10 Thread All About Yoga
http://www.aboutyoga.go.ro