OPNsense teszt

FreeBSD

OPNsense teszt

Az OPNsense egy pfSense fork. Fejlesztői számos dolgot máshogy akarnak csinálni, mint a szülőprojekt. A pfSense-t jól ismerem, hosszú évek óta használom. Viszont kíváncsi voltam az OPNsense-re is, ezért úgy döntöttem, hogy teszek vele egy próbát. A hardver adott volt: a korábban már ismertetett APU.2C2 alaplap. A változás mindössze annyi, hogy az SD kártya helyett az adattárolásért ezúttal egy 16 GB-os mSATA SSD felelt.

( lmarton | 2017. 03. 27., h – 22:17 )

Mar vartam mikor probalod ki...
Amikor a multkor posztoltal rola akkor en mar felpakoltam az APU2-mre, de kb fel nap bokoeds utan ment is a kukaba... Doksi majdnem nulla hozza, fejlesztok ugy ereztem inkabb arcoskodnak mint fijlesztenek es ami feature set volt benne az is helyenkent bugos... Ugy gondoltam egy tuzfalnal ne mar a csilivilli interfesz legyen a legfontosabb... Maradt a PFSense nalam is...

"Opnsense is just a PR stunt for a company called Deciso. For the past few months since opnsense release, their developers openly lied against and attacked pfSense developers (check their twitter), which was totally unprofessional and not so "community" like behavior. What's worse, pfSense guys HELPED opnsense devs fix their own shit work."

Több helyen is olvastam, hogy az OPNsense fejlesztője (vagy fejlesztői) annyit csináltak csak, hogy rebrandeltél a pfSense-t, illetve új alapokra helyezték a webes felületet. Ezen kívül érdemi munkájuk nincs benne. Viszont ezzel egy csomó új bug is érkezett. Az új funkciók pedig vagy nem vagy csak ritkán működnek. Azt hiszem, hogy semmi olyat nem nyújt, ami miatt a sok-sok éve jól teljesítő pfSense-t el kellene vagy el lenne érdemes hagyni.

--
trey @ gépház

A legnagyobb ígéretük egy normális REST API lenne. A Pfsense-vel is az a baj ,hogy nincs API. Néhány tucat fw-nél nem hátrány ha a default szabályrendszert usereket log beállítást stb egy ansible role-val lehet teríteni egyszerűen. Persze lehet trükközni az xml-el itt is de inkább nem. Úgyhogy inkább VYOS.

Egy ideig hasznaltunk Pfsense-et, nekem kicsit az API hianyzott, de meg jobban a changelog. Nem lehetett semmilyen modon megnezni, hogy mi valtozott a configban az elmult 1 hetben. Na jo, meg lehetett, az egesz config egy marhanagy XML-ben volt, azt diffelhetted.... A masik kedvencem az volt, mikor valaki valtoztatott valamit, de nem apply-olta, te beleptel az oldalra egy het mulva es feldobta, hogy "na akkor most akarod alkalmazni a valtozasokat?", de hogy mi a valtozas azt nem tudta megmondani. :)

PFSense: 


op@blackbird:~/work/hardenedbsd/hardenedBSD.git$ git shortlog --grep pfsense origin/freebsd/current/master 
bz (1):
      Remove the static from int hardlink_check_uid. There is an external use in the opensolaris code.

garga (2):
      When passwd or group information is changed (by pw, vipw, chpass, ...) temporary file is created and then a rename() call move it to official file. This operation didn't have any check to make sure data was written to disk and if a power cycle happens system could end up with a 0 length passwd or group database.
      MFC r285050, r285053, r285059:

hselasky (1):
      Add new USB ID to UDAV driver.

loos (3):
      Remove the check that prevent carp(4) advskew to be set to '0'.
      MFC r276751:
      Fix the parsing of NPt binat rules.

mlaier (3):
      Resolve conflicts created during the import of pf 3.7 Some features are missing and will be implemented in a second step.  This is functional as is.
      Resolve conflicts created during the import of pf 3.7 Some features are missing and will be implemented in a second step.  This is functional as is.
      If we cannot immediately get the pf_consistency_lock in the purge thread, restart the scan after acquiring the lock the hard way.  Otherwise we might end up with a dead reference.

OPNSense: 


op@blackbird:~/work/hardenedbsd/hardenedBSD.git$ git shortlog --grep opnsense origin/freebsd/current/master 
glebius (2):
      Don't dereference NULL is pf_get_mtag() fails.
      A miss from r283061: don't dereference NULL is pf_get_mtag() fails.

hselasky (1):
      MFC r292254:

kp (1):
      pf: remove fastroute tag

markj (1):
      rtsold: Log messages about unexpected RAs at LOG_DEBUG.

sbruno (4):
      r293331 mistakingly failed to add an assignment of paddr to the rxbuf but only in the NETMAP code.  This lead to the NETMAP code paths passing nothing up to userland.
      The buffer address is always overwritten in the extended descriptor format, we have to refresh it ... always.  This fixes problems reported in NetMap with em(4) devices after conversion to extended descriptor format in svn r293331.
      Restore r302384 that was dropped when r303816 updated the driver to 1.6.6.-k
      Reset the EIAC register to include the LINK status bit and restore link up/down notifications.

( Kronosz v | 2017. 03. 28., k – 12:34 )

Pfsense-ben milyen funkciókat használtok? (mailscanner nevű csodát használjátok?)

Alap dolgokat főként. NAT, Portforward, PPTP, IPsec, OpenVPN. Mikor hol mit kíván a feladat. pfSense-t jellemzően olyan helyen használjuk, ahol

a) virtuális gépben kell tűzfalat adni
b) ahol igény van a 10-20 ezer forintos SOHO routernél jobb (megbízhatóbb) megoldásra, de ugyanakkor sajnálják a pénzt a 200+ ezer forintnál kezdődő nagyobb nevű hardveres vagy virtual appliance UTM megoldásokra

Ahol kell spam, mailscanner stb. védelem, oda mást használunk (Stormshield).

--
trey @ gépház

T-s felhasználóként használtam még mielőtt megkaptam a most használt Speedport-ot, akkor nagyjából ezeket használtam én is. A volt munkahelyemen meg szenvedtem a mailscannerrel, szóval azt fel se tettem.
Megvoltam vele elégedve, bár többet evett akkoriban, mint a mostani modem-router kombó (kis fogyasztású PC-n használtam). :)

( fairlane | 2017. 03. 28., k – 14:35 )

Köszi a tesztet, sokat segített a döntésben.
(APU2C4 lesz, pfSense-sel)

--------------------------------
...úgyis jönnek...

( vadonka | 2017. 04. 24., h – 09:53 )

Mi használunk pfsense-t és opnsense-t is. Van k 40 pfsense a kezem alatt (virtuális gép és fizikai vas egyaránt) és úgy 20 opnsense (de folyamatosan állunk át)
A pfsense egy súlyos hibája amit több mint fél éve nem bírnak javítani, hogy bizonyos konfiggal kernel pánik van napi szinten. A VM resetel de a fizikai vas szétfagy és táp kihúz bedug. Ez egy olyan helyen ahol a tűzfal magasan van rossz helyen nehézkes, főleg ha a helyi hülyéket kell erre megkérni. Naponta azért gáz. Nem tudni mi okozza, szűz konfiggal nem, de ha már picit bonyibb dolgok vannak benne csinálja. Ismert bug, de nem bírnak rájönni az okára. A másik gond, hogy az eredeti csapat jórésze lelécelt tőlük. Köztük az alapítók is. Nagyon nem tetszett sokaknak, hogy a profitszerzés felé mozdult el a projekt. A jobb fejlesztők sorban pártoltoltak át az opnsense-hez illetve más csapatokhoz. A pfsense jelenleg erősen ember hiánnyal küzd, nem véletlen, hogy csak hotfixek vannak jó ideje.
Az opnsense egy már több éves projekt, szóval nem nevezném ismeretlennek. Nagy előnye, hogy pl. támogatja a natív geoip-t aliasban és szabályokban, nem kell azt a használhatatlan pfblockert használni. URL táblákat is kezel dinamikusan aliasként, a pfsense-ben ez nem működik rendesen. Már jó ideje saját projekt az egész, szinte semmilyen szinten nem használnak már semmit a pfsense-ből. A beépített IDP/IPS is sokkal jobban működik mint amit a pfsense-ben a snort-al vagy suricata-val össze lehet tákolni. Gyengébb vason lényegesen jobban fut, pl. a jó öreg alix lapokon a 800mhz-es amd procival. Még egy nagy plusz pont az opnsense mellett, hogy támogatja a libressl-t ami szerintem már az openssl-t lenyomja lazán.
A pfsense egyetlen előnye az a sok opcionálisan telepíthető csomag ami van hozzá.
Éveken át használtuk a pfsense-t, és már legalább másfél éve az opnsense-t is. Van összehasonlítási alapom, a legkritikusabb dolog a kernel pánik ami egy súlyos hiba. Az, hogy weben a gui-n enged kattintgatni úgy, hogy kernel pánikot okozó konfigot hozz össze az nagy gáz. Tehát semmi parancssori mókolás nincs mögötte.
Jelenleg folyamatosan állunk át, sajnos a két konfig véletlen sem ugyanaz csak töredékek belőle. Szóval nagyon kézi munka a pfsense szabályok átvitele opnsense-be. Annyira nem bírja egymást a két csapat, hogy ez egy szándékos húzás volt.

Én most tervezem egy célhw vásárlását (SG-2440) és meglepően olvasom a kernel panic hibákat.
Tudnál erről részletesebben írni? Milyen speciális konfiggal fordul elő ez a jelenség?

Lehet, hogy OpnSense-t kellene vásárolnom...
Találkoztál azokkal a GUI-s bugokkal, melyeket trey említett?

( 1984white | 2018. 01. 05., p – 08:41 )

Üdv!

Nektek sikerült összehozni az ssl proxyt az opnsense-el? ( legújabb stabil verzió használok)
Nálam az a gond, hogy akármit beírok a "nobump" kivételhez az nem jut érvényre.
Maga az sslproxy tökéletes, de kellenek kivátelek, ahol nem akarok MITM-et. ( pl banki oldalak, stb)
Előbb az volt a gond, hogy "," kell elválasztani a bejegyzéseket, de a jel használatával sem jó.

A hiba amit kapok kivétel esetén: SSL Record maximum length .....
Működik ez másnak, vagy ez egy bug?
Mit nem tudok? :)

Köszönöm a választ!
Üdvözlettel!

( MrSealRD v | 2018. 03. 10., szo – 10:30 )

Így közel 1 évvel a post után kíváncsi lennék a tapasztalatokra. Akár másoktól is. Most kísérletezési célból pfSense van fent. Hogy áll a két projekt egymáshoz képest? Van esetleg más alternatíva ami szóba jöhet és érdemes mérlegelni?

Szia,

csak a tapasztalataimról tudok nyilatkozni, ami a pfSense-re korlátozódik, mivel az van a vason.
Közel egy éve megvan, a számomra szükséges dolgokat (OpenVPN, DDNS támogatás) feltelepítettem, NAT, FW szabályok beállítva és működik.
Néha ránézek, eddig egy frissítés jött ki, az is pár kattintással és egy reboot-tal lefutott.

Nincs széthajtva, egyszerűen teszi a dolgát. :)

--------------------------------
...úgyis jönnek...

DDNS, NAT, FW szabályokkal kapcsolatban tudsz segíteni? Mit érdemes ezeknél beállítani. Egyelőre default beállításokkal vagyok. Próbáltam keresgélni ajánlásokat, de igazából a pfsense anyagai elég zártak, viszonylag kevés YT és egyéb oldal van ami segít a biztonságos beállításokban.

( ricsip v | 2018. 06. 27., sze – 13:39 )

iperf szerint csak 6-700 mbit-et bír factory default konfiggal (Opnsense 18.1, iperf server WAN, iperf client LAN interface-re kötve).
A 2 gép layer2-ben bírja a 940 mbit-et.
--

Közben meglett a válasz:

https://teklager.se/en/knowledge-base/apu2c0-ipfire-throughput-test-muc…

"BSD-based operating systems such as pfSense use single CPU core for routing. Linux based systems are spreading the routing load between CPU cores.

APU routers have 4 CPU cores. IPFire is able to use all of them for routing, while pfSense is using just one."

Ha ez így van, az elég ciki a freeBSD-re nézve. Elvégre az "A" network operating system, nem a Linux / Windows.
--

( Proci85 v | 2019. 11. 28., cs – 09:27 )

Sziasztok!

Most felmerült az igény egy pfsense beállítására. Továbbra is érdemes inkább opnsense-t hadrendbe álítani?

Eddig mindig RouterOS-t futtattam VM-ben, de elég sok CVE jön hozzá, legyen akkor linux+iptables. Wines kollégák kevésbé szeretik. Így lenne GUI-s tűzfal. Jelenlegi feladatra egyszerű layer 4 tűzfal kell, bevédeni a windowst net oldalról. VM-ben futna mindkettő.