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 - mw01

#1
Root.

R/
Mike
#2
Yes sir. 

I currently have no events are coming in.  There are 14 events that display nicely in Plain View.  In Live View the log bars are wide - 2 log entries --> Lobby through Help (collapsed) with just interface and time.  With Firefox these events are displayed OK but twice.  There are 12 log entries --> Lobby through Help.  The 1st 14 followed by the 1st 11 = 25 lines. 
#3
The 18.1.2 update was flawless and openvpn works great.  However, observed openvpn inactivity timeout + auth failed after about half a day or so since 18, whick requires a manual restart (just a click).  It's hard to tell if it is the result 18 or something going on with PIA.  Does anyone else have a similar experience?  I have:

persist-key
persist-tun
remote-cert-tls server
reneg-sec 0
#4
18.1 Legacy Series / Re: OpenVPN Broken
February 06, 2018, 01:36:49 AM
Well done.  Patch works.  Defined static addresses for VPN traffic on VLANS.
#5
18.1 Legacy Series / Re: OpenVPN Broken
February 04, 2018, 02:39:38 AM
I seem to recall the NAT Outbound NAT Address was something else than Interface Address.  Wasn't it OpenVPN address and the WAN was WAN address?  Now they are both Interface Address, which makes sense.

I have something similar in /tmp/rules.debug

nat on igb1 from 192.168.1.0/24 to any port 500 -> igb1 static-port # Auto created rule for ISAKMP - OPT1 -> WAN
# nat on openvpn inet from 192.168.1.0/24 to any port 500 static-port # ISAKMP - OPT1 -> WAN_VPN4
nat on igb1 from 192.168.1.0/24 to any -> igb1 port 1024:65535 # Auto created rule - OPT1 -> WAN
# nat on openvpn inet from 192.168.1.0/24 to any port 1024:65535 # OPT1 -> WAN_VPN4
#6
The upgrade from 17.7.12 to 18.1.1, apu2, was flawless. 

While testing noted the firewall logs Live View does not display correctly with google chrome 64.0.3282.140 64-bit.  The display update of each row takes seconds, the interface and time display correctly, the rest of the text is not properly decoded (square), and apu2 cpu goes up 40% cpu.  The display decodes on Firefox ESR and with the same apu cpu loading but two events are displayed 4 times.
#7
Thank you.

No issues after a day.  apu2, AMD GX-412TC SOC (4 cores), nano.
#8
Thank you.  Patch works.
#9
17.7 Legacy Series / Re: Great Work!
September 02, 2017, 12:43:21 AM
Great work!  Seamless upgrade - suricata and openvpn (clients by ip).
#10
~90Mbs, depending on time of day (with the "optimal" server at the other end). 

Suricata is not the limiting factor.  It's the ISP pipe.  I have not performed testing with a Gb WAN connection.  If I extrapolate cpu loading I might see another 30Mbps or so.

Suricata loading is also a function of the rule set.  The more you check the more the loading.

#11
Yes, I have conducted bandwidth tests.  I am still limited by ISP provisioning (~90Mbs).  What I have observed is lower cpu utilization with 4.0.0.
#12
17.7 Legacy Series / Suricata Rule Parsing Errors
August 27, 2017, 04:09:38 PM
We have been "testing" Suricata 4.0 and it works well.  Today, I was checking into TLS wrong version errors (daughter on facebook, andriod cell) and checked the logs.  There are parsing errors from abuse.ch.  For example, IDS Rules Apply, clog suricata.log | less first error:

27/8/2017 -- 09:32:29 - <Notice> - rule reload starting
27/8/2017 -- 09:32:35 - <Error> - [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "^_<8B>^H" from file /usr/local/etc/suricata/opnsense.rules/abuse.ch.sslblacklist.rules at line 1

I recall, not all that long ago the ET ruleset parsing changed.
#13
Upgraded from 17.1.11 to 17.7 and Suricata 4.0.0.  Went smoothly, no issues.  apu2 AMD GX-412TC SOC (4 cores)
#14
Thank you. 

What caught my eye was the change on the syslog aggregator - what is normal.  There is a configd.py-log file that contains the daemon start message and the request pfctl byte/packet counters went to the ip-log file.

Logging is good.  Please use your best judgement (as always).   :)
#15
Update from 17.1.9 to 17.1.10-amd64 went well.  Noted open Dashboard causes endless logging of configd.py: [ ] request pfctl byte/packet counters, which is a change.

Turns out the periodic updates of the Interface List are now logged.