OpenBSD 7.5 crash under RHEL9 kvm host host
Hi all, I am trying to install an OpenBSD 7.5 vm under RHEL9 kvm host but installation crash. Installer crash immediately after detects CPU. I am using Q35 definition for this virtual machine. Changing to PC all seems to work. Do I need to reconfigure some virtio devices in guest definition or is it a bug in OpenBSD installer? Regards, C. L. Martinez
OT: SSH3 proposal
Hi all, https://blog.apnic.net/2024/02/02/towards-ssh3-how-http-3-improves-secure-shells/ Uhmm ... ssh over http/3? What do you think about it? Best regards, C. L. Martinez
Re: Problem configuring multiple wireguard tunnels
> On 15 Feb 2022, at 13:58, Stuart Henderson wrote: > > On 2022-02-15, Carlos Lopez wrote: >> But regarding the question to use different keys for every wg client? > > You have two options: > > 1. use the same 'server' key for all connections: use one wg interface > on the server > > 2. use different 'server' keys for each connection: each will need to > have its own wg interface and UDP port > > When deciding which to do, think about what you are trying to protect against. > > -- > Please keep replies on the mailing list. Totally agree Stuart …. The second option is most likely to be used. Many thanks. >
Re: Problem configuring multiple wireguard tunnels
> On 15 Feb 2022, at 10:16, Łukasz Moskała wrote: > > > > Dnia 15 lutego 2022 10:13:57 CET, Carlos Lopez napisał/a: >> Hi all, >> >> I am trying to configure multiple Wireguard road-warriors config using this >> simple config in /etc/hostname.wg0 >> >> wgkey Ls1Os9/oE0kU5jJdFp1dLpzJhtL8WIzzJ/G+7bzSEZk= >> wgport 8443 >> wgpeer 2XLLj0O6jdtx+BNCt90m2pEyJS/M2kh6WaskFTz+n1A= vgaip 10.55.55.2/32 >> vgaip 10.55.55.3/32 >> inet 10.55.55.1/28 >> description "WireGuard Network" >> up >> >> but "sh /etc/netstart wg0” returns me always the following error: >> >> ifconfig: vgaip: bad value >> >> My host is OpenBSD 6.9 fully updated …. On the other side, is it possible to >> assign different wiper keys to every client? >> >> Many thanks for your help >> > > I think it's wgaip not vgaip > - Ouch!!! …. You are right Lukasz ….. Sorry for the noise …. But regarding the question to use different keys for every wg client?
Problem configuring multiple wireguard tunnels
Hi all, I am trying to configure multiple Wireguard road-warriors config using this simple config in /etc/hostname.wg0 wgkey Ls1Os9/oE0kU5jJdFp1dLpzJhtL8WIzzJ/G+7bzSEZk= wgport 8443 wgpeer 2XLLj0O6jdtx+BNCt90m2pEyJS/M2kh6WaskFTz+n1A= vgaip 10.55.55.2/32 vgaip 10.55.55.3/32 inet 10.55.55.1/28 description "WireGuard Network" up but "sh /etc/netstart wg0” returns me always the following error: ifconfig: vgaip: bad value My host is OpenBSD 6.9 fully updated …. On the other side, is it possible to assign different wiper keys to every client? Many thanks for your help
Re: Problem with some pf table defined outside of an anchor
Uhhmm …. But this is not the case I have only referenced the
table once. Complete rules:
table persist counters
#
# Specific options for exposed services
#
exposed_tcp = "(max-src-conn 10, max-src-conn-rate 15/5, overload
flush global)"
exposed_udp = "(max-src-conn 30, max-src-conn-rate 10/1, overload
flush global)"
#
#
# Default policy rules
#
#
# Block brute force access
block quick log from label "Block access from bruteforce hosts"
#---
# Policy for inbound connections to egress interface
#---
#
# Group of rules for exposed public services
#
anchor inet from ! to (carp1) tag inet-to-enc {
pass in log (all, to pflog1) proto udp to port $pub_port keep state
$exposed_udp rdr-to $encgw01 port $pub_port
}
> On 12 Jan 2022, at 18:50, Marin BERNARD wrote:
>
> Hi,
>
> Your anchor is probably defined twice, once in the main ruleset, and
> once more in the context of the 'pub-network/_2' anchor.
>
> In such case a warning is shown to let you know that this is not
> recommended practice.
>
> From pfctl(8) man page (http://man.openbsd.org/pfctl#a):
>
>> When a rule referring to a table is loaded in an anchor, the rule
>> will use the private table if one is defined, and then fall back to
>> the table defined in the main ruleset, if there is one. This is
>> similar to C rules for variable scope. It is possible to create
>> distinct tables with the same name in the global ruleset and in an
>> anchor, but this is often bad design and a warning will be issued in
>> that case.
>
> ‐‐‐ Original Message ‐‐‐
>
> Le mercredi 12 janvier 2022 à 11:58, Carlos Lopez a
> écrit :
>
>> Hi all,
>>
>
>> I have a strange issue when I use a pf table inside an anchor. Error
>> returned is:
>>
>
>> pfctl: warning: table already defined in anchor "pub-network/_2”
>>
>
>> Table is defined in global pf.conf file. In pf.conf I have
>> defined some anchors by interface, like this:
>>
>
>> Group of rules for public network
>> =
>>
>
>> anchor "pub-network" on egress
>>
>
>> load anchor pub-network from "/etc/fwrules/publan.conf”
>>
>
>> Inside public.conf I have the rule that returns this warning:
>>
>
>> exposed_tcp = "(max-src-conn 10, max-src-conn-rate 15/5, overload
>> flush global)”
>>
>
>> anchor inet from ! to (carp1) tag inet-to-enc {
>>
>
>>pass in log (all, to pflog1) proto tcp to port $my_port keep state
>> $exposed_tcp rdr-to $encgw01 port $my_port
>>
>
>>
>
>> }
>>
>
>> How can I fix it? Or maybe am I doing some mistake?
>
Problem with some pf table defined outside of an anchor
Hi all,
I have a strange issue when I use a pf table inside an anchor. Error returned
is:
pfctl: warning: table already defined in anchor "pub-network/_2”
Table is defined in global pf.conf file. In pf.conf I have defined
some anchors by interface, like this:
# Group of rules for public network
anchor "pub-network" on egress
load anchor pub-network from "/etc/fwrules/publan.conf”
Inside public.conf I have the rule that returns this warning:
exposed_tcp = "(max-src-conn 10, max-src-conn-rate 15/5, overload
flush global)”
anchor inet from ! to (carp1) tag inet-to-enc {
pass in log (all, to pflog1) proto tcp to port $my_port keep state
$exposed_tcp rdr-to $encgw01 port $my_port
}
How can I fix it? Or maybe am I doing some mistake?
Re: Error trying to compile Suricata 6.0.1 under OpenBSD 6.8 (SOLVED)
Hi all, I have exported "CC=/usr/bin/clang" in the shell and now Suricata compiles ok. Many thanks to all for your help. On 27/1/21, 14:45, "owner-m...@openbsd.org on behalf of Carlos Lopez" wrote: HI Stuart, Many thanks for your help. I have tried to compile using "--with-clang=/usr/bin/clang" flag but same error appears... On 27/1/21, 13:49, "owner-m...@openbsd.org on behalf of Stuart Henderson" wrote: On 2021-01-27, Carlos Lopez wrote: > Hi all, > > I am trying to compile suricata 6.0.1 with some custom options and the following error is returned: > > hecking for strlcat... yes > checking for special C compiler options needed for large files... no > checking for _FILE_OFFSET_BITS value needed for large files... no > checking host os... installation for x86_64-unknown-openbsd6.8 OS... ok > checking for c11 support... no > checking for thread local storage gnu __thread support... no > configure: error: "no thread local support available." > > Any ideas? Running configure without options (only with --disable-gccmarch-native) returns the same error. > > Regards, > C. L. Martinez > It is using the wrong compiler, OpenBSD/amd64 still installs the old version of gcc as /usr/bin/gcc and some software picks this up. I suggest modifying the port to suit your needs rather than building it standalone.
Re: Error trying to compile Suricata 6.0.1 under OpenBSD 6.8
HI Stuart, Many thanks for your help. I have tried to compile using "--with-clang=/usr/bin/clang" flag but same error appears... On 27/1/21, 13:49, "owner-m...@openbsd.org on behalf of Stuart Henderson" wrote: On 2021-01-27, Carlos Lopez wrote: > Hi all, > > I am trying to compile suricata 6.0.1 with some custom options and the following error is returned: > > hecking for strlcat... yes > checking for special C compiler options needed for large files... no > checking for _FILE_OFFSET_BITS value needed for large files... no > checking host os... installation for x86_64-unknown-openbsd6.8 OS... ok > checking for c11 support... no > checking for thread local storage gnu __thread support... no > configure: error: "no thread local support available." > > Any ideas? Running configure without options (only with --disable-gccmarch-native) returns the same error. > > Regards, > C. L. Martinez > It is using the wrong compiler, OpenBSD/amd64 still installs the old version of gcc as /usr/bin/gcc and some software picks this up. I suggest modifying the port to suit your needs rather than building it standalone.
Re: Error trying to compile Suricata 6.0.1 under OpenBSD 6.8
Thanks Gonzalo. Yes I would like to compile without rust support and with GeoIP support ... On 27/1/21, 13:49, "Gonzalo Rodriguez" wrote: I don’t remember now the version we have in 6.8 but are you compiling it for some reason instead of use the package? — gonzalo > On 27. Jan 2021, at 13:31, Carlos Lopez wrote: > > Hi all, > > I am trying to compile suricata 6.0.1 with some custom options and the following error is returned: > > hecking for strlcat... yes > checking for special C compiler options needed for large files... no > checking for _FILE_OFFSET_BITS value needed for large files... no > checking host os... installation for x86_64-unknown-openbsd6.8 OS... ok > checking for c11 support... no > checking for thread local storage gnu __thread support... no > configure: error: "no thread local support available." > > Any ideas? Running configure without options (only with --disable-gccmarch-native) returns the same error. > > Regards, > C. L. Martinez
Error trying to compile Suricata 6.0.1 under OpenBSD 6.8
Hi all, I am trying to compile suricata 6.0.1 with some custom options and the following error is returned: hecking for strlcat... yes checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... no checking host os... installation for x86_64-unknown-openbsd6.8 OS... ok checking for c11 support... no checking for thread local storage gnu __thread support... no configure: error: "no thread local support available." Any ideas? Running configure without options (only with --disable-gccmarch-native) returns the same error. Regards, C. L. Martinez
Re: CARP load balancing problems under KVM
Many thanks for your help Giannis ... I am not using oVirt to manage this KVM host, only default installed tools: libvirtd, virsh ... In any case there is not any filter applied in libvirtd On 12/1/21, 20:13, "owner-m...@openbsd.org on behalf of Kapetanakis Giannis" wrote: On 12/01/2021 18:58, Carlos Lopez wrote: > Thanks Gianni, but about what interface ? KVM bridges? In theory, MAC spoofing is avoided using this option: > > bridge.ageing-time: 300 > > On 12/1/21, 17:47, "owner-m...@openbsd.org on behalf of Kapetanakis Giannis" wrote: > > Check that you have mac spoofing filter disabled on that interface. For carp to work, I have it disabled on the virtual interface on the supervisor. I use ovirt so I do it on the network profile there. This is a libvirt filter option. Maybe it's applied by default on your setup. The idea is to disable this protection and allow mac spoofing. G
Re: CARP load balancing problems under KVM
Thanks Gianni, but about what interface ? KVM bridges? In theory, MAC spoofing is avoided using this option: bridge.ageing-time: 300 On 12/1/21, 17:47, "owner-m...@openbsd.org on behalf of Kapetanakis Giannis" wrote: Check that you have mac spoofing filter disabled on that interface. G On 12/01/2021 15:30, Carlos Lopez wrote: > Hi David and misc@, > > Sorry to disturb with this.I have realized several tests this morning with two OpenBSD 6.8 carp'ed firewalls (fully patched) as kvm guests and result is the same: carp load balancing doesn't work. My host is a RedHat Enterprise Linux 8.3 with kernel .18.0-240.10.1.el8_3.x86_6 (fully patched also). I have tested all ip load balancing options under these OpenBSD virtual guests: ip, ip-unicast and ip-stealth. > > When I use only "ip" for load balancing in all carped interfaces, these appears as MASTER in both firewalls as you can see here: > > carp0: flags=8843 mtu 1500 > lladdr 00:00:5e:00:01:0a > description: Production Network > index 12 priority 15 llprio 3 > carp: carpdev vio0 advbase 1 balancing ip > state MASTER vhid 10 advskew 0 > state MASTER vhid 11 advskew 100 > groups: carp > status: master > inet 172.22.55.30 netmask 0xffe0 broadcast 172.22.55.31 > carp1: flags=8843 mtu 1500 > lladdr 00:00:5e:00:01:0c > description: Primary Public Network > index 13 priority 15 llprio 3 > carp: carpdev vio1 advbase 1 balancing ip > state MASTER vhid 12 advskew 0 > state MASTER vhid 13 advskew 100 > groups: carp > status: master > inet 172.17.35.5 netmask 0xff00 broadcast 172.17.35.255 > carp2: flags=8843 mtu 1500 > lladdr 00:00:5e:00:01:0e > description: Mgmt Network > index 14 priority 15 llprio 3 > carp: carpdev vio2 advbase 1 balancing ip > state MASTER vhid 14 advskew 0 > state MASTER vhid 15 advskew 100 > groups: carp > status: master > inet 172.22.59.1 netmask 0xfff0 broadcast 172.22.59.15 > carp3: flags=8843 mtu 1500 > lladdr 00:00:5e:00:01:10 > description: DMZ Network > index 15 priority 15 llprio 3 > carp: carpdev vio3 advbase 1 balancing ip > state MASTER vhid 16 advskew 0 > state MASTER vhid 17 advskew 100 > groups: carp > status: master > inet 172.22.54.1 netmask 0xfff8 broadcast 172.22.54.7 > carp4: flags=8843 mtu 1500 > lladdr 00:00:5e:00:01:12 > description: VPN Network > index 16 priority 15 llprio 3 > carp: carpdev vio4 advbase 1 balancing ip > state MASTER vhid 18 advskew 0 > state MASTER vhid 19 advskew 100 > groups: carp > status: master > inet 172.22.56.1 netmask 0xfff8 broadcast 172.22.56.7 > carp5: flags=8843 mtu 1500 > lladdr 00:00:5e:00:01:14 > description: Encryption Network > index 17 priority 15 llprio 3 > carp: carpdev vio5 advbase 1 balancing ip > state MASTER vhid 20 advskew 0 > state MASTER vhid 21 advskew 100 > groups: carp > status: master > inet 172.22.57.1 netmask 0xfff8 broadcast 172.22.57.7 > carp6: flags=8843 mtu 1500 > lladdr 00:00:5e:00:01:16 > description: IDPS Network > index 18 priority 15 llprio 3 > carp: carpdev vio6 advbase 1 balancing ip > state MASTER vhid 22 advskew 0 > state MASTER vhid 23 advskew 100 > groups: carp > status: master > inet 172.22.60.1 netmask 0xfff0 broadcast 172.22.60.15 > carp7: flags=8843 mtu 1500 > lladdr 00:00:5e:00:01:18 > description: Windows Network > index 19 priority 15 llprio 3 > carp: carpdev vio8 advbase 1 balancing ip > state MASTER vhid 24 advskew 0 > state MASTER vhid 25 advskew 100 > groups: carp > status: master > inet 172.22.61.1 netmask 0xfff8 broadcast 172.22.61.7 > > .. and all kvm guests behind these firewalls shows the following arp entries (172.22.55.30 is the carp'ed IP address. IP 172.22.55.28 is for fw01 and 172.22.55.29 is for fw02): > > root@stonehenge:~# ip neigh > 172.22.55.14 dev eth0 lladdr ac:1f:6b:14:6a:f6 STALE > 172.22.55.29 dev eth0 lladdr 00:50:56:a1:4d:c3 STALE > 172.22.55.5 dev eth0 lladdr ac:1f:6b:14:6c:b0 STALE > 172.22.55.30 dev eth0 INCOMPLETE > 172.22.55.28 dev eth0 lladdr 00:50:56:6f:64:aa STALE > 172.22.5
Re: CARP load balancing problems under KVM
balancing ip-stealth state MASTER vhid 10 advskew 0 state BACKUP vhid 11 advskew 100 groups: carp status: master inet 172.22.55.30 netmask 0xffe0 broadcast 172.22.55.31 carp1: flags=8843 mtu 1500 lladdr 00:00:5e:00:01:0c description: Primary Public Network index 13 priority 15 llprio 3 carp: carpdev vio1 advbase 1 balancing ip-stealth state MASTER vhid 12 advskew 0 state BACKUP vhid 13 advskew 100 groups: carp status: master inet 172.17.35.5 netmask 0xff00 broadcast 172.17.35.255 carp2: flags=8843 mtu 1500 lladdr 00:00:5e:00:01:0e description: Mgmt Network index 14 priority 15 llprio 3 carp: carpdev vio2 advbase 1 balancing ip-stealth state MASTER vhid 14 advskew 0 state BACKUP vhid 15 advskew 100 groups: carp status: master inet 172.22.59.1 netmask 0xfff0 broadcast 172.22.59.15 carp3: flags=8843 mtu 1500 lladdr 00:00:5e:00:01:10 description: DMZ Network index 15 priority 15 llprio 3 carp: carpdev vio3 advbase 1 balancing ip-stealth state MASTER vhid 16 advskew 0 state BACKUP vhid 17 advskew 100 groups: carp status: master inet 172.22.54.1 netmask 0xfff8 broadcast 172.22.54.7 carp4: flags=8843 mtu 1500 lladdr 00:00:5e:00:01:12 description: VPN Network index 16 priority 15 llprio 3 carp: carpdev vio4 advbase 1 balancing ip-stealth state MASTER vhid 18 advskew 0 state BACKUP vhid 19 advskew 100 groups: carp status: master inet 172.22.56.1 netmask 0xfff8 broadcast 172.22.56.7 carp5: flags=8843 mtu 1500 lladdr 00:00:5e:00:01:14 description: Encryption Network index 17 priority 15 llprio 3 carp: carpdev vio5 advbase 1 balancing ip-stealth state MASTER vhid 20 advskew 0 state BACKUP vhid 21 advskew 100 groups: carp status: master inet 172.22.57.1 netmask 0xfff8 broadcast 172.22.57.7 carp6: flags=8843 mtu 1500 lladdr 00:00:5e:00:01:16 description: IDPS Network index 18 priority 15 llprio 3 carp: carpdev vio6 advbase 1 balancing ip-stealth state MASTER vhid 22 advskew 0 state BACKUP vhid 23 advskew 100 groups: carp status: master inet 172.22.60.1 netmask 0xfff0 broadcast 172.22.60.15 carp7: flags=8843 mtu 1500 lladdr 00:00:5e:00:01:18 description: Windows Network index 19 priority 15 llprio 3 carp: carpdev vio8 advbase 1 balancing ip-stealth state MASTER vhid 24 advskew 0 state BACKUP vhid 25 advskew 100 groups: carp status: master inet 172.22.61.1 netmask 0xfff8 broadcast 172.22.61.7 ... but no traffic flows also. With one exception: using ip-unicast, UDP packets flows and I can resolve DNS names, sync time with NTP, etc. But only with ip-unicast, with ip-stealth no traffic appears. Also, using ip-unicast or ip-stealth, arp tables in guests behind these pair of firewalls seems to be ok: root@stonehenge:~# ip neigh 172.22.55.14 dev eth0 lladdr ac:1f:6b:14:6a:f6 STALE 172.22.55.29 dev eth0 lladdr 00:50:56:a1:4d:c3 STALE 172.22.55.5 dev eth0 lladdr ac:1f:6b:14:6c:b0 STALE 172.22.55.30 dev eth0 lladdr 00:00:5e:00:01:0a REACHABLE 172.22.55.28 dev eth0 lladdr 00:50:56:6f:64:aa STALE 172.22.55.4 dev eth0 lladdr a0:ce:c8:0a:7e:f4 DELAY All my kvm bridges are configured with the following options: bridge.mac-address: -- bridge.stp: no bridge.priority:32768 bridge.forward-delay: 15 bridge.hello-time: 2 bridge.max-age: 20 bridge.ageing-time: 300 bridge.group-forward-mask: 0 bridge.multicast-snooping: yes bridge.vlan-filtering: no bridge.vlan-default-pvid: 1 bridge.vlans: -- Same scenario, with same config under OpenBSD 6.7 (pf rules and carp config), works like a charm. Arrived to this point I am confused. Any idea? Do you use some specific config for the kvm bridges? Mybe is a problem with multicast? Many thanks for your help in advance. On 11/1/21, 17:01, "owner-b...@openbsd.org on behalf of Carlos Lopez" wrote: Many thanks David for your help. I am using virtual switches on all OpenBSD's guest interfaces, except for one which it is the "public" interface connected to my ISP's router. I will try to reconfigure two scenarios: one with OpenBSD 6.7 guests and another with OpenBSD 6.8 guests and I will keep you update. Many thanks. On 9/1/
Connecting to a Fortinet VPN SSL gateway with OpenBSD 6.8 as a client
Hi all, Does anyone know of a valid option to connect an OpenBSD host as a roadwarrior to a Fortinet SSL-VPN gateway? Using VPN-SSL ... Regards, C. L. Martinez
Re: CARP load balancing problems under KVM
Ok, done. I have already sent the bug report. On 21/10/2020, 11:11, "Uwe Werler" wrote: On 21 Oct 07:12, Carlos Lopez wrote: > Hi all, > > Before upgrade from OpenBSD 6.7 to OpenBSD 6.8, my pair firewalls was using carp in IP balance mode without problems from several months. These firewalls are installed in a RHEL 8.2 (fully patched) KVM host. > > After upgrading to OpenBSD 6.8, carp ip balance mode doesn’t works. I have tested reconfiguring balance mode for ip-stealth and ip-unicast also and the result is always the same: network packets are not processed by firewalls. But if I configure CARP using “the simple configuration” and one node is master and the other is backup all it is working without problems. > > Since the configuration is exactly the same for version 6.8 as it was for version 6.7, could there be some kind of problem with the virtio driver on the network interfaces in version 6.8? > > Regards, > C. L. Martinez Hi folks, I run into exactly the same issue with my ldap proxy. When one node is master for both carp nodes it responds to packets addressed to the carp ip. In load balancing mode it sometimes responds depending on the source ip. Please open a bug report. -- wq: ~uw
CARP load balancing problems under KVM
Hi all, Before upgrade from OpenBSD 6.7 to OpenBSD 6.8, my pair firewalls was using carp in IP balance mode without problems from several months. These firewalls are installed in a RHEL 8.2 (fully patched) KVM host. After upgrading to OpenBSD 6.8, carp ip balance mode doesn’t works. I have tested reconfiguring balance mode for ip-stealth and ip-unicast also and the result is always the same: network packets are not processed by firewalls. But if I configure CARP using “the simple configuration” and one node is master and the other is backup all it is working without problems. Since the configuration is exactly the same for version 6.8 as it was for version 6.7, could there be some kind of problem with the virtio driver on the network interfaces in version 6.8? Regards, C. L. Martinez
Re: Managing PF logs
Yep ... Pretty interesting Pierre ... but maybe is not a good idea to install
JDK in a fw gateway ... In any case, good catch.
But maybe the best option is to do it using syslog ... I will think about it
this weekend ... Many thanks to all for your help.
On 07/08/2020, 16:35, "owner-m...@openbsd.org on behalf of
pierre1.bar...@orange.com" wrote:
Hello,
I use logstash with an input like this :
input {
pipe {
type => "pflog"
command => "doas /usr/sbin/tcpdump -l -v -n -n -e -s 160 -tt -i pflog0"
}
}
--
Cordialement,
Pierre BARDOU
-Message d'origine-
De : owner-m...@openbsd.org De la part de Peter N.
M. Hansteen
Envoyé : vendredi 7 août 2020 13:10
À : misc@openbsd.org
Objet : Re: Managing PF logs
On Fri, Aug 07, 2020 at 10:29:32AM +, Carlos Lopez wrote:
> Hi all,
>
> I am thinking about how could be the best option to inject PF logs in
Elasticsearch (or any similar platform). If I am not wrong, some years ago
there is an option using a shell wrapper to store all pf logs in ASCII format
and redirect all of them to a central syslog server (published in PF FAQ). More
or less it is what I am looking for.
>
> But maybe exists another best option in nowadays. Any ideas? Tips?
As Tom said, it is possible to use tcpdump to convert to text, then forward
to syslog.
The example from the old PF tutorial
https://home.nuug.no/~peter/pf/newest/log2syslog.html
should still work.
All the best,
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember
to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
_
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
Managing PF logs
Hi all, I am thinking about how could be the best option to inject PF logs in Elasticsearch (or any similar platform). If I am not wrong, some years ago there is an option using a shell wrapper to store all pf logs in ASCII format and redirect all of them to a central syslog server (published in PF FAQ). More or less it is what I am looking for. But maybe exists another best option in nowadays. Any ideas? Tips? Regards, C. L. Martinez
Re: Message WARNING: CHECK AND RESET THE DATE! in kvm guests
Hi Otto, After some days without problems, it has happened again: root on sd0a (912329c5d9d2b184.a) swap on sd0b dump on sd0b WARNING: clock gained 3 days WARNING: CHECK AND RESET THE DATE! With version 6.6 I never had these problems. I am using default conf for ntpd, but some errors appears: Jun 2 06:32:01 obsdfw ntpd[91858]: ntp engine ready Jun 2 06:32:01 obsdfw ntpd[91858]: constraint reply from 9.9.9.9: offset 1.298291 Jun 2 06:32:03 obsdfw ntpd[91858]: cancel settime because dns probe failed Jun 2 06:32:03 obsdfw savecore: no core dump Jun 2 06:32:04 obsdfw ftp-proxy[73808]: listening on 127.0.0.1 port 8021 Jun 2 06:32:08 obsdfw ntpd[91858]: constraint reply from 216.58.211.36: offset 1.270038 Jun 2 06:32:29 obsdfw ntpd[91858]: peer 162.159.200.123 now valid Jun 2 06:32:30 obsdfw ntpd[91858]: peer 162.159.200.1 now valid Jun 2 06:32:30 obsdfw ntpd[91858]: peer 147.156.7.18 now valid Jun 2 06:32:32 obsdfw ntpd[91858]: peer 162.159.200.123 now valid Jun 2 06:32:33 obsdfw ntpd[91858]: reply from 147.156.7.26: not synced (alarm), next query 3184s Jun 2 06:33:04 obsdfw ntpd[91858]: peer 147.156.7.18 now invalid Jun 2 06:33:27 obsdfw ntpd[61176]: adjusting local clock by 1.707163s Jun 2 06:33:50 obsdfw ntpd[91858]: peer 147.156.7.18 now valid Jun 2 06:35:06 obsdfw ntpd[61176]: adjusting local clock by 1.212163s Jun 2 06:37:18 obsdfw ntpd[61176]: adjusting local clock by 0.559285s Jun 2 06:39:28 obsdfw ntpd[91858]: clock is now synced Jun 2 06:39:28 obsdfw ntpd[91858]: constraint reply from 9.9.9.9: offset -0.872650 Jun 2 06:39:28 obsdfw ntpd[91858]: constraint reply from 216.58.211.36: offset -0.880034 Jun 2 07:02:16 obsdfw ntpd[61176]: adjusting clock frequency by -0.447350 to 4.954650ppm Jun 2 07:25:37 obsdfw ntpd[91858]: peer 147.156.7.26 now valid Jun 2 07:28:08 obsdfw ntpd[61176]: adjusting clock frequency by -0.050205 to 4.904445ppm Jun 2 07:34:08 obsdfw ntpd[91858]: reply from 147.156.7.26: not synced (alarm), next query 3170s Jun 2 08:25:24 obsdfw ntpd[91858]: reply from 147.156.7.18: not synced (alarm), next query 3154s Ntpctl -s all output: 5/5 peers valid, constraint offset -1s, clock synced, stratum 4 peer wt tl st next poll offset delay jitter 162.159.200.123 time.cloudflare.com * 1 10 3 28s 33s 1.520ms 2.347ms 0.712ms 162.159.200.123 from pool pool.ntp.org * 1 10 3 29s 32s 1.530ms 2.394ms 0.406ms 147.156.7.26 from pool pool.ntp.org 1 10 2 10s 34s 0.081ms20.071ms 0.387ms 162.159.200.1 from pool pool.ntp.org 1 10 3 11s 30s 1.502ms 2.442ms 0.134ms 147.156.7.18 from pool pool.ntp.org 1 10 2 3005s 3154s 1.199ms19.994ms 0.321ms On 25/05/2020, 10:20, "Otto Moerbeek" wrote: On Mon, May 25, 2020 at 07:53:47AM +0000, Carlos Lopez wrote: > Hi all, > > After upgrading four kvm guests to OpenBSD 6.7, I see the following messages when these guests starts: > > WARNING: clock gained 2 days > WARNING: CHECK AND RESET THE DATE! This means the clock compared to the last mounted filesystem time differ. Show what ntpd is doing after boot (see /var/log/daemon). If ntpd sets the time ok, there is nothing further to be done. It's just a warning that the kernel initially isn't sure about the time. -Otto > > All four guests are fully patched. Dmesg output: > > OpenBSD 6.7 (GENERIC) #1: Sat May 16 16:07:20 MDT 2020 > r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC > real mem = 788389888 (751MB) > avail mem = 752021504 (717MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5af0 (9 entries) > bios0: vendor SeaBIOS version "1.11.1-4.module+el8.1.0+4066+0f1aadab" date 04/01/2014 > bios0: Red Hat KVM > acpi0 at bios0: ACPI 3.0 > acpi0: sleep states S5 > acpi0: tables DSDT FACP APIC MCFG > acpi0: wakeup devices > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel Core Processor (Broadwell), 1900.30 MHz, 06-3d-02 > cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,RDTSCP,LONG,LAHF,ABM,3DNOWP,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,ARAT,XSAVEOPT,MELTDOWN > cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache > cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped > cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB ent
Message WARNING: CHECK AND RESET THE DATE! in kvm guests
Hi all, After upgrading four kvm guests to OpenBSD 6.7, I see the following messages when these guests starts: WARNING: clock gained 2 days WARNING: CHECK AND RESET THE DATE! All four guests are fully patched. Dmesg output: OpenBSD 6.7 (GENERIC) #1: Sat May 16 16:07:20 MDT 2020 r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC real mem = 788389888 (751MB) avail mem = 752021504 (717MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5af0 (9 entries) bios0: vendor SeaBIOS version "1.11.1-4.module+el8.1.0+4066+0f1aadab" date 04/01/2014 bios0: Red Hat KVM acpi0 at bios0: ACPI 3.0 acpi0: sleep states S5 acpi0: tables DSDT FACP APIC MCFG acpi0: wakeup devices acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel Core Processor (Broadwell), 1900.30 MHz, 06-3d-02 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,RDTSCP,LONG,LAHF,ABM,3DNOWP,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,ARAT,XSAVEOPT,MELTDOWN cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 1000MHz ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xb000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0: C1(@1 halt!) "ACPI0006" at acpi0 not configured acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 "PNP0A06" at acpi0 not configured "PNP0A06" at acpi0 not configured "QEMU0002" at acpi0 not configured "ACPI0010" at acpi0 not configured cpu0: using Broadwell MDS workaround pvbus0 at mainbus0: KVM pvclock0 at pvbus0 pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82G33 Host" rev 0x00 vga1 at pci0 dev 1 function 0 "Red Hat QXL Video" rev 0x04 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) ppb0 at pci0 dev 2 function 0 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci1 at ppb0 bus 1 virtio0 at pci1 dev 0 function 0 "Qumranet Virtio 1.x Network" rev 0x01 vio0 at virtio0: address 00:50:56:f3:d8:1f virtio0: msix shared ppb1 at pci0 dev 2 function 1 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci2 at ppb1 bus 2 virtio1 at pci2 dev 0 function 0 "Qumranet Virtio 1.x Network" rev 0x01 vio1 at virtio1: address 00:50:56:b8:2b:4a virtio1: msix shared ppb2 at pci0 dev 2 function 2 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci3 at ppb2 bus 3 virtio2 at pci3 dev 0 function 0 "Qumranet Virtio 1.x Console" rev 0x01 virtio2: no matching child driver; not configured ppb3 at pci0 dev 2 function 3 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci4 at ppb3 bus 4 virtio3 at pci4 dev 0 function 0 "Qumranet Virtio 1.x Storage" rev 0x01 vioblk0 at virtio3 scsibus1 at vioblk0: 2 targets sd0 at scsibus1 targ 0 lun 0: sd0: 16384MB, 512 bytes/sector, 33554432 sectors virtio3: msix shared ppb4 at pci0 dev 2 function 4 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci5 at ppb4 bus 5 virtio4 at pci5 dev 0 function 0 vendor "Qumranet", unknown product 0x1045 rev 0x01 viomb0 at virtio4 virtio4: apic 0 int 22 ppb5 at pci0 dev 2 function 5 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci6 at ppb5 bus 6 virtio5 at pci6 dev 0 function 0 "Qumranet Virtio 1.x RNG" rev 0x01 viornd0 at virtio5 virtio5: apic 0 int 22 ppb6 at pci0 dev 2 function 6 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci7 at ppb6 bus 7 pcib0 at pci0 dev 31 function 0 "Intel 82801IB LPC" rev 0x02 ahci0 at pci0 dev 31 function 2 "Intel 82801I AHCI" rev 0x02: msi, AHCI 1.0 scsibus2 at ahci0: 32 targets ichiic0 at pci0 dev 31 function 3 "Intel 82801I SMBus" rev 0x02: apic 0 int 16 iic0 at ichiic0 isa0 at pcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pckbd0 at pckbc0 (kbd slot) wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) wsmouse0 at pms0 mux 0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 vscsi0 at root scsibus3 at vscsi0: 256 targets softraid0 at root scsibus4 at softraid0: 256 targets root on sd0a (91a26d47938d3239.a) swap on sd0b dump on sd0b WARNING: clock gained 2 days WARNING: CHECK AND RESET THE DATE! Do I need to reconfigure something in OpenBSD? Regards, C. L. Martinez
Strange numbers for pfsync
Hi all, After upgrade my two OpenBSD carp’ed fws to 6.7, I am seeing a lot of “failed state lookup/inserts” statistics. On firewall A: pfsync: 5487 packets received (IPv4) 0 packets received (IPv6) 0 packets discarded for bad interface 0 packets discarded for bad ttl 0 packets shorter than header 0 packets discarded for bad version 0 packets discarded for bad HMAC 0 packets discarded for bad action 0 packets discarded for short packet 0 states discarded for bad values 2 stale states 2879 failed state lookup/inserts 9539 packets sent (IPv4) 0 packets sent (IPv6) 0 send failed due to mbuf memory error 4 send error On firewall B: pfsync: 9466 packets received (IPv4) 0 packets received (IPv6) 0 packets discarded for bad interface 0 packets discarded for bad ttl 0 packets shorter than header 0 packets discarded for bad version 0 packets discarded for bad HMAC 0 packets discarded for bad action 0 packets discarded for short packet 0 states discarded for bad values 0 stale states 2879 failed state lookup/inserts 5485 packets sent (IPv4) 0 packets sent (IPv6) 0 send failed due to mbuf memory error 2 send error How can I debug this? In principle, the firewalls are working well and I haven't noticed any problems with packet loss or any related problem. Regards, C. L. Martinez
Re: OPenBSD 6.7 as a Q35 KVM guest (SOLVED)
Hi all another time, Problem is solved ... I had made a mistake: I had disabled the nic offloading options for this guest. By enabling them again, everything works. Many thanks. On 20/05/2020, 09:34, "Carlos Lopez" wrote: Hi all, I just set up an OpenBSD 6.7 kvm guest on an RHEL8.2 server and selected q35 instead of pc as a machine type. Everything seems to be working fine, except for the network interfaces (virtio interfaces). They don't work. On the other hand, if I modify q35 by pc, everything works correctly. Do I have to change any parameter or option in OpenBSD to use q35 as a machine type, or is it simply not supported? Regards, C. L. Martinez
OPenBSD 6.7 as a Q35 KVM guest
Hi all, I just set up an OpenBSD 6.7 kvm guest on an RHEL8.2 server and selected q35 instead of pc as a machine type. Everything seems to be working fine, except for the network interfaces (virtio interfaces). They don't work. On the other hand, if I modify q35 by pc, everything works correctly. Do I have to change any parameter or option in OpenBSD to use q35 as a machine type, or is it simply not supported? Regards, C. L. Martinez
Re: What is the difference between these anchor rules
Thanks Edgar … Nop, it is not a typo 😊
--
Regards,
C. L. Martinez
From: "ed...@pettijohn-web.com"
Date: Monday, 16 March 2020 at 17:16
To: Carlos Lopez
Cc: "misc@openbsd.org"
Subject: Re: What is the difference between these anchor rules
On Mar 16, 2020 11:07 AM, Carlos Lopez wrote:
Hi all,
I am trying to accomplish several different tests using anchors rules under an
OpenBSD 6.6 host. But I am seeing a strange behavior depending how I configure
them. For example:
This rule works:
anchor inet from $laptop_admin label "Allow access from $srcaddr via SSH" {
anchor proto tcp to port ssh {
pass in to (self)
pass in to { $dmz_network $vpn_network } tag intlans-to-intlans
}
}
But this one never matches:
anchor inet from $laptop_admin label "Allow access from $srcaddr via http/https
services" {
anchor proto tcp to port { http https } {
pass in $hots2 tag intlans-to-intlans
}
}
Is hots2 a typo in the mail or the conf also? Or maybe it's not a typo.
Edgar
I have tried inserting “quick” keyword in second rule, but nothing … Maybe am I
doing some mistake? Rules that works goes before than the other that fails …
Changing order, it doesn’t matter …
Any tip?
--
Regards,
C. L. Martinez
What is the difference between these anchor rules
Hi all,
I am trying to accomplish several different tests using anchors rules under an
OpenBSD 6.6 host. But I am seeing a strange behavior depending how I configure
them. For example:
This rule works:
anchor inet from $laptop_admin label "Allow access from $srcaddr via SSH" {
anchor proto tcp to port ssh {
pass in to (self)
pass in to { $dmz_network $vpn_network } tag intlans-to-intlans
}
}
But this one never matches:
anchor inet from $laptop_admin label "Allow access from $srcaddr via http/https
services" {
anchor proto tcp to port { http https } {
pass in $hots2 tag intlans-to-intlans
}
}
I have tried inserting “quick” keyword in second rule, but nothing … Maybe am I
doing some mistake? Rules that works goes before than the other that fails …
Changing order, it doesn’t matter …
Any tip?
--
Regards,
C. L. Martinez
Re: Lot of errors as a "bad ip cksum" using Tor
Thanks Stuart. This is a KVM virtual machine with all offloads settings disabled for the guest ... I will try to enable and see how it goes ... -- Regards, C. L. Martinez On 15/03/2020, 17:41, "owner-m...@openbsd.org on behalf of Stuart Henderson" wrote: On 2020-03-15, Carlos Lopez wrote: > Good morning, > > I've been seeing a lot of "bad ip cksum" error messages in my OpenBSD’s Tor gateway, like these: from the tcpdump manual: IP and Protocol Checksum Offload Some network cards support IP and/or protocol checksum offload. Packet headers for such interfaces erroneously indicate a bad checksum, since the checksum is not calculated until after tcpdump sees the packet.
Re: Lot of errors as a "bad ip cksum" using Tor
Sorry, my mistake. I have only one match rule configured as: match in all scrub (no-df max-mss 1440 random-id) -- Regards, C. L. Martinez On 15/03/2020, 13:33, "Carlos Lopez" wrote: Good morning, I've been seeing a lot of "bad ip cksum" error messages in my OpenBSD’s Tor gateway, like these: Mar 15 12:27:03.113986 rule 2._5.1/(match) [uid 0, pid 71416] pass in on vio0: [orig src 172.22.55.4:49964, dst 172.217.19.142:443] 172.22.55.4.49964 > 127.0.0.1.9040: SWE 3285379865:3285379865(0) win 65535 (ttl 63, id 46325, len 64, bad ip cksum 2341! -> 64a7) Mar 15 12:27:07.847299 rule 2._5.1/(match) [uid 0, pid 71416] pass in on vio0: [orig src 172.22.55.4:49965, dst 85.17.191.244:443] 172.22.55.4.49965 > 127.0.0.1.9040: SWE 755785425:755785425(0) win 65535 (ttl 63, id 9318, len 64, bad ip cksum 5f32! -> f536) Mar 15 12:27:08.355880 rule 1._5.1/(match) [uid 0, pid 71416] pass in on vio0: [orig src 172.22.55.4:49966, dst 88.221.213.34:80] 172.22.55.4.49966 > 127.0.0.1.9040: SWE 2618743678:2618743678(0) win 65535 (ttl 63, id 53617, len 64, bad ip cksum 992c! -> 482b) Mar 15 12:27:09.337650 rule 2._5.1/(match) [uid 0, pid 71416] pass in on vio0: [orig src 172.22.55.4:49967, dst 85.17.191.242:443] 172.22.55.4.49967 > 127.0.0.1.9040: SWE 2709850134:2709850134(0) win 65535 (ttl 63, id 31872, len 64, bad ip cksum 71a! -> 9d1c) Mar 15 12:27:09.364017 rule 2._5.1/(match) [uid 0, pid 71416] pass in on vio0: [orig src 172.22.55.4:49968, dst 85.17.191.242:443] 172.22.55.4.49968 > 127.0.0.1.9040: SWE 855567415:855567415(0) win 65535 (ttl 63, id 58857, len 64, bad ip cksum 9db0! -> 33b3) As you can see all packets are allowed and I have configured my match rules as: match in all scrub (no-df max-mss 1440) match out on egress all scrub (no-df random-id reassemble tcp max-mss 1440) Any idea this error is always on? -- Regards, C. L. Martinez
Lot of errors as a "bad ip cksum" using Tor
Good morning, I've been seeing a lot of "bad ip cksum" error messages in my OpenBSD’s Tor gateway, like these: Mar 15 12:27:03.113986 rule 2._5.1/(match) [uid 0, pid 71416] pass in on vio0: [orig src 172.22.55.4:49964, dst 172.217.19.142:443] 172.22.55.4.49964 > 127.0.0.1.9040: SWE 3285379865:3285379865(0) win 65535 (ttl 63, id 46325, len 64, bad ip cksum 2341! -> 64a7) Mar 15 12:27:07.847299 rule 2._5.1/(match) [uid 0, pid 71416] pass in on vio0: [orig src 172.22.55.4:49965, dst 85.17.191.244:443] 172.22.55.4.49965 > 127.0.0.1.9040: SWE 755785425:755785425(0) win 65535 (ttl 63, id 9318, len 64, bad ip cksum 5f32! -> f536) Mar 15 12:27:08.355880 rule 1._5.1/(match) [uid 0, pid 71416] pass in on vio0: [orig src 172.22.55.4:49966, dst 88.221.213.34:80] 172.22.55.4.49966 > 127.0.0.1.9040: SWE 2618743678:2618743678(0) win 65535 (ttl 63, id 53617, len 64, bad ip cksum 992c! -> 482b) Mar 15 12:27:09.337650 rule 2._5.1/(match) [uid 0, pid 71416] pass in on vio0: [orig src 172.22.55.4:49967, dst 85.17.191.242:443] 172.22.55.4.49967 > 127.0.0.1.9040: SWE 2709850134:2709850134(0) win 65535 (ttl 63, id 31872, len 64, bad ip cksum 71a! -> 9d1c) Mar 15 12:27:09.364017 rule 2._5.1/(match) [uid 0, pid 71416] pass in on vio0: [orig src 172.22.55.4:49968, dst 85.17.191.242:443] 172.22.55.4.49968 > 127.0.0.1.9040: SWE 855567415:855567415(0) win 65535 (ttl 63, id 58857, len 64, bad ip cksum 9db0! -> 33b3) As you can see all packets are allowed and I have configured my match rules as: match in all scrub (no-df max-mss 1440) match out on egress all scrub (no-df random-id reassemble tcp max-mss 1440) Any idea this error is always on? -- Regards, C. L. Martinez
Re: Compiling Zeek 3.0.2 returns an error at final stage (partially solved)
Ok, all works well when I configure Zeek as a standalone node: packets are captured, there are several logs regarding conn, dns ... Problem appears when Zeek is configured as a cluster using one host as a manager and another host as a worker ... Strange, because PF is disabled in both hosts, one host can connect to the other (ping, ssh and so on). Maybe it is a bug with Zeek ... -- Regards, C. L. Martinez On 08/03/2020, 10:42, "owner-m...@openbsd.org on behalf of Carlos Lopez" wrote: Hi Monah, Yes, zeekctl deploy works without problem. If I launch several requests using curl or doing several dns requests, I can see all of them with tcpdump but not in zeek … Of course, sniffing the same interface … -- Regards, C. L. Martinez From: Monah Baki Date: Sunday, 8 March 2020 at 00:25 To: Carlos Lopez Cc: "misc@openbsd.org" Subject: Re: Compiling Zeek 3.0.2 returns an error at final stage From the server if you curl a website, in zeek log current folder do you see a http.log file, and after changing the interface did you zeekctl deploy. Thanks Monah On Sat, Mar 7, 2020 at 5:42 PM Carlos Lopez mailto:clo...@outlook.com>> wrote: Thanks Monah … But this is not the problem … interface configuration is correct … -- Regards, C. L. Martinez From: Monah Baki mailto:monahb...@gmail.com>> Date: Saturday, 7 March 2020 at 23:30 To: Carlos Lopez mailto:clo...@outlook.com>> Cc: "misc@openbsd.org<mailto:misc@openbsd.org>" mailto:misc@openbsd.org>> Subject: Re: Compiling Zeek 3.0.2 returns an error at final stage Hi Carlos, Check your node.cfg, the interface section [zeek] type=standalone host=localhost interface=eth0 <<<<<< might want to change it On Sat, Mar 7, 2020 at 5:01 PM Carlos Lopez mailto:clo...@outlook.com>> wrote: Many thanks for your answer Stuart ... Finally, I have compiled Zeek 3.0.3-dev.3 an all goes ok during compilation ... But zeek doesn't capture any packet ... and tcpdump works without problems and I can see all traffic ... -- Regards, C. L. Martinez On 07/03/2020, 22:08, "owner-m...@openbsd.org<mailto:owner-m...@openbsd.org> on behalf of Stuart Henderson" mailto:owner-m...@openbsd.org> on behalf of s...@spacehopper.org<mailto:s...@spacehopper.org>> wrote: On 2020-03-07, Carlos Lopez mailto:clo...@outlook.com>> wrote: > Hi all, > > I am trying to install Zeek 3.0.2 under OpenBSD 6.6 amd64 fully patched but compilation returns me the following error: > > [ 97%] Building C object src/CMakeFiles/zeek.dir/nb_dns.c.o > [ 97%] Linking CXX executable zeek > ld: error: unable to find library -llibbinpac.so.VERSION > c++: error: linker command failed with exit code 1 (use -v to see invocation) > *** Error 1 in build (src/CMakeFiles/zeek.dir/build.make:1826 'src/zeek') > *** Error 1 in build (CMakeFiles/Makefile2:1661 'src/CMakeFiles/zeek.dir/all') > *** Error 1 in build (Makefile:152 'all') > *** Error 1 in /root/builds/src/zeek-3.0.2 (Makefile:15 'all') > > But libbinpac.so exists compiled under the source dirs.: > > root@obsd66:~/builds/src/zeek-3.0.2# find . -name "*binpac.so" > ./build/aux/binpac/lib/libbinpac.so > root@obsd66:~/builds/src/zeek-3.0.2 > > Any tip to solve this issue? > You're probably better off using the port. There is a fair chance that if you update *just* the net/bro directory (the port dir wasn't renamed but the package was) to -current that it will build, and if not, you'll be closer to getting it working. Or the easy option, update to -current, pkg_add zeek.
Re: Compiling Zeek 3.0.2 returns an error at final stage
Hi Monah, Yes, zeekctl deploy works without problem. If I launch several requests using curl or doing several dns requests, I can see all of them with tcpdump but not in zeek … Of course, sniffing the same interface … -- Regards, C. L. Martinez From: Monah Baki Date: Sunday, 8 March 2020 at 00:25 To: Carlos Lopez Cc: "misc@openbsd.org" Subject: Re: Compiling Zeek 3.0.2 returns an error at final stage >From the server if you curl a website, in zeek log current folder do you see a >http.log file, and after changing the interface did you zeekctl deploy. Thanks Monah On Sat, Mar 7, 2020 at 5:42 PM Carlos Lopez mailto:clo...@outlook.com>> wrote: Thanks Monah … But this is not the problem … interface configuration is correct … -- Regards, C. L. Martinez From: Monah Baki mailto:monahb...@gmail.com>> Date: Saturday, 7 March 2020 at 23:30 To: Carlos Lopez mailto:clo...@outlook.com>> Cc: "misc@openbsd.org<mailto:misc@openbsd.org>" mailto:misc@openbsd.org>> Subject: Re: Compiling Zeek 3.0.2 returns an error at final stage Hi Carlos, Check your node.cfg, the interface section [zeek] type=standalone host=localhost interface=eth0 <<<<<< might want to change it On Sat, Mar 7, 2020 at 5:01 PM Carlos Lopez mailto:clo...@outlook.com>> wrote: Many thanks for your answer Stuart ... Finally, I have compiled Zeek 3.0.3-dev.3 an all goes ok during compilation ... But zeek doesn't capture any packet ... and tcpdump works without problems and I can see all traffic ... -- Regards, C. L. Martinez On 07/03/2020, 22:08, "owner-m...@openbsd.org<mailto:owner-m...@openbsd.org> on behalf of Stuart Henderson" mailto:owner-m...@openbsd.org> on behalf of s...@spacehopper.org<mailto:s...@spacehopper.org>> wrote: On 2020-03-07, Carlos Lopez mailto:clo...@outlook.com>> wrote: > Hi all, > > I am trying to install Zeek 3.0.2 under OpenBSD 6.6 amd64 fully patched but compilation returns me the following error: > > [ 97%] Building C object src/CMakeFiles/zeek.dir/nb_dns.c.o > [ 97%] Linking CXX executable zeek > ld: error: unable to find library -llibbinpac.so.VERSION > c++: error: linker command failed with exit code 1 (use -v to see invocation) > *** Error 1 in build (src/CMakeFiles/zeek.dir/build.make:1826 'src/zeek') > *** Error 1 in build (CMakeFiles/Makefile2:1661 'src/CMakeFiles/zeek.dir/all') > *** Error 1 in build (Makefile:152 'all') > *** Error 1 in /root/builds/src/zeek-3.0.2 (Makefile:15 'all') > > But libbinpac.so exists compiled under the source dirs.: > > root@obsd66:~/builds/src/zeek-3.0.2# find . -name "*binpac.so" > ./build/aux/binpac/lib/libbinpac.so > root@obsd66:~/builds/src/zeek-3.0.2 > > Any tip to solve this issue? > You're probably better off using the port. There is a fair chance that if you update *just* the net/bro directory (the port dir wasn't renamed but the package was) to -current that it will build, and if not, you'll be closer to getting it working. Or the easy option, update to -current, pkg_add zeek.
Re: Compiling Zeek 3.0.2 returns an error at final stage
Thanks Monah … But this is not the problem … interface configuration is correct … -- Regards, C. L. Martinez From: Monah Baki Date: Saturday, 7 March 2020 at 23:30 To: Carlos Lopez Cc: "misc@openbsd.org" Subject: Re: Compiling Zeek 3.0.2 returns an error at final stage Hi Carlos, Check your node.cfg, the interface section [zeek] type=standalone host=localhost interface=eth0 <<<<<< might want to change it On Sat, Mar 7, 2020 at 5:01 PM Carlos Lopez mailto:clo...@outlook.com>> wrote: Many thanks for your answer Stuart ... Finally, I have compiled Zeek 3.0.3-dev.3 an all goes ok during compilation ... But zeek doesn't capture any packet ... and tcpdump works without problems and I can see all traffic ... -- Regards, C. L. Martinez On 07/03/2020, 22:08, "owner-m...@openbsd.org<mailto:owner-m...@openbsd.org> on behalf of Stuart Henderson" mailto:owner-m...@openbsd.org> on behalf of s...@spacehopper.org<mailto:s...@spacehopper.org>> wrote: On 2020-03-07, Carlos Lopez mailto:clo...@outlook.com>> wrote: > Hi all, > > I am trying to install Zeek 3.0.2 under OpenBSD 6.6 amd64 fully patched but compilation returns me the following error: > > [ 97%] Building C object src/CMakeFiles/zeek.dir/nb_dns.c.o > [ 97%] Linking CXX executable zeek > ld: error: unable to find library -llibbinpac.so.VERSION > c++: error: linker command failed with exit code 1 (use -v to see invocation) > *** Error 1 in build (src/CMakeFiles/zeek.dir/build.make:1826 'src/zeek') > *** Error 1 in build (CMakeFiles/Makefile2:1661 'src/CMakeFiles/zeek.dir/all') > *** Error 1 in build (Makefile:152 'all') > *** Error 1 in /root/builds/src/zeek-3.0.2 (Makefile:15 'all') > > But libbinpac.so exists compiled under the source dirs.: > > root@obsd66:~/builds/src/zeek-3.0.2# find . -name "*binpac.so" > ./build/aux/binpac/lib/libbinpac.so > root@obsd66:~/builds/src/zeek-3.0.2 > > Any tip to solve this issue? > You're probably better off using the port. There is a fair chance that if you update *just* the net/bro directory (the port dir wasn't renamed but the package was) to -current that it will build, and if not, you'll be closer to getting it working. Or the easy option, update to -current, pkg_add zeek.
Re: Compiling Zeek 3.0.2 returns an error at final stage
Many thanks for your answer Stuart ... Finally, I have compiled Zeek 3.0.3-dev.3 an all goes ok during compilation ... But zeek doesn't capture any packet ... and tcpdump works without problems and I can see all traffic ... -- Regards, C. L. Martinez On 07/03/2020, 22:08, "owner-m...@openbsd.org on behalf of Stuart Henderson" wrote: On 2020-03-07, Carlos Lopez wrote: > Hi all, > > I am trying to install Zeek 3.0.2 under OpenBSD 6.6 amd64 fully patched but compilation returns me the following error: > > [ 97%] Building C object src/CMakeFiles/zeek.dir/nb_dns.c.o > [ 97%] Linking CXX executable zeek > ld: error: unable to find library -llibbinpac.so.VERSION > c++: error: linker command failed with exit code 1 (use -v to see invocation) > *** Error 1 in build (src/CMakeFiles/zeek.dir/build.make:1826 'src/zeek') > *** Error 1 in build (CMakeFiles/Makefile2:1661 'src/CMakeFiles/zeek.dir/all') > *** Error 1 in build (Makefile:152 'all') > *** Error 1 in /root/builds/src/zeek-3.0.2 (Makefile:15 'all') > > But libbinpac.so exists compiled under the source dirs.: > > root@obsd66:~/builds/src/zeek-3.0.2# find . -name "*binpac.so" > ./build/aux/binpac/lib/libbinpac.so > root@obsd66:~/builds/src/zeek-3.0.2 > > Any tip to solve this issue? > You're probably better off using the port. There is a fair chance that if you update *just* the net/bro directory (the port dir wasn't renamed but the package was) to -current that it will build, and if not, you'll be closer to getting it working. Or the easy option, update to -current, pkg_add zeek.
Compiling Zeek 3.0.2 returns an error at final stage
Hi all, I am trying to install Zeek 3.0.2 under OpenBSD 6.6 amd64 fully patched but compilation returns me the following error: [ 97%] Building C object src/CMakeFiles/zeek.dir/nb_dns.c.o [ 97%] Linking CXX executable zeek ld: error: unable to find library -llibbinpac.so.VERSION c++: error: linker command failed with exit code 1 (use -v to see invocation) *** Error 1 in build (src/CMakeFiles/zeek.dir/build.make:1826 'src/zeek') *** Error 1 in build (CMakeFiles/Makefile2:1661 'src/CMakeFiles/zeek.dir/all') *** Error 1 in build (Makefile:152 'all') *** Error 1 in /root/builds/src/zeek-3.0.2 (Makefile:15 'all') But libbinpac.so exists compiled under the source dirs.: root@obsd66:~/builds/src/zeek-3.0.2# find . -name "*binpac.so" ./build/aux/binpac/lib/libbinpac.so root@obsd66:~/builds/src/zeek-3.0.2 Any tip to solve this issue? -- Regards, C. L. Martinez
Re: Errors when I try to configure multiple DNS search suffixes in dhcpd.conf
On 24/09/2019 12:26, Erling Westenvik wrote: > On Tue, Sep 24, 2019 at 08:11:00AM +0000, Carlos Lopez wrote: >> When I try to configure multiple search DNS suffixes in dhcpd.conf, I >> am receiving the following error: >> >> /etc/dhcpd.conf line 21: >> option domain-search "custom.domain.org" >> ^ >> fatal in dhcpd: Configuration file errors encountered >> >> According to man page: > > To avoid ambiguity you should always state explicitly to which man page > you are referring. In this case you're not quoting dhcpd.conf(5) but > dhcp-options(5). > >> option domain-search rfc1035; | string [, string ...]; >> [...] >> Note that dhcpd(8) calls this option option-119 instead of >> domain-search and only supports the rfc1035 variant. >> [...] > > This is it! Change > > option domain-search "custom.domain.org" > > to > > option option-119 "custom.domain.org" > > and you should be good to go. > Oops ... You are right Erling. Changed to option-119 and it works. Sorry for the noise. -- Regards, C. L. Martinez
Re: Errors when I try to configure multiple DNS search suffixes in dhcpd.conf
Regards,
C. L. Martinez
On 24/09/2019 10:22, Rudolf Leitgeb wrote:
> Could this be a case of missing semicolon at the end ?
>
Thanks Rudolf, but not ... My complete config is:
subnet 172.22.55.0 netmask 255.255.255.224 {
option routers 172.22.55.30;
range 172.22.55.17 172.22.55.27;
option subnet-mask 255.255.255.224;
option broadcast-address 172.22.55.31;
option domain-search "internal.dom.org", "dmz.dom.org";
}
Errors when I try to configure multiple DNS search suffixes in dhcpd.conf
Hi all, When I try to configure multiple search DNS suffixes in dhcpd.conf, I am receiving the following error: /etc/dhcpd.conf line 21: option domain-search "custom.domain.org" ^ fatal in dhcpd: Configuration file errors encountered According to man page: option domain-search rfc1035; | string [, string ...]; The domain-search option specifies a list of the domain names that should be used during DNS name resolution. When dhclient(8) constructs resolv.conf(5) it will use this list of domains in preference to any information provided by the domain-name option. Note that dhcpd(8) calls this option option-119 instead of domain-search and only supports the rfc1035 variant. If my config is ok, maybe is this a bug? Regards -- Regards, C. L. Martinez
Re: route-to rule problem after upgrading to 6.5
On 19/05/2019 14:16, Ville Valkonen wrote:
> On Sun, 19 May 2019 at 12.14, Carlos Lopez <mailto:clo...@outlook.com>> wrote:
>
> Hi all,
>
> Yesterday, I have upgraded my home OpenBSD's fws from 6.4 to 6.5.
> All
> seems to work ok execpt with route-to rules. The following rules have
> been working smoothly in previous versions:
>
> pass in quick inet proto tcp from to
> port = 80 flags S/SA keep state (if-bound) label
> "Force access to Google sites via TOR" tag intlans-to-intlans route-to
> 172.22.56.5@vio4
> pass in quick inet proto tcp from to
> port = 443 flags S/SA keep state (if-bound) label
> "Force access to Google sites via TOR" tag intlans-to-intlans route-to
> 172.22.56.5@vio4
>
> .. but with 6.5 fails ... Any idea?
> --
> Regards,
> C. L. Martinez
>
>
> Hello Carlos,
>
> you have "port = 443", shouldn't that be in "port 443" form? Didn't
> check the pf.conf man page for the correct grammar while on mobile.
>
> Regards,
> Ville
Thanks Ville, but not. This is not the problem. I have attached pfctl's
output. Original rules is:
pass in quick inet proto tcp from to
port { http https } route-to ($vpnif $inthost) tag
intlans-to-intlans label "Force access to Google sites via TOR"
route-to rule problem after upgrading to 6.5
Hi all, Yesterday, I have upgraded my home OpenBSD's fws from 6.4 to 6.5. All seems to work ok execpt with route-to rules. The following rules have been working smoothly in previous versions: pass in quick inet proto tcp from to port = 80 flags S/SA keep state (if-bound) label "Force access to Google sites via TOR" tag intlans-to-intlans route-to 172.22.56.5@vio4 pass in quick inet proto tcp from to port = 443 flags S/SA keep state (if-bound) label "Force access to Google sites via TOR" tag intlans-to-intlans route-to 172.22.56.5@vio4 .. but with 6.5 fails ... Any idea? -- Regards, C. L. Martinez
Re: Warning applying latest syspatch
On 02/11/2018 18:18, Theo de Raadt wrote: > Carlos Lopez wrote: > >> Applying syspatch today, returns me the following warning: >> >> root@obsd-fw-per01:~# syspatch >> ln: /usr/X11R6/bin/X: No such file or directory >> >> I guess it's an expected error since I don't have X11 installed. Correct? > Yes. > > The syspatch patch to syspatch (say that three times fast) isn't quite > perfect for that case, but at least the warning it gives isn't a big deal. > You can ignore it. Wow! .. Perfect. Many thanks Theo and congratulations for this work. -- Regards, C.L. Martinez
Warning applying latest syspatch
Hi all, Applying syspatch today, returns me the following warning: root@obsd-fw-per01:~# syspatch ln: /usr/X11R6/bin/X: No such file or directory I guess it's an expected error since I don't have X11 installed. Correct? -- Regards, C.L. Martinez
Re: OT: Firmware encryption hacked?
Many thanks to all for your explanations, as always. Regards, C. L. Martinez From: owner-m...@openbsd.org on behalf of Kevin Chadwick Sent: 13 September 2018 17:39 To: misc@openbsd.org Subject: Re: OT: Firmware encryption hacked? On Thu, 13 Sep 2018 10:23:11 -0400 > > Uhmm … Reality? > > https://techcrunch.com/2018/09/12/security-flaw-in-nearly-all-modern-pcs-and-macs-leaks-encrypted-data/?guccounter=1 > > Somewhat better writup from the source: > > https://blog.f-secure.com/cold-boot-attacks/ > > The vulnerability seems to be when a computer is running or "sleeping" > not actually off or hibernating. There are then ways that an attacker > with physical access might recover encryption keys or other data from > RAM. Old news. Also, cold boot attacks go atleast several years before 2008. In fact, expensive cold boot resistant hdd were around in 2005.
OT: Firmware encryption hacked?
Uhmm … Reality? https://techcrunch.com/2018/09/12/security-flaw-in-nearly-all-modern-pcs-and-macs-leaks-encrypted-data/?guccounter=1 Can we consider a risk to encrypt at OS level also?
