Mivel a célhardveren nincs VGA kimenet, a telepítést soros porton keresztül végeztem el. Szerencsére a pfSense-hez hasonlóan az OPNsense is támogatja ezt a telepítési metódust. A megfelelő telepítő image letölthető innen:
|
Kibontjuk, majd egy USB-s pendrive-ra írjuk:
|
Ha ez megvan, dugjuk fel az elkészített pendrive-ot az eszközre, majd lőjük be a soros porti kommunikációt a gépünk és az eszköz közt. Ha sikerült, akkor bootolhatunk. A megfelelő terminál kliensünkkel a következőket láthatjuk:
|
Az "1." menüpontot választva elindul az OPNsense telepítője a pendrive-ról:
|
A telepítés elindításához jelentkezzünk be "installer" felhasználóval. A jelszó: opnsense
|
Ha kész a telepítés, jöhet a reboot:
|
Immár a "lemezről" bootolva bejelentkezhetünk és szétnézhetünk a parancssori menüben:
|
Ezen a ponton már él a webes konfigurációs felület is:
Bejelentkezés után indul a "varázsló"
A telepítés és az alapbeállítás elkészült.
Az OPNsense a teszt alatt gyakorlatilag ugyanazt nyújtotta, amit a pfSense, annyi különbséggel, hogy egy újabbnak ható, modernebb webes felületet kínált. Sajnos azonban az új felületen több bugba is belefutottam. Felmerült bennem a kérdés, hogy miért válasszam az OPNsense-t a pfSense helyett? A kérdésre válaszokat keresve arra jutottam, hogy nincs semmi okom arra, hogy a régi, jól bevált pfSense-t lecseréljem az újabb, ám ismeretlen OPNsense-re...
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
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...
- A hozzászóláshoz be kell jelentkezni
Ezt futottam végig:
https://www.reddit.com/r/PFSENSE/comments/35dl17/pfsense_vs_opnsense_ar…
Túl sok jót nem láttam az OPNsense-ről.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Koszi a bemutatot az eszkozrol.
Az Opensense megtetszett es a fejleszteseikkel is jol haladtak, de tenyleg nem javasolt a hasznalata? Sok baj lehet vele?
- A hozzászóláshoz be kell jelentkezni
"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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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. :)
- A hozzászóláshoz be kell jelentkezni
És még tegyük hozzá,hogy azért jót tett a fork a pfsense-nek is ,mivel előtte erősen kezdtek elmenni a rossz irányba. pl a publikus forrás nem volt fordítható stb stb. Azóta van rendes github tároló meg átláthatóság.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
A reddit oldalhoz meg a hatter info, hogy a moderatorok ott csak pfsense-hez kotheto emberek. ;)
- A hozzászóláshoz be kell jelentkezni
Pfsense-ben milyen funkciókat használtok? (mailscanner nevű csodát használjátok?)
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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). :)
- A hozzászóláshoz be kell jelentkezni
Nekünk sophos utm hw van, de csak az email szűrést végzi, a tűzfala nem tetszett. szerintem a pf/opnsense jobb tűzfal. Néztem már pár hw tűzfalat de mindegyikkel volt prücök.
Talán a juniper ami jó lenne, de az meg arany áron van mérve.
- A hozzászóláshoz be kell jelentkezni
Köszi a tesztet, sokat segített a döntésben.
(APU2C4 lesz, pfSense-sel)
--------------------------------
...úgyis jönnek...
- A hozzászóláshoz be kell jelentkezni
Frankó meg minden, de a doboza lehetne más anyagból, mert ha megfogod, az összes ujjlenyomatod rajta lesz (lásd kép fent). Leszedni meg marha nehéz. :( Ettől eltekintve teljesen korrekt.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
É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?
- A hozzászóláshoz be kell jelentkezni
Ü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!
- A hozzászóláshoz be kell jelentkezni
Í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?
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Ezeket nézted már?
https://forum.pfsense.org/index.php?topic=128030.0
https://forum.pfsense.org/index.php?topic=4799.0
https://forum.pfsense.org/index.php?topic=128373.0
https://forum.pfsense.org/index.php?topic=84004.0
https://sweetcode.io/secure-your-network-with-pfsense-firewall/
- A hozzászóláshoz be kell jelentkezni
Még nem. De megnézem, köszi. (Bár átálltam OPNSense-re, de ott is jó lesz...)
- A hozzászóláshoz be kell jelentkezni
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.
--
- A hozzászóláshoz be kell jelentkezni
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.
--
- A hozzászóláshoz be kell jelentkezni
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ő.
- A hozzászóláshoz be kell jelentkezni