Messages

aaand.... after a decent night sleep and some coffee i went ahead and actually enabled the haproxy service in the config to solve this  ::)

could do with a "make sure the service is enabled" addition to the message...
but then again, could also just notice the fact that the status button is not shown, so... more coffee and sleep.

So, while i had no issues on a 21.7.5 machine, i just setup a new opnsense,
so a completely NEW setup, no tinkering, no importing, no whatever.

while configuring haproxy i keep running into the issue that it says "There are pending configuration changes that must be applied in order for them to take effect. To review them visit the Config Diff page."
and when i hit apply.... it does not apply.
and so, no way to start haproxy.

when i move haproxy.conf.staging to haproxy.conf manually, and start haproxy manually, there is no issue and the gui happily says there are no config changes.
i then change something in the gui again aaaaaand.... broken again.

is this a known issue for 21.7.7 ?
is someone else experiencing this ?

we have opnsense support if needed, so i could always contact their paid support, but before bothering them  like that,
i wanted to verify in the community if anyone else is seeing this.

as i was looking back through the forums (dont come here too often) and github i was compelled to donate as well.
i know deciso has income from their enterprise offerings, but hey... they are offering a great product for free, and listening and helping the community out, so the community should do the same.

since i've been using opnsense since practically the beginning and would recommend everyone this over any other firewall,
we'll go for the monthly donation here as well.
and since 3 euro seems to be the going rate, that's what we'll chip in !

Welcome to the opnsense fanbase :)

This is (probably) due to the current filter being applied to interface, but not to the network of that interface.
That means any traffic captured coming or going over the interface gets logged.

There is now an issue on github to discuss and perhaps change this behaviour: https://github.com/opnsense/core/issues/4724

A very understandable question.

This is (probably) due to the current filter being applied to interface, but not to the network of that interface.
That means any traffic captured coming or going over the interface gets logged.

There is now an issue on github to discuss and perhaps change this behaviour: https://github.com/opnsense/core/issues/4724

Franco: i updated from the 19.1 series to 19.7.3 and also noticed the cpu load...
which is now almost constantly at 95%, seemingly due to suricata and netflow.
(with suricata often logging Error reading data from iface 'pppoe0': (55u) No buffer space available )

both suricata and netflow were already running on 19.1 where i had, maybe, a 10% load (so the cpu load jumped extremely high, even in low-traffic situations)
i dont know what buffer space would be needed, but there is enough free disk space and memory as well as swap space, so that cannot be an issue.

since turning off suricata and netflow is not an option, i was wondering if it is possible to downgrade back to 19.1?
(i would rather stay on an outdated firewall than to disable functions or use -and thus pay- a lot more electricity, since this is a 24/7 appliance)

i currently kill the involved processes (suricata, netflow, syslog-ng) and then have a relatively stable, normal cpu usage for a while... but it seems to return to high usage after some time for no clear reason

i am happily running my (home install) opnsense off of this board: https://www.gigabyte.com/Motherboard/GA-N3160TN-rev-10#ov

yes, its with realtek nics.
however i can use vlanning and get pretty much my full gigabit speed over the network, so i'm very happy with it.

would it not be better to just use a vpn connection to the firewall?

however, in the way you want is also possible:
add your fqdn in the alias list, and allow that alias (group) as source.

ok guys, i fixed the issue with ntopng.

I remembered a bug/feature discussion about the loopback interface (and renaming it etc because it could be used as an actual interface)

@mimugmail and @franco werent you guys part of that discussion? :)
anyway, since it seemed no service was available on the loopback interface, i decided to go for a guess and went into Firewall: Virtual IPs: Settings and added 127.0.0.1 without gateway as an ip alias on the loopback interface.

dns, ping, and ntopng now function as expected.
maybe an oversight somewhere ?

(i did check on the terminal and lo0 did have 127.0.0.1 assigned already, but i still needed to add it to the virtual ip list for it to actually work)

concerning the ups, it just states the ups is unavailable. seems like a regression of some sorts in the driver.

concerning redis/ntopng, redis starts fine and is running.
ntopng however cannot seem to find it.

Code Select Expand

root@firewall:/usr/local/etc/nut # service redis status
redis is running as pid 161.
root@firewall:/usr/local/etc/nut # service ntopng status
ntopng is not running.
root@firewall:/usr/local/etc/nut # service ntopng start
Starting ntopng.
05/Mar/2019 17:19:34 [Ntop.cpp:1902] Setting local networks to 127.0.0.0/8
05/Mar/2019 17:19:34 [Redis.cpp:111] ERROR: ntopng requires redis server to be up and running
05/Mar/2019 17:19:34 [Redis.cpp:112] ERROR: Please start it and try again or use -r
05/Mar/2019 17:19:34 [Redis.cpp:113] ERROR: to specify a redis server other than the default
root@firewall:/usr/local/etc/nut # sockstat | grep -i redis
redis    redis-serv 161   5  dgram  -> /var/run/log
redis    redis-serv 161   7  tcp4   127.0.0.1:6379        *:*
redis    redis-serv 161   8  tcp6   ::1:6379              *:*
redis    redis-serv 161   9  stream /var/run/redis/redis.sock
root@firewall:/usr/local/etc/nut #


additionally, for some reason, my dns will no longer respond to queries on and from 127.0.0.1 (even though it is running), but will respond to queries to any of the other interface addresses.

Code Select Expand

obody   dnsmasq    61335 14 udp4   10.0.1.1:53           *:*
nobody   dnsmasq    61335 15 tcp4   10.0.1.1:53           *:*
nobody   dnsmasq    61335 16 udp4   127.0.0.1:53          *:*
nobody   dnsmasq    61335 17 tcp4   127.0.0.1:53          *:*


mind you that i commented in this topic, but i am currently running 19.1.2

same here.
i came from 18.7.1 where redis, ntopng, and ups were working as expected, to 19.1.1 and both ntopng and ups are complaining.

now, the ups part is something i find normal due to the small amount of testing it has had (blazer driver), but ntopng is something i dont understand...

redis is started, is listening to localhost, but when trying to start ntopng it mentions that redis needs to be started.

a few (questions/suggestions/remarks) regarding the firewall and the log functionality:

1) is it possible to ignore an interface in the live log without disabling logging on it completely?
=> i have several rules applied to multiple interfaces through the floating ruleset, and there are a few vlans that i dont need in my live log, but where i dont want to make new rules just for those interfaces, to not overcomplicate rule management

2) in that same live log, would it be possible to add an icon for the direction, so we could see if it is coming into or going out of the interface without clicking on the info button?
=> i opened up issue #2804 for this and have a 'proof of concept' code there
EDIT: thanks to AdSchellevis this is now already available in the master, thanks!

3) another item i miss in the live log is the ability to let it resolve hostnames immediately, again having to use the info button to resolve hostnames... yet i thought that this was an existing option somewhere (long ago) in the past?
(there is issue #2287 for this, but i remember it being possible when we still had the 'normal' log, before the live log, or am i mistaken?)

first, personal opinion.... firewall to protect your network, remotely manageable... yikes.

secondly, try a port above 1024  with a forward (maybe your isp blocks low ports)

and last (not sure about this one)... maybe you also need to have a port forward to specify the fact that you want the firewall to respond and not a server behind it. (maybe this can be fixed with destination "this firewall" instead of "wan address" ?)

ok so...

after applying the fix from franco's post AND adding my lan pc's external ip to the virtual ip list on lan it works...

so i expected (just example ips):
externalv6::xxxx translated to fd01::xxx in both ways.
i also expected npt to do this without help.

my lan pc only has the internal fd01:xxxx
outgoing, npt translates this to 2a02::xxxx as expected.
incoming, i need to add that address to the lan interface,
or opnsense will not respond.

i already had the 2a02:: range added to vip but that didnt do the trick...

so its fixed but i assume this is not the right way (because it doesnt scale like this)

only encrypting your dns traffic doesnt make any difference since your isp -if they would choose so- could still find out where you're going on the internet...
so in my opinion, it's a useless act.
if all you want to do is prevent your isp from seeing your dns query, use another resolver with or without encryption, but don't assume your traffic is "safe" from your provider.

everything depends on what you are calling secure, and what your goal is, but if it is to keep your traffic hidden from your isp,
then i'd suggest routing everything through either tor or i2p (and take the performance hit for the increased security)

if just hiding it from your isp, but not caring about digitalocean knowing what you do, you could route all traffic over the vpn.
(which i dont get you're not doing in the first place if you're concerned about your isp snooping on you)

and lastly, if all traffic by default goes out the wan... make sure there's never a rogue application that sends information out over the wan without you knowing (chinese ip cams have a nice habbit of doing this, for example)