Messages

1

24.1 Legacy Series / Re: OPNsense in a jail on a FreeBSD host?

« on: July 09, 2024, 11:27:14 pm »

Hello
I came across this post just now. Interesting that somebody else is also looking at jailed version of OPNsense.
I have mostly positive expirience running opnsense inside FreeBSD jail. There are some little thing that are either not working or woking with a little bit of work. Again, mostly all functionality is there. Ask me questions on this matter if interested

2

22.7 Legacy Series / Re: Bridge/transparent/ interface passing dot1x

« on: September 20, 2022, 12:45:03 am »

.1q vlans won't be able to communicate over the bridge if only you mix tag/no tag on the bridge. Even if you need such a setup you could still to use ng_bridge instead.

3

22.1 Legacy Series / Re: Lost connectivity to some internet service

« on: March 31, 2022, 07:03:08 pm »

@yorch

You can ssh into the box and run this

Code: [Select]

tcpdump -tenpi pflog0
You can limit the information it shows by applying some filters
This one is going to display information only related to vtnet1 interface and traffic that being blocked

Code: [Select]

tcpdump -tenpi pflog0 ifname vtnet1 and action block

4

22.1 Legacy Series / Re: Lost connectivity to some internet service

« on: March 31, 2022, 05:10:36 pm »

Hello everyone,

I was just troubleshooting same behavior (so far Facebook is not working)
So far I see that packets coming to Facebook (31.13.93.54 and 157.240.241.17) are being blocked by the default rule (in my case it's rule 12)

Code: [Select]

rule 12/0(match): block in on vtnet1: 192.168.1.113.50103 > 31.13.93.54.5222: Flags [F.], seq 0, ack 1, win 65535, length 0
rule 12/0(match): block in on vtnet1: 192.168.1.113.49194 > 157.240.241.17.443: Flags [F.], seq 0, ack 1, win 65535, length 0
rule 12/0(match): block in on vtnet1: 192.168.1.113.50103 > 31.13.93.54.5222: Flags [F.], seq 0, ack 1, win 65535, length 0
rule 12/0(match): block in on vtnet1: 192.168.1.113.49194 > 157.240.241.17.443: Flags [F.], seq 0, ack 1, win 65535, length 0
rule 12/0(match): block in on vtnet1: 192.168.1.113.50103 > 31.13.93.54.5222: Flags [F.], seq 0, ack 1, win 65535, length 0
Actual rule 12 looks like this:

Code: [Select]

@12 block drop in log inet all label "02f4bab031b57d1e30553ce08e0ec131"
I don't understand why packets coming to some specific IPs are blocked by this default rule.
PS. If I just wipe out all the rules and create some manually (like nat and default allow rule) everything is fine.

I'm more than happy if somebody shed some light on this issue.
Thank you.

5

17.7 Legacy Series / Re: how to move anti-lockout rules to a bridge interface

« on: January 16, 2018, 12:53:35 pm »

Hello,

I faced same problem. Let me explain.
When I do have two local interfaces (vtnet1 and vtnet2) and I need to tight them together (created bridge interface). So the final bridge interface in my scenario has name LAN.
So, Anti-lockout rules are exist on the previously configured LAN interface (was vtnet1).
My question is, how to move Anti-lockout rules off the vtnet1 and put in to the new LAN?
Of course I could create same rules manually, but this just doesn't make a sense.
Let me know if you need any information from my system.
Thank you.