Messages

[HA-Proxy version 1.8.5 2018/03/23]

Had to go nuclear on it:

opnsense-bootstrap -r 18.1

Afterwards it went perfect until it reached the haproxy.
It uninstalled the package and did not reinstall it.

I've installed and was bugged with the high cpu usage on haproxy, as described here:

https://github.com/opnsense/plugins/issues/588

Tried to apply the workaround and it did not work as expected:

root@opncluster0101:~ # /usr/local/sbin/haproxy  -v
HA-Proxy version 1.8.5 2018/03/23
Copyright 2000-2018 Willy Tarreau <willy@haproxy.org>

root@opncluster0101:~ # opnsense-revert -r 18.1.2 os-haproxy
Fetching os-haproxy.txz: ... done
Verifying signature with trusted certificate pkg.opnsense.org.20171219... done
os-haproxy-2.6: already unlocked
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
pkg-static: os-haproxy has a missing dependency: haproxy
Checking integrity... done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        os-haproxy: 2.4

Number of packages to be installed: 1
[1/1] Installing os-haproxy-2.4...
Extracting os-haproxy-2.4: 100%
Stopping configd...done
Starting configd.
Keep version OPNsense\HAProxy\HAProxy (2.2.0)
Configuring system logging...done.
Reloading template OPNsense/HAProxy: OK
root@opncluster0101:~ # /usr/local/sbin/haproxy -v
HA-Proxy version 1.8.5 2018/03/23
Copyright 2000-2018 Willy Tarreau <willy@haproxy.org>

Then i also downgraded the haproxy-devel package

# opnsense-revert -r 18.1.2 haproxy-devel
Fetching haproxy-devel.txz: ... done
Verifying signature with trusted certificate pkg.opnsense.org.20171219... done
haproxy-devel-1.8.5: already unlocked
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Checking integrity... done (0 conflicting)
The following 1 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
        haproxy-devel: 1.8.3

Number of packages to be installed: 1

The process will require 3 MiB more space.
[1/1] Installing haproxy-devel-1.8.3...
Extracting haproxy-devel-1.8.3: 100%
root@pfsense01:~ # /usr/local/sbin/haproxy -v
HA-Proxy version 1.8.3-205f675 2017/12/30
Copyright 2000-2017 Willy Tarreau <willy@haproxy.org>



In this version the high cpu usage is no longer showing and everything seams ok now.
Don't forget to lock both packages after the downgrade.

Hello all,

I have been trying to upgrade my opnsense 18.1.5 to the latest version and i keep getting this error:

Checking integrity...Child process pid=13361 terminated abnormally: Bus error

On my system console the error is more detailed:

[HBSD SEGVGUARD] [/usr/local/sbin/pkg-static (12794)] Suspension expired.
-> pid: 12794 ppid: 12349 p_pax: 0x850<SEGVGUARD,ASLR,NODISALLOWMAP32BIT>
pid 13361 (pkg-static), uid 0: exited on signal 10 (core dumped)

I have tried to execute pkg-static upgrade -y and i keep getting a coredump on the process.

I have rebooted the server but the problem remains

Can you please help me?

Thanks,
Nuno

Hello Julien,

Is the difficulty being shown at any speed? Or is only felt when you reach 200mbps?

Thanks!

In my environment I tested it via iperf to a System in another Subnet or over WAN:
Virtio and IPS disabled: ~900Mbit/s
E1000 and IPS disabled: ~200-250Mbit/s
VMXNET3 and IPS disabled: ~500Mbit/s
VMXNET3 and IPS enabled: ~300-400Mbit/s

Grretings,
Fabio

Hello again.

My problem was not the same as yours. My connections simply dropped dead. No even ping would pass.
It appears that is issue on your case is the vCPU of the opnsense appliance is not strong enough to handle all the traffic and IPS at the same time.
Can you add other vCPU's to your vm, and pin them with exclusivity to a physical CPU on the host and re-check?

Thanks

Yes, I have the same issue with E1000 and VirtIO, if IPS is enable -> nothing works!
And of course - I still played with the amount of vCores and with the emulated CPU Type. But it is always the same with E1000 and VirtIO. :(
I am running my Installation currently with VMXNET3, because I don't want to give up IPS...

It is normal a drop in traffic when using IPS. It takes the CPU time to process and validade the data.
It's the same on every IDS/IPS system.

On this case, the usage that suricata does of the netmap driver capability makes it more noticeable.

Hello Julien,

Is the difficulty being shown at any speed? Or is only felt when you reach 200mbps?

Thanks!

In my environment I tested it via iperf to a System in another Subnet or over WAN:
Virtio and IPS disabled: ~900Mbit/s
E1000 and IPS disabled: ~200-250Mbit/s
VMXNET3 and IPS disabled: ~500Mbit/s
VMXNET3 and IPS enabled: ~300-400Mbit/s

Grretings,
Fabio

Hello again.

My problem was not the same as yours. My connections simply dropped dead. No even ping would pass.
It appears that is issue on your case is the vCPU of the opnsense appliance is not strong enough to handle all the traffic and IPS at the same time.
Can you add other vCPU's to your vm, and pin them with exclusivity to a physical CPU on the host and re-check?

Thanks

For me the same
its kills the connections from 1Gbps/s to 200Mbps.
I am on a hardware
hardware offload is disabled but its still killing my connection.

Hello Julien,

Is the difficulty being shown at any speed? Or is only felt when you reach 200mbps?

Thanks!

[on the interface that is going to be using the IPS feature (on my case the WAN)]

Hello all,

I am running my opnsense firewall cluster on two differente versions of KVM/QEMU:

qemu-2.7.0-360
qemu-2.9.0-385

Both of them work pefectly now with IPS and the em0 on the interface that is going to be using the IPS feature (on my case the WAN)

On wich virtualization engine you are having issues?

Thanks!
Nuno

Hello all,

I've been trying to get my netflow working with my Argus accounting server with no luck.
My configuration is as showned on attach1.png

If i look inside the firewall, there is indeed a process that i suspect that is the flow analyser:

# 0:00.01 /usr/local/bin/samplicate -s 127.0.0.1 -p 2055 172.16.0.155/9666

I have checked and there is a very slow of data being put my the firewall on my argus accounting server.
I have other softflow devices that are recording data correctly with this configuration.
The same for radium/argus native client.

One issue that i've found is that usual netflow network packets (at least the kind that i am used to) are much smaller that thoose produced by the netflow engine of opnsense: opn packets - 1506 bytes versus usual packets 120 to 280 bytes.

What am i missing here?

Thanks for your product and your help!

Works beautifully. I recomend (and i think that the documentation recomends it too) that you have a dedicated interface for CARP.
Another recomendations include, using e1000 virtual cards on the interfaces that you will be using IDS with IPS active (suricata) because the virtio cards have an improper implementation / bug of netmap.
Finally (and i dont know if this a bug on the config or my very wierd configuration type) but on the CARP interfaces, you WILL HAVE TO set rules so the config sync mecanism and the CARP mecanism work.
Again i dont know if this should be done automaticly by opnsense, or if something is screwed on my config.

Hi Franco!

Thanks for your quick response. I 've created the issue #1883 on GITHUB.

Thanks,
Nuno

Hello all!

I'm using the HAProxy plugin and I needed to run it inline, in transparent mode.
I have been digging around on the forum and found this past thread:

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

@Franco,

Have you had the time to see the solution presented by Rosu?

Thanks!

I am very interested in this too. Is it possible?

I have changed form the virtio vnic to the e1000 vnic.
It works perfectly now as expected.

Thanks for your help and feedback!

 Hello All.

I've installed the latest version of opnsense and tryed to run suricata.
My HW is a 3 vCore QEMU/KVM (tryed on qemu 2.7 and 2.9) with 2GB of ram and several VIRTIO NICs.

I've pulled the latest rules, and checked if there was updates to be installed.
Both suricata and opnsense are on the latest version.

When i boot suricata in IPS configuration, on the WAN interface, i loose conectivity.
Here's a ping form the firewall to the next hop to demonstrate what appends:

64 bytes from 192.168.1.254: icmp_seq=0 ttl=64 time=1.135 ms
64 bytes from 192.168.1.254: icmp_seq=1 ttl=64 time=0.991 ms
64 bytes from 192.168.1.254: icmp_seq=2 ttl=64 time=0.595 ms
64 bytes from 192.168.1.254: icmp_seq=3 ttl=64 time=0.749 ms
64 bytes from 192.168.1.254: icmp_seq=4 ttl=64 time=0.828 ms
64 bytes from 192.168.1.254: icmp_seq=5 ttl=64 time=0.803 ms
64 bytes from 192.168.1.254: icmp_seq=6 ttl=64 time=0.766 ms
64 bytes from 192.168.1.254: icmp_seq=7 ttl=64 time=68606.310 ms < Suricata boot
64 bytes from 192.168.1.254: icmp_seq=8 ttl=64 time=68300.215 ms
64 bytes from 192.168.1.254: icmp_seq=10 ttl=64 time=67848.197 ms
64 bytes from 192.168.1.254: icmp_seq=14 ttl=64 time=68108.471 ms
64 bytes from 192.168.1.254: icmp_seq=17 ttl=64 time=67052.875 ms
64 bytes from 192.168.1.254: icmp_seq=18 ttl=64 time=67528.361 ms
64 bytes from 192.168.1.254: icmp_seq=19 ttl=64 time=68002.670 ms
64 bytes from 192.168.1.254: icmp_seq=22 ttl=64 time=67999.273 ms
64 bytes from 192.168.1.254: icmp_seq=23 ttl=64 time=67995.854 ms

There are NO rules loaded for this test, I just started the daemon.

If i stop the IPS mode (active defense) it goes back to normal:

64 bytes from 192.168.1.254: icmp_seq=10 ttl=64 time=38098.266 ms
64 bytes from 192.168.1.254: icmp_seq=15 ttl=64 time=36568.727 ms
64 bytes from 192.168.1.254: icmp_seq=16 ttl=64 time=36987.789 ms
64 bytes from 192.168.1.254: icmp_seq=20 ttl=64 time=37390.267 ms
64 bytes from 192.168.1.254: icmp_seq=21 ttl=64 time=36703.024 ms
64 bytes from 192.168.1.254: icmp_seq=24 ttl=64 time=36385.351 ms
64 bytes from 192.168.1.254: icmp_seq=26 ttl=64 time=51639.619 ms
64 bytes from 192.168.1.254: icmp_seq=27 ttl=64 time=52612.838 ms
64 bytes from 192.168.1.254: icmp_seq=29 ttl=64 time=51815.528 ms
64 bytes from 192.168.1.254: icmp_seq=30 ttl=64 time=51632.411 ms
64 bytes from 192.168.1.254: icmp_seq=32 ttl=64 time=50433.146 ms
64 bytes from 192.168.1.254: icmp_seq=85 ttl=64 time=0.504 ms
64 bytes from 192.168.1.254: icmp_seq=86 ttl=64 time=0.473 ms
64 bytes from 192.168.1.254: icmp_seq=87 ttl=64 time=0.462 ms
64 bytes from 192.168.1.254: icmp_seq=88 ttl=64 time=0.404 ms
64 bytes from 192.168.1.254: icmp_seq=89 ttl=64 time=0.502 ms
64 bytes from 192.168.1.254: icmp_seq=90 ttl=64 time=0.444 ms
64 bytes from 192.168.1.254: icmp_seq=91 ttl=64 time=0.474 ms

Am i missing something or is this a bug?
I need the IPS active to do active defense on my system?
Or can it be run with active defence on legacy configuration thru pcap thus being only and IDS and not a IPS?

Thanks,
Nuno