Re: snmpd and route changes
Not 100% sure but there's a chance that this will work how you expect in -current. https://github.com/openbsd/src/commit/029c661593e4bba8652393dbb912eaf3b5031eec On 2024-02-23, Marko Cupać wrote: > Hi, > > my OpenBSD firewall has static default route to the Internet over > external interface, and gets routes to internal subnets by means of > OSPF with Juniper switch over internal interface. > > Host on one of internal subnets queries snmpd listening on internal > interface of OpenBSD firewall. When OSPF on OpenBSD firewall is > up, requests arrive on internal interface, replies depart on internal > interface - expected working situation. > > When OSPF on OpenBSD firewall go down (rcctl stop ospfd), requests > still arrive on internal interface (switch has static default route > over OpenBSD firewall), but as firewall has no longer route to internal > subnet from which queries originate, it correctly tries to send replies > over default route (external interface), which intentionally get > blocked by pf. > > The problem is the fact that after OSPF on OpenBSD firewall comes up > (rcctl start ospfd), snmpd continues to send replies over default > route, not over more specific route learned over OSPF. Restarting snmpd > results in picking up new route correctly. > > I am not 100% sure, but I think the same happens with pflow exports to > the same host on internal subnet. It takes destroying pflow0 interface > and netstart-ing it for picking up new route correctly. > > Anyone else encountered this? Could this be a bug? Or should I > reconfigure something? > > PS: My setup is actually a bit more complicated (CARP pair, OSPF > depends on carp interface, aggregated interfaces etc. but that should > not affect the situation where snmpd sends traffic over default route > and external interface even though routing table has more specific > route over internal interface. I will gladly provide more details if > needed. > > snmpd.conf (redacted): > > listen on udp 10.66.66.253 read snmpv3 > seclevel auth > system contact "John Doe (john@example.org" > system description "OpenBSD" > system location "Somwhere" > system name "fw2.example.org" > user "example" authkey "thisisnotakey" auth hmac-sha1 > > hostname.pflow0 (redacted): > > flowsrc 10.66.66.253 flowdst 10.66.65.169:9996 > pflowproto 10 > > route to host's subnet when OSPF is up (redacted): > > netstat -rn | grep 10.66.65.0 > > 10.66.65.0/24 10.30.66.249 UG 0 957 -32 aggr0 > > route -n get 10.66.65.0/24 > >route to: 10.66.65.0 > destination: 10.66.65.0 >mask: 255.255.255.0 > gateway: 10.66.66.249 > interface: aggr0 > if address: 10.66.66.253 >priority: 32 (ospf) > flags: > use mtuexpire > 7126 0 0 > > ospfctl sh rib | grep 10.66.65.0 > > 10.66.65.0/24 10.66.66.249 Intra-Area Network 65536 20:32:27 > > ospfctl sh fib | grep 10.66.65.0 > > *O 32 10.66.65.0/24 10.66.66.249 > > dmesg: > > OpenBSD 7.4 (GENERIC.MP) #0: Sun Oct 22 12:13:42 MDT 2023 > > r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 17027289088 (16238MB) > avail mem = 16491503616 (15727MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x788c5000 (241 entries) > bios0: vendor HP version "P89" date 11/23/2021 > bios0: HP ProLiant DL360 Gen9 > efi0 at bios0: UEFI 2.4 > efi0: HP rev 0x25c00 > acpi0 at bios0: ACPI 5.0 > acpi0: sleep states S0 S5 > acpi0: tables DSDT FACP UEFI MCEJ SSDT HEST BERT ERST EINJ BGRT HPET PMCT > WDDT APIC MCFG SLIT SRAT SPMI RASF SPCR MSCT BDAT PCCT DMAR SSDT SSDT SSDT > acpi0: wakeup devices PEX4(S4) BR05(S4) BR03(S4) BR07(S4) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpihpet0 at acpi0: 14318179 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Xeon(R) CPU E5-2623 v4 @ 2.60GHz, 2597.06 MHz, 06-4f-01, patch > 0b40 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 8-way L2 cache, 10MB 64b/line 20-way L3 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges > cpu0: apic clock running at 99MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.2, IBE > cpu1 at mainbus0: apid 2 (application processor) > cpu1: Intel(R) Xeon(R) CPU E5-2623 v4 @ 2.60GHz,
snmpd and route changes
Hi, my OpenBSD firewall has static default route to the Internet over external interface, and gets routes to internal subnets by means of OSPF with Juniper switch over internal interface. Host on one of internal subnets queries snmpd listening on internal interface of OpenBSD firewall. When OSPF on OpenBSD firewall is up, requests arrive on internal interface, replies depart on internal interface - expected working situation. When OSPF on OpenBSD firewall go down (rcctl stop ospfd), requests still arrive on internal interface (switch has static default route over OpenBSD firewall), but as firewall has no longer route to internal subnet from which queries originate, it correctly tries to send replies over default route (external interface), which intentionally get blocked by pf. The problem is the fact that after OSPF on OpenBSD firewall comes up (rcctl start ospfd), snmpd continues to send replies over default route, not over more specific route learned over OSPF. Restarting snmpd results in picking up new route correctly. I am not 100% sure, but I think the same happens with pflow exports to the same host on internal subnet. It takes destroying pflow0 interface and netstart-ing it for picking up new route correctly. Anyone else encountered this? Could this be a bug? Or should I reconfigure something? PS: My setup is actually a bit more complicated (CARP pair, OSPF depends on carp interface, aggregated interfaces etc. but that should not affect the situation where snmpd sends traffic over default route and external interface even though routing table has more specific route over internal interface. I will gladly provide more details if needed. snmpd.conf (redacted): listen on udp 10.66.66.253 read snmpv3 seclevel auth system contact "John Doe (john@example.org" system description "OpenBSD" system location "Somwhere" system name "fw2.example.org" user "example" authkey "thisisnotakey" auth hmac-sha1 hostname.pflow0 (redacted): flowsrc 10.66.66.253 flowdst 10.66.65.169:9996 pflowproto 10 route to host's subnet when OSPF is up (redacted): netstat -rn | grep 10.66.65.0 10.66.65.0/24 10.30.66.249 UG 0 957 -32 aggr0 route -n get 10.66.65.0/24 route to: 10.66.65.0 destination: 10.66.65.0 mask: 255.255.255.0 gateway: 10.66.66.249 interface: aggr0 if address: 10.66.66.253 priority: 32 (ospf) flags: use mtuexpire 7126 0 0 ospfctl sh rib | grep 10.66.65.0 10.66.65.0/24 10.66.66.249 Intra-Area Network 65536 20:32:27 ospfctl sh fib | grep 10.66.65.0 *O 32 10.66.65.0/24 10.66.66.249 dmesg: OpenBSD 7.4 (GENERIC.MP) #0: Sun Oct 22 12:13:42 MDT 2023 r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17027289088 (16238MB) avail mem = 16491503616 (15727MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x788c5000 (241 entries) bios0: vendor HP version "P89" date 11/23/2021 bios0: HP ProLiant DL360 Gen9 efi0 at bios0: UEFI 2.4 efi0: HP rev 0x25c00 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S5 acpi0: tables DSDT FACP UEFI MCEJ SSDT HEST BERT ERST EINJ BGRT HPET PMCT WDDT APIC MCFG SLIT SRAT SPMI RASF SPCR MSCT BDAT PCCT DMAR SSDT SSDT SSDT acpi0: wakeup devices PEX4(S4) BR05(S4) BR03(S4) BR07(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5-2623 v4 @ 2.60GHz, 2597.06 MHz, 06-4f-01, patch 0b40 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 8-way L2 cache, 10MB 64b/line 20-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E5-2623 v4 @ 2.60GHz, 2597.04 MHz, 06-4f-01, patch 0b40 cpu1:
