Menu

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.

Show posts Menu

Messages - hharry

#1
Quote from: CntrlAltDel on December 13, 2024, 09:29:03 AMISP is saying PPPOE connectivity is being rejected from their end but like I said I've gotten this to work before and it does work on my regular Asus router.

I have PPPoE running successfully in OPNsense running in ESXi VM, without any issues....works great, even supports adaptive LCP echo request, which is a big plus...

You just need to take a look at the PPPoE logs to figure out what's not working in your deployment.

Just navigate to Interfaces -> Point-to-Point -> LogFile

Select Log level = informational


PPPoE is quite a simple protocol to tshoot, and the logging is excellent.
#2
look into zenarmor for NGFW capability....

opnsense does support filtering based on FQDN....if that whats your after, but for true content filtering, you'll likely be better off with zenarmor
#3
and this type of response is why opnsense can never be taken as a serious F/W....
#4
there mere fact that the rule is installed, and enabled, when CARP is admin disabled is sloppy in itself...needs to cleaned up....

It should be a simple trivial fix, so why you need to debate a useless point ?
#5
It seems the is an automatic IPv4 CARP rule is applied, when CARP is administratively disabled.

Can this tidied up?, such that when  CARP is admin disabled, the automatic rule's are removed...

#6
i had the same issue, ripd frequently crashing....

I've even upgraded to the latest OPNsense 24.7.9_1-amd64, however didn't resolve the issue....

It got so bad, i migrated all L3 routing topology, over to ospf, which so far has been stable...plus more secure etc...


It's evidently something specific to opnsense, as i run frr + ripd on separate Linux VM's, and VYOS + frr + ripd, in the same L2 and L3 domain as opnsense, and none have this issue....