Messages

1

23.1 Legacy Series / Re: Blocking established connections?

« on: April 29, 2023, 11:14:42 pm »

Thx!  Any way to make it programmatic?  I suppose I could try a curl/cron from another machine....

Edits

I should have done a better search.  I found how to do it via the CLI:

Code: [Select]

/sbin/pfctl -F state
For others, here's the source of the above and how to automate it:

https://forum.opnsense.org/index.php?topic=10740.0

2

23.1 Legacy Series / Solved - Blocking established connections?

« on: April 29, 2023, 06:47:29 pm »

Hi,

I've set up a single, scheduled IP blocking rule on my LAN.  It works for new connections but it does not block an established connection.

I tried with and without Firewall > Settings > Advanced > Schedule States checked.

How would I go about blocking established connections?

I've searched the forum and I didn't get any hits.  It's possible that my searching -fu isn't all that great.  :\

Thx!

3

21.1 Legacy Series / Re: THANK YOU

« on: January 30, 2021, 11:10:36 pm »

+1!

(As much as I hate the old AOL "me too" ... :p )

4

21.1 Legacy Series / Re: Upgrade to 21.1 may take *very* long time (>1h)

« on: January 30, 2021, 11:09:54 pm »

Hi everyone,

I upgraded a VM before upgrading one of my GWs.  I monitored the Console and noticed one of the longest steps was the extraction of the new packages.  This takes CPU + I/O.

My GW upgrade time was four minutes.

Below is my write-time on the SSD gumstick:

Code: [Select]

# dd if=/dev/zero of=x bs=64k count=10000;rm x
10000+0 records in
10000+0 records out
655360000 bytes transferred in 1.967271 secs (333131472 bytes/sec)


5

20.7 Legacy Series / Re: [Solved ] Bridging working except LAN to 'bridged LAN'

« on: January 23, 2021, 03:56:51 am »

It seems using OPNsense as my test VM was not a good idea.  I tried Puppy Linux and everything is working like I expect.  Phew!

-pablo

6

20.7 Legacy Series / Re: [Solved] Bridging weirdness

« on: January 23, 2021, 03:55:37 am »

During my tests I was using OPNSense in my VM.  I thought, hmm, perhaps I should try something else. 

I downloaded Puppy Linux (it's small) and voila, everything is working as I expected.

Thx!
-pablo

7

20.7 Legacy Series / [Solved] Bridging weirdness

« on: January 22, 2021, 11:50:50 pm »

Hi,

I am trying to understand a particular behavior with my bridge set up that's causing me heartburn. 

Below is some ASCII art of my set up:

Interfaces
==========
o LAN   - ig0

o WANBr - ig1

o LAN2  - ig2
   |
   +---- V1010

o WAN   - bridge0
             |
             +  WANBr + V1010

Topology
========
 VM -- V1010 -+
              |
              +-- [ GW ] -- WAN -- [ GW2 ] -- Internet
              |
   ...  LAN --+


If I ping the VM from any machine on the WAN, an ICMP reply is setn from [GW2]

If I ping the VM from [GW], the ping appears to go through [GW2] since it's a wireless connection.  The ping time is in ms versus sub-ms (what a local ping should be).

I cannot ping the VM from any machine on my LAN.  Using tcpdump, I never see a reply hit the LAN interface.

Any tips on how to proceed?   I'm going crazy! 

Thx!
-pablo

8

20.7 Legacy Series / [Solved ] Bridging working except LAN to 'bridged LAN'

« on: January 19, 2021, 04:42:08 am »

Hi!

I'm hoping I can get some direction on solving a bridging access problem.

Environment

I am double NATd:

• LAN is 192.168.10.0/24
• WAN is 10.8.0.0/24

Goal

• I would like to create a bridge between my WAN and two machines on the LAN.  Let's say they're 10.8.0.10 and 10.8.0.11
• I would like machines on the WAN to access the two machines on the LAN via their respective IP:  10.8.0.10 and 10.8.0.11
• From within my LAN, I'd like to access these two machines also by their 10.x.x.x addresses
• Similar to my LAN, I'd like the same from within my OPNsense gateway

Working

To keep things simple I decided to start with one machine.

I was able to created the bridge between the old WAN interface and a VLAN to access 10.8.0.10 from the bridged WAN:  ping, ssh all work.

Not working

The following two items are not working.  :\

• From within my LAN, I'd like to access these two machines also by their 10.x.x.x addresses
• Similar to my LAN, I'd like the same from within my OPNsense gateway

My gut tells me that I need to implement some NATing.

Any tips on what I should research?   All hints welcomed! 

Interfaces

• LAN - igb0 - 192.168.10.1/24
• WANBr - igb1
• INT_10_NET - igb2 - 192.168.24.1/24
• V99 - vlan 99 on igb2
• WAN - bridge0 - V99 + WANBr - 10.8.0.7/24

9

20.7 Legacy Series / Re: Upgrade to 20.7 fails

« on: October 14, 2020, 08:36:18 pm »

Hey everyone,

In my VirtualBox test bed, I had to repeatedly stop syslog-ng for the upgrade from 20.7 to 20.7.3 to complete.

With one browser driving the upgrade, I used a second browser to stop syslog-ng from restarting.

I clog -f'd /var/log/system.log and when syslog would restart, I'd use the second browser to stop it. 

The recipe was the following:

1) Stop syslog-ng in browser #2
2) clog -f /var/log/system.log in a shell
3) Start the upgrade from 20.7 to 20.7.3 in browser #1
4) When I see syslog restarting in the shell, use browser #2 to stop it again
5) Watch the upgrade press on in browser #1
6) Repeat 4) and 5) until done

To confirm all went well, I did an audit after the upgrade completed.

Thx!
-pablo

10

20.1 Legacy Series / HOWTO: Bridging > VLAN to LAN > remotely

« on: May 14, 2020, 01:31:17 pm »

Hi everyone,

I am sure everyone knows the power of having OPNsense use a centralized, open-format configuration file.  I thought I'd share how I plan on implementing Bridging without the need to be physically in front of my router.

Background
We're introducing a Raspberry Pi in our outdoor enclosure to monitor temperature and other goodies.  It will be connected to a Smart Switch and presented to the router via a VLAN.

We want to Bridge the VLAN with the LAN.

Problem
During the Bridge creation, there's a step when access to the GUI via the VLAN is lost.

Solution
When I was proving out OPNsource as a viable solution, I created a virtualized test lab.  It simulates my needs:  N-Cable Modems, houses connected to their respective Cable Modem, etc. etc.

My lab allows me to slurp in a modified Production XML backup to simulate Production. 

A simple sed script is used to change the Interface names from Production and my lab.  After running the script, the config file is ready for my lab machine.

I was able to create the Bridge in my lab, diff the before and after XML files to confirm that I can import the config to Production.  After importing, Production should come up with the Bridge set up.

By doing it above, the only outage will be when I reboot Production with the new config file.

I absolutely love how the XML file strives to abstract the functionality.  By doing it this way, it makes the above possible.  Thank you smart people who developed OPNsense.  I truly appreciate the thinking behind it.

Very cool!

11

20.1 Legacy Series / Re: kernel panic on 20.1.5.1 > panic: sbsndptr

« on: May 04, 2020, 08:46:59 pm »

FYI:  I've been offsite until recently.  I submitted via the GUI a bug report.

12

20.1 Legacy Series / Re: kernel panic on 20.1.5.1 > panic: sbsndptr

« on: May 04, 2020, 08:20:27 pm »

No, no WireGurad. 

ps:  I had to Google what that was ... :p

13

20.1 Legacy Series / Re: kernel panic on 20.1.5.1 > panic: sbsndptr

« on: May 04, 2020, 02:49:50 pm »

No, no PPPoE. 


I use Cable Modems (one active at the moment) set up in Router mode.


Thx!
-pablo

14

20.1 Legacy Series / kernel panic on 20.1.5.1 > panic: sbsndptr

« on: May 04, 2020, 01:29:33 pm »

Hi,


This morning my kernel panicked - see below.  I'm on 20.1.5.1 - full details below. 


I see there's version 20.1.6 but it's not clear to me if the issue below is addressed.


Any advice on how to proceed would be appreciated. 


Thx!
-pablo


Trace

May  4 01:01:09 beast syslogd: kernel boot file is /boot/kernel/kernel
May  4 01:01:09 beast kernel: panic: sbsndptr: sockbuf 0xfffff80073ddc878 and mbuf 0xfffff8013d1a6c00 clashing
May  4 01:01:09 beast kernel: cpuid = 1
May  4 01:01:09 beast kernel: __HardenedBSD_version = 1100056 __FreeBSD_version = 1102000
May  4 01:01:09 beast kernel: version = FreeBSD 11.2-RELEASE-p18-HBSD  f08b5f14327(stable/20.1)
May  4 01:01:09 beast kernel: KDB: stack backtrace:
May  4 01:01:09 beast kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe01ece48180
May  4 01:01:09 beast kernel: vpanic() at vpanic+0x17c/frame 0xfffffe01ece481e0
May  4 01:01:09 beast kernel: panic() at panic+0x43/frame 0xfffffe01ece48240
May  4 01:01:09 beast kernel: sbsndptr() at sbsndptr+0xd5/frame 0xfffffe01ece48250
May  4 01:01:09 beast kernel: tcp_output() at tcp_output+0x1009/frame 0xfffffe01ece483f0
May  4 01:01:09 beast kernel: tcp_do_segment() at tcp_do_segment+0x2453/frame 0xfffffe01ece484f0
May  4 01:01:09 beast kernel: tcp_input() at tcp_input+0xf5b/frame 0xfffffe01ece48650
May  4 01:01:09 beast kernel: ip_input() at ip_input+0x141/frame 0xfffffe01ece486b0
May  4 01:01:09 beast kernel: netisr_dispatch_src() at netisr_dispatch_src+0xa8/frame 0xfffffe01ece48700
May  4 01:01:09 beast kernel: ether_demux() at ether_demux+0x140/frame 0xfffffe01ece48730
May  4 01:01:09 beast kernel: ng_ether_rcv_upper() at ng_ether_rcv_upper+0x8e/frame 0xfffffe01ece48750
May  4 01:01:09 beast kernel: ng_apply_item() at ng_apply_item+0x163/frame 0xfffffe01ece487e0
May  4 01:01:09 beast kernel: ng_snd_item() at ng_snd_item+0x2e7/frame 0xfffffe01ece48820
May  4 01:01:09 beast kernel: ng_apply_item() at ng_apply_item+0x163/frame 0xfffffe01ece488b0
May  4 01:01:09 beast kernel: ng_snd_item() at ng_snd_item+0x2e7/frame 0xfffffe01ece488f0
May  4 01:01:09 beast kernel: ng_ether_input() at ng_ether_input+0x4c/frame 0xfffffe01ece48920
May  4 01:01:09 beast kernel: ether_nh_input() at ether_nh_input+0x289/frame 0xfffffe01ece48980
May  4 01:01:09 beast kernel: netisr_dispatch_src() at netisr_dispatch_src+0xa8/frame 0xfffffe01ece489d0
May  4 01:01:09 beast kernel: ether_input() at ether_input+0x26/frame 0xfffffe01ece489f0
May  4 01:01:09 beast kernel: igb_rxeof() at igb_rxeof+0x721/frame 0xfffffe01ece48a90
May  4 01:01:09 beast kernel: igb_msix_que() at igb_msix_que+0x117/frame 0xfffffe01ece48ae0
May  4 01:01:09 beast kernel: intr_event_execute_handlers() at intr_event_execute_handlers+0xe9/frame 0xfffffe01ece48b20
May  4 01:01:09 beast kernel: ithread_loop() at ithread_loop+0xe7/frame 0xfffffe01ece48b70
May  4 01:01:09 beast kernel: fork_exit() at fork_exit+0x83/frame 0xfffffe01ece48bb0
May  4 01:01:09 beast kernel: fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe01ece48bb0
May  4 01:01:09 beast kernel: --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
May  4 01:01:09 beast kernel: KDB: enter: panic
 



Version Information

• OPNsense 20.1.5-amd64
• FreeBSD 11.2-RELEASE-p18-HBSD
• OpenSSL 1.1.1f 31 Mar 2020

15

20.1 Legacy Series / Re: OPNsense > jaw-dropping goodness!

« on: April 26, 2020, 05:37:19 pm »

... combined bandwidth might be more than the entire cable network can provide ... Just wondering if this might be relevant for you.

Thank you for responding.  The overarching issue is we need to map each home to their Internet drop.  No sharing.  The ISP is very clear about this and we don't want to upset them.   

The solution will afford each home to buy the package that fits their needs.