OPNsense
  • Home
  • Help
  • Search
  • Login
  • Register

  • OPNsense Forum »
  • Profile of zeon »
  • Show Posts »
  • Messages
  • Profile Info
    • Summary
    • Show Stats
    • Show Posts...
      • Messages
      • Topics
      • Attachments

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

  • Messages
  • Topics
  • Attachments

Messages - zeon

Pages: [1]
1
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.

2
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

3
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.

4
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.

Pages: [1]
OPNsense is an OSS project © Deciso B.V. 2015 - 2023 All rights reserved
  • SMF 2.0.19 | SMF © 2021, Simple Machines
    Privacy Policy
    | XHTML | RSS | WAP2