OPNsense
  • Home
  • Help
  • Search
  • Login
  • Register

  • OPNsense Forum »
  • Profile of Seimus »
  • 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 - Seimus

Pages: 1 ... 33 34 [35] 36 37 ... 41
511
General Discussion / Re: Does opnsense help contribute code commits to freebsd?
« on: October 27, 2023, 10:02:33 am »
aaaand here we go, Netgate doing exactly what most of the community already thought will happen.

2 years or so when I was angry at proprietary solution and was deciding if to go either OPN or PF 2 major things decided for me to go for OPN:

1. Suspicion that NetGate will do a rugpull or other rather anti community decisions
2. Community and OPNsense interactions of the forum (you guys are just awesome)

Also in regards of Lawrence YT channel. As I watch his channel for years.
You can learn a lot from him about networking and security, however when it comes to the question of PFsense or Netgate, no matter what he will always give them pass/protect them.

When it comes to comparisons from him between PF an OPN, even thou he tries to be unbiased. He will always more lean and tell you in between the lines that PF is better because ______. A beautiful example of this is his video posted by the @allebone and one of its older where he did directly compare PF vs OPN. Example:

In the old video he complained that OPN is not so fast updated, that PF is faster updated thus is better. Yet in his latest video he is saying exactly the opposite That OPNsense has more updates than PF yet it may cause problems (like bugs, issues etc.). This made me laugh actually listening to his reaction and remembering some of his old videos.

Regards,
S.

512
23.7 Legacy Series / Re: "Set Priority" to a specific LAN rule
« on: October 26, 2023, 10:32:21 am »
To your question, you use both, VOICE is bidirectional traffic. Video depending if you stream as well or not is Multicast based so unidirectional, ether you are the receiver or sender. From the issue describe the problem occurs during download so download is the problem here however you should do it for both direction.

Another and more important thing, if you are using FQ_CODEL then you can not use Weighted queues, FQ_CODEL doesn't use that. So if you want to use FQ_Codel you need to create separate pipes for each service. Or dont use FQ_Codel if you want to have only one pipe and use Weighted queues

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

The link that CJ provided there you can see examples of BW reservation for VOICE, you can do same for VIDEO
https://docs.opnsense.org/manual/how-tos/shaper_dedicated_bw.html

Regards,
S.


513
23.7 Legacy Series / Re: Alias problem
« on: October 23, 2023, 12:07:19 pm »
Can you post the output of /usr/local/opnsense/scripts/filter/lib/alias/base.py

Also how many Aliases do you have?
Can you paste the configuration of all of your Aliases?

Regards,
S.

514
23.7 Legacy Series / Re: Route between vlan not working correctly
« on: October 23, 2023, 12:00:58 pm »
Quote from: mekano on October 23, 2023, 02:28:41 am


vlan 10 192.168.10.0/24 ip of the interfcace 192.168.10.1
vlan 20 192.168.20.0/24 ip of the interface 192.168.20.1


Do what Patrick said.

For InterVLAN routing within your VLAN domains you dont need RPLs (also you have them wrong). Currently you are forcing the traffic on IN do go back from where it came.

Regards,
S.

515
23.7 Legacy Series / Re: os-frr + bgp + route map
« on: October 19, 2023, 12:23:13 pm »
If you remove the prefix-list object from the route-map seq 10, and let the route-map applied on the neighbor, do you get the same error?

Regards,
S.

516
23.7 Legacy Series / Re: dpinger behaviour after WAN IF down [SOLVED - bug filed]
« on: October 19, 2023, 09:21:22 am »
Quote from: bulmaro on October 19, 2023, 03:19:39 am
today I updated my version, I still have a multi wan problem, the main gateway is not activated, apply this patch
# opnsense-patch 3c46b33a3e
the problem continues

Gateways: Log File

2023-10-18T19:20:05-06:00   Warning   dpinger   WAN_DHCP 1.1.1.1: sendto error: 64   
2023-10-18T19:20:04-06:00   Warning   dpinger   WAN_DHCP 1.1.1.1: sendto error: 64   
2023-10-18T19:20:03-06:00   Warning   dpinger   WAN_DHCP 1.1.1.1: sendto error: 64   
2023-10-18T19:20:02-06:00   Warning   dpinger   WAN_DHCP 1.1.1.1: sendto error: 64   
2023-10-18T19:20:01-06:00   Warning   dpinger   WAN_DHCP 1.1.1.1: sendto error: 64   
2023-10-18T19:20:00-06:00   Warning   dpinger   WAN_DHCP 1.1.1.1: sendto error: 64   
2023-10-18T19:19:59-06:00   Warning   dpinger   WAN_DHCP 1.1.1.1: sendto error: 64   
2023-10-18T19:19:58-06:00   Warning   dpinger   WAN_DHCP 1.1.1.1: sendto error: 64

Also why are you monitoring an ANYCAST IP? The cloudflare DNS 1.1.1.1 as its an ANYCAST IP/NETWORK will be reachable always if at least one of its resolver is UP.

Wouldn't be better if you ping the GW of your ISP? Or an UNICAST BASED IP that is closer to you?

Regards,
S.

517
23.1 Legacy Series / Re: Why are there two WireGuard plugins?
« on: October 16, 2023, 11:23:25 am »
Cant say for sure, but.

At release 23.7.3 WG

https://docs.opnsense.org/releases/CE_23.7.html#august-30-2023

Regards,
S.

518
23.7 Legacy Series / Re: new lan not getting access to internet
« on: October 12, 2023, 09:39:26 am »
Segregation is achieved via splitting up the networks, either L2 via VLANs or L3 via Networks, both of them are usually used in together.

If you have split networks for LAB and LAN, assuming you have 2 L3 Interfaces for each specific Network. Firewalls essentially filter traffic in two directions INbound and OUTbound. By default INbound has implicit DENY on the interface/zone, you need to create a INbound RULE on the specific Interface to ALLOW traffic you want (OUTbound is by default ALLOWed).

Currently those RULES you have in place only ALLOW traffic for ICMP towards this Firewall.

Regards,
S.

519
23.7 Legacy Series / Re: OpnSense after three months use
« on: October 11, 2023, 11:34:27 am »
Quote from: franco on October 10, 2023, 09:09:49 pm
> Is see suddenly a lot of posts with problems using Wireguard.

Confirmation bias does that. It's not more or less for any other VPN. Even the "simple" WireGuard protocol can be challenging.

And of course there is always a bug hidden somewhere. We can't find it without users reporting problems. ;)


Cheers,
Franco

I can only agree on this as per my experience with Enterprise vendors.

As well this is not vendor exclusive. Basically as for any vendor and any feature they are providing. Can say I've seen many weird stuff happening with many vendors.

Certain scenarios and use cases trigger certain bugs/problems.

Regards,
S.

520
23.7 Legacy Series / Re: new lan not getting access to internet
« on: October 11, 2023, 11:19:30 am »
As Maurice said, destination field in the rule cant be WAN for this, the WAN specifies the FW WAN interface IP.

So by your rule traffic only to the WAN IP is permitted and not to the Internet. You need to put ANY or if you want only Internet access while blocking LAN communication between host you can do it via Alias using inverse match in the rule.

Regards,
S.

521
23.7 Legacy Series / Re: OpnSense after three months use
« on: October 06, 2023, 09:30:19 am »
Interesting stuff with the Wireguard,

I am using WG as well on Community editions OPN, basically cant live without out it, yet never experienced such issues. I am as well not using official HW but a miniPC knockoff. Also my WG implementation is RA. I believe you are using as well persistent WG tunnel? My is more or less on-demand used only in case I am out of the Home network.

Would be interesting to test it in a persistent way.

Thanks for your post, I'll personally keep an eye on this.

Regards,
S.

522
23.7 Legacy Series / Re: trying towork through VLAN set up.
« on: September 22, 2023, 05:17:55 pm »
That is not fully true "advice that tagged networks have a separate interface from your firewall/router." in the way you present it.

The main reason of VLANs is that you can have several logical segments over 1 cable. A Switch usually is capable to carry over 4096 VLANs from which one of them is NATIVE (Native meaning traffic that doesnt fell under any of TAGGed VLANs falls under this NATIVE VLAN. Native VLAN you can understand as partiually unTAGed VLAN but thats not really true from a perspective of a switch.)

Another point: "Another reason an untagged network was important is that I have a mixture of consumer devices on the network that don't have VLAN capability.". You dont need consumer devices capable of vlan TAGing is just bad mindset. TAGing is done on network interfaces. If you want to TAG a specific end device to a specific HOST that doesn't do or doesn't know TAG all you need to do is to set on a switch on that particular port for a device so called "access VLAN". Switch will then assign a TAG to it once he sees traffic coming from that port and remove it outgoing way.

"Theoretically, if I leave ports untagged, they will convert the tagged traffic to untagged on the way out of the port and tag it on the way in. At least, that's what I gathered from the VLAN write-ups."
This only works if you have a managed switch cable VLAN TAGs. The TAG and unTAG is done on a port configured as access.

There are many uses cases you can do the setup. I personally prefer to have a Portchannel so called LAGG between a Switch and the OPNsense, and on this PO create VLANs + GW per VLAN. This way you have more redundant, resilient and higher capacity connection between OPN and a SWITCH. Switch is then per port per End device set to either Trunk mode (multiple VLANs) - where a server is TAGing several VLANs or access mode - single VLAN like for IoT where switch is TAGing.

Regards,
S.


523
23.7 Legacy Series / Re: trying towork through VLAN set up.
« on: September 22, 2023, 09:53:51 am »
So let me ask just right away,

You are using TAGed and non-TAGed VLANs? If yes this is generally not a good idea, even thou it may work its not "officially supported/recommended".

In regards of Rules, its quiet simple. You close always if not mostly permitt traffic INCOMING way, once its in FW the default rule "Let anything out of GW/FW" will let it go automatically from the OUTGOING way.


For test you can just do a simple rule on the VLAN and LAN and allow any to any IN. Than you can Harden it and disable the default allow any/any rule.

Regards,
S.

524
23.7 Legacy Series / Re: New default Firewall > Rules interface OpenVPN 23.7.4
« on: September 20, 2023, 01:56:40 pm »
That settles it, for a moment I thought I am getting paranoid.

Thanks Franco.

Regards,
S.

525
23.7 Legacy Series / Re: New default Firewall > Rules interface OpenVPN 23.7.4
« on: September 20, 2023, 01:51:01 pm »
Checked as well Firewall > Groups, and I can see two new non-removable groups are created

  • openvpn
  • enc0(IPSEC)

So this really looks like a new default inbaked into the latest OPN release.

Regards,
S.

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