Messages

1

Virtual private networks / Zenarmor does not work when using wireguard

« on: February 20, 2024, 09:21:19 pm »

I can't figure out what the issue is here. I read on a reddit post that I needed to use os-wireguard-go instead and I tried that and it still doesn't work.  Is this a wireguard problem or a zenarmor problem?  My wireguard client is set up to use the IP on my LAN interface for DNS, which is what my computer is set up to use, and my computer is filtered with zenarmor just fine, but my phone using wireguard is not.

2

21.7 Legacy Series / Re: Interfaces randomly go down/unroutable

« on: November 30, 2021, 10:34:47 pm »

I think my thread's been jacked here, but I'm not even using suricata.  I've disabled sensei, but I still get this problem.  Sometimes LAN interfaces pingable, sometimes not.  Sometimes when they are pingable the traffic goes into the firewall and vanishes, I don't know where to look beyond that.  Here's my dmesg output, and the last up/down in the log was me swapping for a different cable.  But I strongly suspect that won't do a thing because simply rebooting the box fixes it every time.

Code: [Select]

---<<BOOT>>---
Copyright (c) 2013-2019 The HardenedBSD Project.
Copyright (c) 1992-2019 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.1-RELEASE-p21-HBSD #0  1c99b63a2ba(stable/21.7)-dirty: Wed Nov 10 11:17:14 CET 2021
    root@sensey:/usr/obj/usr/src/amd64.amd64/sys/SMP amd64
FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on LLVM 8.0.1)
VT(efifb): resolution 800x600
HardenedBSD: initialize and check features (__HardenedBSD_version 1200059 __FreeBSD_version 1201000).
CPU: Intel(R) Core(TM) i3-7100U CPU @ 2.40GHz (2400.10-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x806e9  Family=0x6  Model=0x8e  Stepping=9
  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0x7ffafbbf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
  AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
  AMD Features2=0x121<LAHF,ABM,Prefetch>
  Structured Extended Features=0x29c67af<FSGSBASE,TSCADJ,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,NFPUSG,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PROCTRACE>
  Structured Extended Features3=0xc000000<IBPB,STIBP>
  XSAVE Features=0xf<XSAVEOPT,XSAVEC,XINUSE,XSAVES>
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID
  TSC: P-state invariant, performance statistics
real memory  = 12884901888 (12288 MB)
avail memory = 12339802112 (11768 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: <ALASKA A M I >
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 hardware threads
random: unblocking device.
ioapic0 <Version 2.0> irqs 0-119 on motherboard
Launching APs: 1 2 3
Timecounter "TSC-low" frequency 1200050100 Hz quality 1000
wlan: mac acl policy registered
random: entropy device external interface
kbd1 at kbdmux0
module_register_init: MOD_LOAD (vesa, 0xffffffff812947f0, 0) error 19
random: registering fast source Intel Secure Key RNG
random: fast provider: "Intel Secure Key RNG"
000.000054 [4344] netmap_init               netmap: loaded module
[ath_hal] loaded
nexus0
efirtc0: <EFI Realtime Clock> on motherboard
efirtc0: registered as a time-of-day clock, resolution 1.000000s
cryptosoft0: <software crypto> on motherboard
acpi0: <ALASKA A M I > on motherboard
acpi0: Power Button (fixed)
cpu0: <ACPI CPU> on acpi0
hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
Timecounter "HPET" frequency 24000000 Hz quality 950
Event timer "HPET" frequency 24000000 Hz quality 550
Event timer "HPET1" frequency 24000000 Hz quality 440
Event timer "HPET2" frequency 24000000 Hz quality 440
Event timer "HPET3" frequency 24000000 Hz quality 440
Event timer "HPET4" frequency 24000000 Hz quality 440
atrtc0: <AT realtime clock> port 0x70-0x77 irq 8 on acpi0
atrtc0: Warning: Couldn't map I/O.
atrtc0: registered as a time-of-day clock, resolution 1.000000s
Event timer "RTC" frequency 32768 Hz quality 0
attimer0: <AT timer> port 0x40-0x43,0x50-0x53 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1808-0x180b on acpi0
pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
pci0: <ACPI PCI bus> on pcib0
vgapci0: <VGA-compatible display> port 0xf000-0xf03f mem 0xde000000-0xdeffffff,0xc0000000-0xcfffffff irq 16 at device 2.0 on pci0
vgapci0: Boot video device
xhci0: <Intel Sunrise Point-LP USB 3.0 controller> mem 0xdf600000-0xdf60ffff irq 16 at device 20.0 on pci0
xhci0: 32 bytes context size, 64-bit DMA
usbus0: waiting for BIOS to give up control
usbus0 on xhci0
usbus0: 5.0Gbps Super Speed USB v3.0
pci0: <simple comms> at device 22.0 (no driver attached)
ahci0: <Intel Sunrise Point-LP AHCI SATA controller> port 0xf090-0xf097,0xf080-0xf083,0xf060-0xf07f mem 0xdf614000-0xdf615fff,0xdf618000-0xdf6180ff,0xdf617000-0xdf6177ff irq 16 at device 23.0 on pci0
ahci0: AHCI v1.31 with 3 6Gbps ports, Port Multiplier not supported
ahcich0: <AHCI channel> at channel 0 on ahci0
ahcich1: <AHCI channel> at channel 1 on ahci0
ahcich2: <AHCI channel> at channel 2 on ahci0
pcib1: <ACPI PCI-PCI bridge> irq 16 at device 28.0 on pci0
pci1: <ACPI PCI bus> on pcib1
em0: <Intel(R) 82583V> port 0xe000-0xe01f mem 0xdf500000-0xdf51ffff,0xdf520000-0xdf523fff irq 16 at device 0.0 on pci1
em0: Using 1024 TX descriptors and 1024 RX descriptors
em0: Using an MSI interrupt
em0: Ethernet address: 00:e0:67:21:c0:a4
em0: netmap queues/slots: TX 1/1024, RX 1/1024
pcib2: <ACPI PCI-PCI bridge> irq 17 at device 28.1 on pci0
pci2: <ACPI PCI bus> on pcib2
em1: <Intel(R) 82583V> port 0xd000-0xd01f mem 0xdf400000-0xdf41ffff,0xdf420000-0xdf423fff irq 17 at device 0.0 on pci2
em1: Using 1024 TX descriptors and 1024 RX descriptors
em1: Using an MSI interrupt
em1: Ethernet address: 00:e0:67:21:c0:a5
em1: netmap queues/slots: TX 1/1024, RX 1/1024
pcib3: <ACPI PCI-PCI bridge> irq 18 at device 28.2 on pci0
pci3: <ACPI PCI bus> on pcib3
em2: <Intel(R) 82583V> port 0xc000-0xc01f mem 0xdf300000-0xdf31ffff,0xdf320000-0xdf323fff irq 18 at device 0.0 on pci3
em2: Using 1024 TX descriptors and 1024 RX descriptors
em2: Using an MSI interrupt
em2: Ethernet address: 00:e0:67:21:c0:a6
em2: netmap queues/slots: TX 1/1024, RX 1/1024
pcib4: <ACPI PCI-PCI bridge> irq 19 at device 28.3 on pci0
pci4: <ACPI PCI bus> on pcib4
em3: <Intel(R) 82583V> port 0xb000-0xb01f mem 0xdf200000-0xdf21ffff,0xdf220000-0xdf223fff irq 19 at device 0.0 on pci4
em3: Using 1024 TX descriptors and 1024 RX descriptors
em3: Using an MSI interrupt
em3: Ethernet address: 00:e0:67:21:c0:a7
em3: netmap queues/slots: TX 1/1024, RX 1/1024
pcib5: <ACPI PCI-PCI bridge> irq 16 at device 28.4 on pci0
pci5: <ACPI PCI bus> on pcib5
em4: <Intel(R) 82583V> port 0xa000-0xa01f mem 0xdf100000-0xdf11ffff,0xdf120000-0xdf123fff irq 16 at device 0.0 on pci5
em4: Using 1024 TX descriptors and 1024 RX descriptors
em4: Using an MSI interrupt
em4: Ethernet address: 00:e0:67:21:c0:a8
em4: netmap queues/slots: TX 1/1024, RX 1/1024
pcib6: <ACPI PCI-PCI bridge> irq 17 at device 28.5 on pci0
pci6: <ACPI PCI bus> on pcib6
em5: <Intel(R) 82583V> port 0x9000-0x901f mem 0xdf000000-0xdf01ffff,0xdf020000-0xdf023fff irq 17 at device 0.0 on pci6
em5: Using 1024 TX descriptors and 1024 RX descriptors
em5: Using an MSI interrupt
em5: Ethernet address: 00:e0:67:21:c0:a9
em5: netmap queues/slots: TX 1/1024, RX 1/1024
isab0: <PCI-ISA bridge> at device 31.0 on pci0
isa0: <ISA bus> on isab0
pci0: <memory> at device 31.2 (no driver attached)
acpi_button0: <Sleep Button> on acpi0
acpi_button1: <Power Button> on acpi0
acpi_tz0: <Thermal Zone> on acpi0
acpi_tz1: <Thermal Zone> on acpi0
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
uart0: console (115200,n,8,1)
orm0: <ISA Option ROM> at iomem 0xc0000-0xcffff pnpid ORM0000 on isa0
est0: <Enhanced SpeedStep Frequency Control> on cpu0
Timecounters tick every 1.000 msec
ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0: <Hoodisk SSD SBFMBBA3> ACS-4 ATA SATA 3.x device
ada0: Serial Number L9MLCCC11295650
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 30533MB (62533296 512 byte sectors)
ugen0.1: <0x8086 XHCI root HUB> at usbus0
Trying to mount root from ufs:/dev/gpt/rootfs [rw,noatime]...
uhub0: <0x8086 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
uhub0: 18 ports with 18 removable, self powered
em0: link state changed to UP
em1: link state changed to UP
em2: link state changed to UP
lo0: link state changed to UP
aesni0: <AES-CBC,AES-CCM,AES-GCM,AES-ICM,AES-XTS> on motherboard
coretemp0: <CPU On-Die Thermal Sensors> on cpu0
lagg0: IPv6 addresses on em4 have been removed before adding it as a member to prevent IPv6 address scope violation.
lagg0: link state changed to DOWN
lagg0: IPv6 addresses on em5 have been removed before adding it as a member to prevent IPv6 address scope violation.
em1: link state changed to DOWN
vlan0: changing name to 'em1_vlan30'
vlan1: changing name to 'em1_vlan10'
vlan2: changing name to 'em1_vlan35'
tun1: changing name to 'ovpns1'
tun2: changing name to 'ovpnc2'
em2: link state changed to DOWN
em1: link state changed to UP
em1_vlan35: link state changed to UP
em1_vlan10: link state changed to UP
em1_vlan30: link state changed to UP
em2: link state changed to UP
em0: link state changed to DOWN
em0: link state changed to UP
pflog0: permanently promiscuous mode enabled
ovpns1: link state changed to UP
ovpns1: link state changed to DOWN
ovpns1: link state changed to UP
997.257986 [ 853] iflib_netmap_config       txr 1 rxr 1 txd 1024 rxd 1024 rbufsz 2048
em1: permanently promiscuous mode enabled
997.358747 [ 853] iflib_netmap_config       txr 1 rxr 1 txd 1024 rxd 1024 rbufsz 2048
em1: link state changed to DOWN
em1_vlan35: link state changed to DOWN
em1_vlan10: link state changed to DOWN
em1_vlan30: link state changed to DOWN
em1: link state changed to UP
em1_vlan35: link state changed to UP
em1_vlan10: link state changed to UP
em1_vlan30: link state changed to UP
arp: 10.0.0.250 moved from b0:b8:67:c9:d4:56 to b0:b8:67:c9:bd:a8 on em1
arp: 10.0.0.250 moved from b0:b8:67:c9:bd:a8 to b0:b8:67:c9:d4:56 on em1
em1: link state changed to DOWN
em1_vlan35: link state changed to DOWN
em1_vlan10: link state changed to DOWN
em1_vlan30: link state changed to DOWN
em1: link state changed to UP
em1_vlan35: link state changed to UP
em1_vlan10: link state changed to UP
em1_vlan30: link state changed to UP



3

21.7 Legacy Series / Re: Interfaces randomly go down/unroutable

« on: November 28, 2021, 07:46:14 pm »

I've been mucking with this issue for weeks. I had it on both mentioned versions of the software. I initially blamed Sensei but even disabling it I had that problem. To be clean, yes my wan DHCP stuff seems weird in the log but I'm not concerned about that right now because my problem is lan facing. I can't ping my lan side. I can't ping my management port. I can't ssh to either. The thing seems dead. As soon as I initiate shutdown with hardware button press, there's a brief moment where about 12 pings make it through before it shuts down. In my case I also lose DHCP because I'm using OPNsense as a DHCP server

4

21.7 Legacy Series / Interfaces randomly go down/unroutable

« on: November 26, 2021, 11:12:38 pm »

I have this issue where every so often (a bit on the spontaneous side, unfortunately) I lose internet.  I can't ping my IPv4 LAN facing gateway.  I can't ping my management port (which I created for troubleshooting this problem).  Looking at /var/log/system.log, I see this:

Code: [Select]

Nov 26 13:08:27 OPNsense dhclient[46336]: DHCPREQUEST on em0 to 208.110.116.101 port 67
Nov 26 13:08:27 OPNsense dhclient[46336]: DHCPACK from 208.110.116.101
Nov 26 13:08:27 OPNsense dhclient[52573]: Creating resolv.conf
Nov 26 13:08:27 OPNsense dhclient[46336]: bound to 208.110.116.102 -- renewal in 300 seconds.
Nov 26 13:13:27 OPNsense dhclient[46336]: DHCPREQUEST on em0 to 208.110.116.101 port 67
Nov 26 13:13:27 OPNsense dhclient[46336]: DHCPACK from 208.110.116.101
Nov 26 13:13:27 OPNsense dhclient[88047]: Creating resolv.conf
Nov 26 13:13:27 OPNsense dhclient[46336]: bound to 208.110.116.102 -- renewal in 300 seconds.
Nov 26 13:16:00 OPNsense root[28797]: reload filter for configured schedules
Nov 26 13:18:27 OPNsense dhclient[46336]: DHCPREQUEST on em0 to 208.110.116.101 port 67
Nov 26 13:18:27 OPNsense dhclient[46336]: DHCPACK from 208.110.116.101
Nov 26 13:18:27 OPNsense dhclient[87230]: Creating resolv.conf
Nov 26 13:18:27 OPNsense dhclient[46336]: bound to 208.110.116.102 -- renewal in 300 seconds.
Nov 26 13:23:27 OPNsense dhclient[46336]: DHCPREQUEST on em0 to 208.110.116.101 port 67
Nov 26 13:23:27 OPNsense dhclient[46336]: DHCPACK from 208.110.116.101
Nov 26 13:23:27 OPNsense dhclient[74715]: Creating resolv.conf
Nov 26 13:23:27 OPNsense dhclient[46336]: bound to 208.110.116.102 -- renewal in 300 seconds.
Nov 26 13:28:27 OPNsense dhclient[46336]: DHCPREQUEST on em0 to 208.110.116.101 port 67
Nov 26 13:28:27 OPNsense dhclient[46336]: DHCPACK from 208.110.116.101
Nov 26 13:28:27 OPNsense dhclient[65189]: Creating resolv.conf
Nov 26 13:28:27 OPNsense dhclient[46336]: bound to 208.110.116.102 -- renewal in 300 seconds.
Nov 26 13:31:00 OPNsense root[30800]: reload filter for configured schedules
Nov 26 13:33:27 OPNsense dhclient[46336]: DHCPREQUEST on em0 to 208.110.116.101 port 67
Nov 26 13:33:27 OPNsense dhclient[46336]: DHCPACK from 208.110.116.101
Nov 26 13:33:27 OPNsense dhclient[84129]: Creating resolv.conf
Nov 26 13:33:27 OPNsense dhclient[46336]: bound to 208.110.116.102 -- renewal in 300 seconds.
Nov 26 13:33:32 OPNsense kernel: em1: link state changed to DOWN
Nov 26 13:33:32 OPNsense kernel: em1_vlan35: link state changed to DOWN
Nov 26 13:33:32 OPNsense kernel: em1_vlan10: link state changed to DOWN
Nov 26 13:33:32 OPNsense kernel: em1_vlan30: link state changed to DOWN
Nov 26 13:33:32 OPNsense kernel: em2: link state changed to DOWN
Nov 26 13:33:32 OPNsense opnsense[93736]: /usr/local/etc/rc.linkup: DEVD Ethernet detached event for lan
Nov 26 13:33:33 OPNsense opnsense[63600]: /usr/local/etc/rc.linkup: Hotplug event detected for Ooma(opt2) but ignoring since interface is configured with static IP (10.35.0.254 ::)
Nov 26 13:33:33 OPNsense opnsense[75016]: /usr/local/etc/rc.linkup: Hotplug event detected for WirelessGuest(opt3) but ignoring since interface is configured with static IP (10.10.0.254 ::)
Nov 26 13:33:34 OPNsense opnsense[80883]: /usr/local/etc/rc.linkup: Hotplug event detected for WirelessTrust(opt1) but ignoring since interface is configured with static IP (10.30.0.254 ::)
Nov 26 13:33:34 OPNsense opnsense[91909]: /usr/local/etc/rc.linkup: Hotplug event detected for MGMT(opt6) but ignoring since interface is configured with static IP (10.255.255.254 ::)
Nov 26 13:36:03 OPNsense kernel: em1: link state changed to UP
Nov 26 13:36:03 OPNsense kernel: em1_vlan35: link state changed to UP
Nov 26 13:36:03 OPNsense kernel: em1_vlan10: link state changed to UP
Nov 26 13:36:03 OPNsense kernel: em1_vlan30: link state changed to UP
Nov 26 13:36:03 OPNsense opnsense[52126]: /usr/local/etc/rc.linkup: DEVD Ethernet attached event for lan
Nov 26 13:36:03 OPNsense opnsense[52126]: /usr/local/etc/rc.linkup: HOTPLUG: Configuring interface lan
Nov 26 13:36:03 OPNsense opnsense[52126]: /usr/local/etc/rc.linkup: ROUTING: entering configure using 'lan'
Nov 26 13:36:03 OPNsense kernel: em2: link state changed to UP
Nov 26 13:36:03 OPNsense opnsense[52126]: /usr/local/etc/rc.linkup: ROUTING: IPv4 default gateway set to wan
Nov 26 13:36:03 OPNsense opnsense[52126]: /usr/local/etc/rc.linkup: ROUTING: skipping IPv4 default route
Nov 26 13:36:03 OPNsense opnsense[52126]: plugins_configure ipsec (,lan)
Nov 26 13:36:03 OPNsense opnsense[52126]: plugins_configure ipsec (execute task : ipsec_configure_do(,lan))
Nov 26 13:36:03 OPNsense opnsense[52126]: plugins_configure dhcp ()
Nov 26 13:36:03 OPNsense opnsense[52126]: plugins_configure dhcp (execute task : dhcpd_dhcp_configure())
Nov 26 13:36:03 OPNsense opnsense[52126]: plugins_configure dns ()
Nov 26 13:36:03 OPNsense opnsense[52126]: plugins_configure dns (execute task : dnsmasq_configure_do())
Nov 26 13:36:03 OPNsense opnsense[52126]: plugins_configure dns (execute task : unbound_configure_do())
Nov 26 13:36:06 OPNsense opnsense[191]: /usr/local/etc/rc.linkup: Hotplug event detected for Ooma(opt2) but ignoring since interface is configured with static IP (10.35.0.254 ::)
Nov 26 13:36:06 OPNsense opnsense[6297]: /usr/local/etc/rc.newwanip: IPv4 renewal is starting on 'em1_vlan35'

I found another forum post that says marking their interface as the gateway solved their problem, but mines already set this way.

For now I've disabled gateway monitoring to see if it makes any difference, but I'm not sure why I'd lose my LAN facing stuff in this case.

5

21.7 Legacy Series / Re: Can't access web server (jNextcloud) due to HSTS error

« on: November 02, 2021, 03:52:03 am »

Nope that didn't do it.  I tried Epiphany, Chromium, and Google Chrome and they do not have this issue.  Just firefox.  I am still puzzled why OPNsense cares at all.  I guess because it is now serving my DNS that is why, but even then I don't know why the other browsers don't complain.

Same L2 subnet, my PC does a DNS lookup to OPNsense, retrieves the inside IP of the server which is the same L2 subnet.  That's it.  From then on out all communication is direct between my server and my PC.  This server also has an external NAT in, though, but not sure how DNS is a ware of that.

6

21.7 Legacy Series / Can't access web server (jNextcloud) due to HSTS error

« on: October 31, 2021, 06:32:11 am »

I don't have this problem on other browsers, I'm using firefox.  For some reason Firefox is getting the certificate of my opnsense firewall instead of Nextcloud.  If I use another browser it works fine and shows the correct cert.  My only thought on this is how my DNS server resides on opnsense so somehow that is causing this issue.  There's no technical reason I can think of why it would happen otherwise.  Nextcloud and my PC are on the same L2 network.

It's important to note if I hit the server with its IP address, I get the correct certificate (but nextcloud barks because the URL is not the FQDN, which is expected).  I am mystified as to why I get an opnsense cert instead of my letsencrypt cert.  It happens with sensei/zenarmor on or off.

7

Virtual private networks / PPTP/L2TP Internet

« on: October 29, 2021, 07:07:58 am »

Hi All,

My ISP is one of the smaller ones that uses PPTP/L2TP to run over other companies wires to give me internet.  Currently they gave me a mikrotik in which I connect OPNsense to (protectli appliance) and the mikrotik and protectli each get an IP out of a public /30.

I can see on the mikrotik the "connect to" IP address, where my credentials go as well.  I don't see source IP address configuration so it's kind of like black magic to me.

I'm confused on the roles involved with my actual physical WAN interface (em0) and the "Point-to-Point" section.  They sort of seem to overlap and I'm not sure what goes where.  Right now the mikrotik has a static for the other IP in my /30 and dishes out DHCP for the remaining IP to my firewall.

Should my WAN interface be changed from DHCP to PPTP (or L2TP, as I think my provider accepts both... but one step at a time here)?  If I do this it is asking for a local and remote address below.  I don't know what these are.  I've just been given a gateway IP which is RFC1918 (172.16.X.X) and my public IPs.  I would assume the remote box would contain the "Connect To" IP address I see in the PPTP config on the mikrotik.  But not a clue what the local address or mask would be.

I'm sorry if this is confusing but I really don't understand how this is supposed to work at all.

8

General Discussion / Re: Internet randomly dies

« on: August 31, 2021, 07:06:21 pm »

Considered this but it would be nice to find it in a log somewhere.  Might have to resort to this

9

General Discussion / Internet randomly dies

« on: August 31, 2021, 05:07:17 pm »

Hi,

Twice now since I installed opnsense on a protectli I've had it kill internet on me.  I can't even ping the firewall inside IP.  What I do to fix it is push the power button until it shuts down, then turn it on again and all is well.

I have a suspicion that it's sensei causing the problem but I can't be certain without examining logs.  The reason I suspect it is because once I initiate the shutdown sequence internet comes back fairly quickly until the box shuts down, so its seems as if a service is shut down at the point it comes back.

Short of being prepared at that moment to console into the firewall I'm not sure what I can do to check what occurred around that time.

OPNsense 21.7.1-amd64
FreeBSD 12.1-RELEASE-p19-HBSD
OpenSSL 1.1.1k 25 Mar 2021

10

General Discussion / Re: Firewall has no implicit deny all

« on: August 26, 2021, 05:13:19 am »

I think really the summary of it all is zones are easy because if you create a zone for internet, and attach it to your internet port, anything routed out that interface is destined to the internet zone, so that will catch anything headed in that direction, regardless of IP address.  It does make things really easy. 

For example:
from [wired] to [internet] action: permit
from [wired] to [wireless trust] application: HTTPS action: permit

Above would let wired clients have access to internet and just HTTPs to the wireless trust zone.

For *sense you'd have to do something like
from [wired] to [wireless trust] port:443 action: permit
from [wired] to [any] except [lan subnets] action: permit
[address-group: lan subnets] <- manually maintain this as you add vlans and so on

Yeah the title is a bit of a thing - my intent was to point out how the way my firewall is configured at this time, it seemingly has no implicit deny all.  But I get what you mean.

In any event I need to adjust how I view the firewall on this thing.  Thanks for the clarification!

11

General Discussion / Re: Firewall has no implicit deny all

« on: August 26, 2021, 04:16:15 am »

My home network has 5 VLANs.  The networks I work on day to day often have even more.  From my view, it's a royal PITA to have to create an address object for all these VLANs and remember to add it to the bottom of the rule sets.  In addition, if I want a mix of access on a mix of VLANs now I'm adding multiple rules with multiple address objects.  Let's say for example I have this:

MGMT: VLAN 1
Trust: VLAN 2
Untrust-Wired: VLAN 3
Trust-WiFi: VLAN 4
Untrust-WiFi: VLAN 5
Cameras: VLAN 6
Internet

Now I want all my VLANs except for cameras to reach the internet, and I want trust to permit full access to cameras and MGMT, and I want trust-wifi to access just trust, and with a mix of full open or port based.

With the approach of security zones this is quite simple.  With zones everything is dropped no matter what.  If you want the Trust interface/zone to reach the internet, you just add a simple rule like trust to internet, done.  In the case of opnsense and pfsense, you can't do that without making a custom address object. But it's a one time thing so not a big deal... until you get to wanting trust-wifi to reach wired and internet.  Now you're talking a new address object, or 2 rules. And you have to mentally validate your rule order which isn't necessarily needed with the zone method.

Just because I didn't understand the way it worked here isn't to say it's wrong, don't mistake me.  My point is convenience and simplicity.

I'm not sure about your comment on how my title is the opposite of how opnsense works.  It definitely has implicit deny all, I have never come across a firewall that has an implicit permit all (unless it's meraki IVR).  The catch in my case was that I was assuming each rule set attached to each interface was dropping anything not allowed, not realizing that a rule on another interface can affect the interface I was looking at.  IE: permit wifi-trust to all permits to wired firewall rule set, even if the firewall rule set only has 1 rule to permit internet access, for example.  Again I'm not saying the approach is wrong, just that I didn't realize it didn't work that way.

In my view, much easier to do it the zone way.

12

General Discussion / Re: Firewall has no implicit deny all

« on: August 25, 2021, 11:19:25 pm »

OK then that's the way I guess I'll have to do it.  I've got a ton of years of experience with Palo Alto and I really like the approach there.  But ya, that's zones.

13

General Discussion / Re: Firewall has no implicit deny all

« on: August 25, 2021, 05:43:58 am »

OK this is what I ended up discovering earlier and it works, but it kind of baffles me.  I don't even think pfSense did this but I could be wrong.  It's a little weird how pf/opnsense present it in the UI but I'm wrapping my head around it.  It's honestly a bit more work to set up policies in this fashion as well. 

Like if I want a wifi "zone" and a wired "zone" and want to permit both out to the internet, but not to one another, I need to set it to permit wifi->!rfc1918, then put my exceptions above that.  Unless I'm blind there seems to be no prebuilt object for referring to the internet so I just made my own as you did.  At first I had it set to bogon networks but then I realized that object is actually blank by default, from what I can tell.

Is there no better way to accomplish this?

14

General Discussion / Firewall has no implicit deny all

« on: August 24, 2021, 05:38:48 pm »

I have multiple VLANs on my network and for the life of me I cannot figure out why the implicit deny all doesn't seem to work.  Take for instance, I have my wired VLAN and my WiFi VLAN:
LAN:
10.0.0.0/24
WiFi:
10.30.0.0/24

When I ping from my WiFi net to my LAN net, it should be dropped.

But instead, I'm seeing it permitted and matching this floating rule that was automatically created with the description:
"let out anything from firewall host itself"

There's even a "default deny any" rule above that one.  So I'm not sure where these rules are coming from and it isn't secure.

Where are these coming from and how do I secure it?

15

Zenarmor (Sensei) / Re: New install with sensei on protectli vault crashing

« on: July 22, 2021, 02:01:26 am »

At this point I'm convinced it was the LAGG.  I haven't had an issue in over 30 minutes.  There was a message that would pop up, which I can't recall or have recorded anywhere, whenever I'd start the service while using the LAGG.

One of the times my console was spitting this almost constantly:
freebsd_generic_rx_handler warning rx packet intercepted but no emulated adapter

I tried each of the different drivers.  This box has intel NICs.