Tee-se-itse: Rautapalomuurit (pfSense, Sophos UTM..) (Mitä käytätte ja miksi juuri se vaihtoehto?)

[antero]

Jos ei nuo tikulta bootaukset onnistu kannatta kokeilla myös eri tikkua. Kaikki uudet tikut on aika myrkkyä boottauksille, alle 32GB tikulla kaikki sujuu.

 

[Enhancer]

Onko kenelläkään Multi-Wan käytössä OPNsensen kanssa?

Jätin omassa rakentelussa vähän myöhemmäksi tuon käyttöönoton, ja tuohan vaikuttaa olevan ihan perseestä. Käyttöönotossa jokaiselle WAN:lle pitää määrittää oma julkinen salaamaton DNS-palvelin, joita purkki käyttää kun ko. yhteys vaihtuu käyttöön. Yhden wanin kanssa sain jo mukavasti otettua käyttöön omassa virtuaalikoneessaan pyörivän AdGuard Homen, mutta ei sinne ohjaukset toimi oikein kun on käytössä useampi WAN.

Harkitsin jo, että teen jokaisesta WAN:sta oman OPNsense -virtuaalikoneensa, josta salattu DNS -yhteys ulkomaailmaan, ja sitten kaikki Proxmoxin sisällä yhteen koneeseen joka hanskaa Multi-WAN ja reitityksen. Tarpeettoman vaikeaksi toki tuokin menee.

Ajatus on, että hallintaverkko pysyy omanaan ja sillä oma AdGuard -palvelimensa, ja 3 muuta VLAN:a joilla omansa + tietenkin muurisäännöt joilla määritellään pääsyt.

Voisiko tämän homman hoitaa muurisäännöillä, jossa kaikki gateway-ryhmään muurilta ulos lähtevä portin 53 salaamaton DNS-liikenne reititettäisiin sisäverkon DNS-palvelimelle, paitsi kyseisen DNS-palvelimen liikenne sallittaisiin ulos gateway-ryhmän kautta?

Tällöin AdGuard voisi tarpeen tullen pyytää DoH -osoitteen määritellyllä salaamattomalta palvelimelta loopin välttämiseksi.

 

[Enhancer]

Voisiko tämän homman hoitaa muurisäännöillä, jossa kaikki gateway-ryhmään muurilta ulos lähtevä portin 53 salaamaton DNS-liikenne reititettäisiin sisäverkon DNS-palvelimelle, paitsi kyseisen DNS-palvelimen liikenne sallittaisiin ulos gateway-ryhmän kautta?

Tällöin AdGuard voisi tarpeen tullen pyytää DoH -osoitteen määritellyllä salaamattomalta palvelimelta loopin välttämiseksi.

Päädyin ottamaan askeleen taaksepäin, kiitos kuka keksitkään Proxmoxin snapshotit. Palasin ensin yhdellä WAN:lla korjaamaan DNS-reititykset.

Testasin paria vaihtoehtoa, lopulta päädyin ottamaan OPNsensen oman natiivin DoT -tuen käyttöön muurin omia kyselyjä varten, tänne putkelle ohjautuu myös AdGuard 1 kyselyt.

Muurisääntö ohjaa muut lähiverkosta tulevat 53 portin kyselyt AdGuard 1:lle. Pientä lomittaisuutta, mutta näin mitään DNS-kyselyitä ei lähde selkokielisinä, kovakoodatut DoT/DoH -kyselyt estetään ja liikenne NextDNS:n on sallittu kaikilta verkkotasoilta jotta myös mobiiliyhteyksin varustetut laitteet joissa pyörii NextDNS laitetasolla toimivat oikein.

AdGuardit 2-4 odottavat valmiina palvelemaan IoT-laitteita, lasten laitteita ja vieras/pilvilaitteita kukin omalla NextDNS -profiilillaan varustettuna.

Huomenna sitten uusi aloitus myös useamman WAN:n kanssa, on vähän helpompi etsiä siitä viat kun pohja on kunnossa.

 

[mikajh]

pfSense Plus 23.09 -asennus (joka on toinen jalka haudassa) päätti satunnaisen konfiguraatiomuutoksen takia jumittua täysin (vaati PC-raudan reset-nappia), ja bootin jälkeen toiminta oli aika heikkoa, syynä että tämä file oli nollan pituinen:
-rw-r--r-- 1 root wheel 500619 Jan 13 09:35 /cf/conf/config.xml

Onneksi automaattisia backuppeja oli käytettävissä (/cf/conf/backup). Että semmosta, note to self: alapa kasata jotain uutta.

 

[sra2010]

pfSense Plus 23.09 -asennus (joka on toinen jalka haudassa) päätti satunnaisen konfiguraatiomuutoksen takia jumittua täysin (vaati PC-raudan reset-nappia), ja bootin jälkeen toiminta oli aika heikkoa, syynä että tämä file oli nollan pituinen:
-rw-r--r-- 1 root wheel 500619 Jan 13 09:35 /cf/conf/config.xml

Onneksi automaattisia backuppeja oli käytettävissä (/cf/conf/backup). Että semmosta, note to self: alapa kasata jotain uutta.

Mikä tuohon on syynä, rautavika?

 

[mikajh]

Mikä tuohon on syynä, rautavika?

Voi olla, vaikka SSD. Jumittuu kesken bootin ja on todellisessa limp-moodissa. Web-console kuoleentuu jos lähtee käyntiin, samoin ssh. Reititys toimii, dhcp ei oikein jne. SMART-tietoja olisi kiva vilkaista, mutta se ei oikein nyt onnistu

E: Myöskään ulkoa tulevat yhteydet eivät näytä forwardoituvan

 

[sra2010]

Voi olla, vaikka SSD. Jumittuu kesken bootin ja on todellisessa limp-moodissa. Web-console kuoleentuu jos lähtee käyntiin, samoin ssh. Reititys toimii, dhcp ei oikein jne. SMART-tietoja olisi kiva vilkaista, mutta se ei oikein nyt onnistu

E: Myöskään ulkoa tulevat yhteydet eivät näytä forwardoituvan

Jep, jotain tuollaista epäilisin, voi olla kaapeli vikakin jos on sata kaapelilla kiinni. Jollakin linux live tikulla varmaan sais käyntiin ja pääsis katsoon smart tiedot jos jaksaa harrastaa.

 

[Enhancer]

Päädyin ottamaan askeleen taaksepäin, kiitos kuka keksitkään Proxmoxin snapshotit. Palasin ensin yhdellä WAN:lla korjaamaan DNS-reititykset.

Testasin paria vaihtoehtoa, lopulta päädyin ottamaan OPNsensen oman natiivin DoT -tuen käyttöön muurin omia kyselyjä varten, tänne putkelle ohjautuu myös AdGuard 1 kyselyt.

Muurisääntö ohjaa muut lähiverkosta tulevat 53 portin kyselyt AdGuard 1:lle. Pientä lomittaisuutta, mutta näin mitään DNS-kyselyitä ei lähde selkokielisinä, kovakoodatut DoT/DoH -kyselyt estetään ja liikenne NextDNS:n on sallittu kaikilta verkkotasoilta jotta myös mobiiliyhteyksin varustetut laitteet joissa pyörii NextDNS laitetasolla toimivat oikein.

AdGuardit 2-4 odottavat valmiina palvelemaan IoT-laitteita, lasten laitteita ja vieras/pilvilaitteita kukin omalla NextDNS -profiilillaan varustettuna.

Huomenna sitten uusi aloitus myös useamman WAN:n kanssa, on vähän helpompi etsiä siitä viat kun pohja on kunnossa.

Aiemmin päivällä kaikki tuntui menevän kuin vettä vaan. Tein Multi-WAN -käyttöönoton kuten OPNsensen dokumentaatio ohjeistaa, sillä poikkeuksella että jätin gateway-kohtaiset DNS-palvelimet laittamatta. Homma toimi, unbound hoiti paikalliset kyselyt ja AdGuard loput välittämättä WAN:sta. Nyt illalla pienen tauon jälkeen sama toistui kuin aiemmin, yhtäkkiä kaikki liikenne pysähtyi puoleksi minuutiksi. Kesken Speedtestin tällä kertaa.

Törmäsin eilen bugiraporttiin, jossa Multi-WAN ongelmat korjaantuivat ottamalla pois käytöstä Firewall - Settings - Advanced oletuksena päällä oleva asetus ”Shared forwarding”. Näin tein, ja näytti ratkaisevan ongelman. Testataan lisää ennen seuraavia askeleita.

 

[mikajh]

Tämä on syytä katsoa tarkasti, jos tuota vanhaa ja toimivaa DynDNS-plugaria on käyttänyt. Kun viimeksi katsoin, niin se uusi virallisesti tuettu oli ihan **ska, eikä sillä voinut korvata niitä custom-käyttöjä mitä itsellä on

OPNsense 23.7:n os-ddclient 1.16_2 ainakin sisältää nyt sellaisen custom-toiminnallisuuden, millä dy.fi-päivityksen saa toimimaan. Nähtäväksi vielä jää, miten päivityksen saa toistumaan vähintään 7 päivän välein, vaikka osoite ei muutu

 

[Rensu]

OPNsense 23.7:n os-ddclient 1.16_2 ainakin sisältää nyt sellaisen custom-toiminnallisuuden, millä dy.fi-päivityksen saa toimimaan. Nähtäväksi vielä jää, miten päivityksen saa toistumaan vähintään 7 päivän välein, vaikka osoite ei muutu

OPNsensen cron command listalta löytyy suoraan "Force ddclient update". Itellä on se ajossa parina yönä viikossa ja tuntuu pelaavan hyvin.

 

[Enhancer]

Lopulta laitoin Quad9 4 eri IP-osoitetta Multi-WAN -konffiin sekä monitorointiosoitteiksi että myös gateway-kohtaisiksi. Unbound ottaa nuo kyselyt kiinni, ja kääntää ne ihan oikein DoT -määrityksensä mukaisesti NextDNS:lle. Homma toimii mukavasti, vihdoin.

Seuraavaksi aika laittaa älyä kehiin. Monet käyttävät ilmeisestikin Suricataa WAN-puolella ottamassa kiinni muurista ulos päätyvää tavaraa, ja Zenarmoria sitten seuraamassa muurin sisäistä LAN-puolen liikennettä.

Onko näistä kokemuksia? Muistia ja prosessoritehoa on tarpeeksi. ET Pro vaikutti Suricataan mielenkiintoiselta setiltä, sen kotiin soittavan version saisi varsin harmittomin datanluovutuksin ilmaiseksi. Ajattelen näin, että näin Venäjän naapurissa kiusa se on pienikin jos jotakin koputtelua saa dataa luovuttamalla päätymään blokkilistoille .

 

[BennyH]

Käyttääkö täällä kukaan Opnsensen kanssa Unboundia siten, että Unboundiin on konffattu estolistoja?

Mihin conf-hakemistoon ja .conf-tiedostoihin estolistojen konffaus tallentuu?

Ja olisiko mahdollista saada lyhyt esimerkki em. .conf-tiedostojen estolistaa koskevista osista.

Tiedän Opnsensen käyttöliittymästä löytyvän blocklist-valikon, mutta nyt kiinnostaa miten lisätään estolistat Unbondiin komentorivin kautta, kun käytössä on Pihole & Unbound.
Kyse siis nimenomaan Unboundin estolista eikä Piholen estolista.

Oletuksena itselläni on, että Opnsense ja Pihole käyttävät samaa Unbound-softaa rekursiivisena DNS-resolverina.

 

[Grazer]

Saapui tuo vanhemmille tilaamani HP T730 Thinclient. Lisäsin PCI-E-paikkaan verkkokortin ja asentelin IPFiren.

Bios oli vuodelta 2015, niin sen päivittelin. HP:n sivuilla jaossa olevaa 00.01.16 Rev.A -versiosta en saanut päivitettyä, kun tuon mukana tullut usb recovery -tikun installeri ei vaan suostunut käynnistymään, mutta tuolta löytyi pykälää vanhempi 00.01.15 bios, jolla homma onnistui Reddit - Dive into anything

 

[Enhancer]

Kumpaa lähestymistä käytätte muurisääntöjen ulosmenevässä liikenteessä?

Kaikki estoon ja sallitaan tarvittavat, vai esim. OPNsensen oletus sallitaan kaikki ja estoja tarpeen mukaan?

Aika vähän lopulta tarvitsisi sallia, 80 ja 443 jos esim. DNS ja NTP -liikenne käännetään omille sisäisille palvelimille jne.

 

[Wilmo]

Kumpaa lähestymistä käytätte muurisääntöjen ulosmenevässä liikenteessä?

Kaikki estoon ja sallitaan tarvittavat, vai esim. OPNsensen oletus sallitaan kaikki ja estoja tarpeen mukaan?

Aika vähän lopulta tarvitsisi sallia, 80 ja 443 jos esim. DNS ja NTP -liikenne käännetään omille sisäisille palvelimille jne.

En kyllä itse ainakaan näe mitään lisäarvoa ulosmenevän liikenteen porttirajoituksille. Toiseen suuntaan toki kaikki kiinni.

 

[sra2010]

Kumpaa lähestymistä käytätte muurisääntöjen ulosmenevässä liikenteessä?

Kaikki estoon ja sallitaan tarvittavat, vai esim. OPNsensen oletus sallitaan kaikki ja estoja tarpeen mukaan?

Aika vähän lopulta tarvitsisi sallia, 80 ja 443 jos esim. DNS ja NTP -liikenne käännetään omille sisäisille palvelimille jne.

Riippuu verkosta, omassa käytössä useita vlan, pääverkossa kaikki sallittu, muista verkoista taas ei ole pääsyä pääverkkoon, mutta nettiin pääsee ja pfBlockerNG hoitaa sitten ulospäin menevän liikenteen suodatukset. Kaikki muurin hallinta porit on estetty pääverkkoa lukuunottamatta ja dns kyselyt ohjataan pfblockerille.

 

[juuhokei]

Kumpaa lähestymistä käytätte muurisääntöjen ulosmenevässä liikenteessä?

Kaikki estoon ja sallitaan tarvittavat, vai esim. OPNsensen oletus sallitaan kaikki ja estoja tarpeen mukaan?

Aika vähän lopulta tarvitsisi sallia, 80 ja 443 jos esim. DNS ja NTP -liikenne käännetään omille sisäisille palvelimille jne.

Melko vaikeaksi menee kyllä jos avaa vain tarvittavat ulos ja ei tuo oikeastaan mitään lisäturvaa tuo, perus 443:een kun saa kuitenkin haittaohjelmien tekemän liikenteen leivottua. Ellei sitten halua jotain sovelluksien toimintaa estää, kuten Bittorrent tai pelit.

Jos haluaa lähtevää liikennettä tarkkailla niin ehkä joku bottiverkon tai muuten haitalliseksi luokiteltujen osoitteiden suodatus ja lokitus, sitä en tosin tiedä miten tuo OPNsensessä tai pfSensessä tehdään (ilmeisesti tuolla pfBlockerNG:llä onnistuu?).

 

[Enhancer]

Melko vaikeaksi menee kyllä jos avaa vain tarvittavat ulos ja ei tuo oikeastaan mitään lisäturvaa tuo, perus 443:een kun saa kuitenkin haittaohjelmien tekemän liikenteen leivottua. Ellei sitten halua jotain sovelluksien toimintaa estää, kuten Bittorrent tai pelit.

Jos haluaa lähtevää liikennettä tarkkailla niin ehkä joku bottiverkon tai muuten haitalliseksi luokiteltujen osoitteiden suodatus ja lokitus, sitä en tosin tiedä miten tuo OPNsensessä tai pfSensessä tehdään (ilmeisesti tuolla pfBlockerNG:llä onnistuu?).

Suricataan pohjaa tuo OPNsensen oma sisäänrakennettu IPS/IDS, sillä voi sisäverkon sisäistä ja uloslähtevää liikennettä toki tarkkailla haittaohjelmien varalta. Ehkäpä tosiaan järkevintä niin.

 

[Aaltoliike]

Futro 930 :stä oletettavasti lahosi mSATA levy täällä. Oli noin viiden aikaan jämähtänyt koko paska aamuyöstä ja napista boottaamalla ei enää bootannut lainkaan OPNSensen puolelle. Hetken siinä ihmeteltyäni rullasin Memtestin, joka ei löytänyt muistista virheitä, mutta Parted Magicin HDDSentinel kertoi että tuossa levyssä on 12 uudelleensijoitettua sektoria, mutta se ei näköjään vielä laukaise SMART-hälytystä.

Tilanne tuon InnoDiskin 16GB mSATA levyn kanssa on siis sellainen, että kone ei siltä boottaa, näkee sen kyllä BIOS :issa. Tikulta yrittäessä uudelleenasentaa OPNSenseä tuolle levylle, koko homma jäätyy alkuunsa kun pitäisi kloonata levylle. Ei etene homma, ei vaikka antaa tuntikaupalla aikaa. Jämähtää siis ihan 1% ja total 0%

Tilasin uuden levyn Datatronicista 23 euroon 64GB ja samalla testiin 8GB keskusmuistipalikka, kun tuossa oli vain 4GB ostettuna alunperin.

 

[Rensu]

Pari viikkoa sitten vaihdoin PFsensestä OPNsenseen. Tallilla on ollut OPNsense jo pari vuotta ja nyt totesin, että on aika vaihtaa kotiakkin se käyttöön.
Yllättävän paljon oli kertynyt konffiin tavaraa ja samalla tuli vähän siivoiltua ja järkevöitettyä asioita. Aikaisemmin tuntui, että PFsensen käyttöliittymä on selkeämpi, mutta nyt alkaa mieli kääntymään ja alan tykkäämään OPNsensestä enemmän.

Pari asiaa on kuitenkin vielä ruuvamatta kuntoon.
1. LCDprocia ei näytä löytyvän suoraan lisäosista, ei sinänsä vakavaa, mutta kiva lisä tuo LCD-näyttö on ollut räkissä.
2. Sarjaporttiin kytketty GPS-vastaanotin aiheuttaa enemmän ongelmia. NTPD saa hienosti ajan GPS:ltä, mutta OPNsensen bootti jumii jos vastaanotin on kiinni sarjaportissa käynnistyksen aikana. Muistelen, että sama ongelma oli PFsensen kanssa aikoinaan ja että se olisi korjaantunut serial consolen päältä otolla. OPNsensessä on nyt käytössä ainoastaan VGA console ja silti käynnistys ei onnistu. En ole vielä päässyt näytön kanssa katsomaan miltä bootti näyttää, kun ei ole (löytynyt) pitkää näytön johtoa joka yltäisi laitekaapille ja GPS:ää ei viitsi alkaa repimään sieltä irti.

 

[Grizzle]

Sain minäkin vihdoin vaihdettua pfSensen OPNsenseen. Samalla tuli purkkiin päivitettyä BIOS ja lisättyä RAMmia 2 GB -> 8 GB.

Jonkun verran ihmettelemistä oli konffaamisessa. Jotkut asiat tehdään eri tavalla ja jotkut lähes samoin kuin pfSensessä. Web-käyttöliittymä tuntui nopeammalle kuin pfSensessä.

Palomuurisäännöt tuli nyt tehtyä vähän fiksummin. LAN-verkkojen eristys toisistaan on nyt tehty yhdellä säännöllä siten, että jatkossa on helppo lisätä verkkoja. Ei mulla mitään monimutkaista onneksi ollutkaan. Kolme verkkoa ja NAT-säännöt parille pleikalle.

Tehtävää jäi vielä mainossuodatus ja lokit RAMdiskille, ettei SSD kulu.

 

[Enhancer]

Sain minäkin vihdoin vaihdettua pfSensen OPNsenseen. Samalla tuli purkkiin päivitettyä BIOS ja lisättyä RAMmia 2 GB -> 8 GB.

Jonkun verran ihmettelemistä oli konffaamisessa. Jotkut asiat tehdään eri tavalla ja jotkut lähes samoin kuin pfSensessä. Web-käyttöliittymä tuntui nopeammalle kuin pfSensessä.

Palomuurisäännöt tuli nyt tehtyä vähän fiksummin. LAN-verkkojen eristys toisistaan on nyt tehty yhdellä säännöllä siten, että jatkossa on helppo lisätä verkkoja. Ei mulla mitään monimutkaista onneksi ollutkaan. Kolme verkkoa ja NAT-säännöt parille pleikalle.

Tehtävää jäi vielä mainossuodatus ja lokit RAMdiskille, ettei SSD kulu.

Miten teit LAN-eristyksen?

 

[Grizzle]

@Enhancer Tein aliaksen "PrivateNetworks" (nimi voi olla muutakin), johon listasin kaikki privaattiverkkojen osoiteet: 192.168.0.0/16, 172.16.0.0/12 ja 10.0.0.0/8

Oletuksena kaikista muista, paitsi käyttöönotossa luodusta LAN-verkosta, ei pääse ulos, ellei tee sallivaa sääntöä muuriin. Tein samanlaisen säännön, sillä erolla, että blokkaava Pass sääntö, kohde ei any vaan käänteisenä PrivateNetworks. Tuo siis päästää ulos kaiken muun paitsi, priivaattiverkkojen osoitteet. Tuo blokaa myös interfacen, joten voi olla tarpeen tehdä muita sääntöjä. Ainakin DNS pitää sallia, jos käyttää OPNsense-purkkia DNS-palvelimena. Jos haluaa portin vastaavan pingiin tms. niin nekin pitää sallia erikseen.

Tämä ulkomuistista, tarvittaessa voin laittaa tarkempaakin kuvausta, kunhan on pääsy muurille.

 

[Gobi]

Opnsense päivittyi eilen 24.1 versioon.

OPNsense Roadmap - Planned enhancements and innovations

OPNsense Roadmap. Planned enhancements and innovations for already one of the best open source firewalls. High-end security made easy™

opnsense.org

 

[Grizzle]

Tietysti tuli virheitä kun kirjoitin äkkiä muistista tuon ohjeen verkkojen eristämisestä.

Korjasin privaattiverkkojen osoitteissa olleen maskin alkuperäiseen postaukseen. Sääntökin piti olla pass, eikä block Block tekee just väärinpäin, sallii liikenteen LAN-verkkojen välillä. Laitetaan kuva niin ei tule virheitä.

Pahoittelut @Enhancer jos ehdit jo säätämään edellisen perusteella homman väärin.

 

[Enhancer]

Tietysti tuli virheitä kun kirjoitin äkkiä muistista tuon ohjeen verkkojen eristämisestä.

Korjasin privaattiverkkojen osoitteissa olleen maskin alkuperäiseen postaukseen. Sääntökin piti olla pass, eikä block Block tekee just väärinpäin, sallii liikenteen LAN-verkkojen välillä. Laitetaan kuva niin ei tule virheitä.

Pahoittelut @Enhancer jos ehdit jo säätämään edellisen perusteella homman väärin.

En toki, kunhan ideoita omien ajatusten tueksi kysyin.

 

[Grizzle]

Opnsense päivittyi eilen 24.1 versioon.

OPNsense Roadmap - Planned enhancements and innovations

OPNsense Roadmap. Planned enhancements and innovations for already one of the best open source firewalls. High-end security made easy™

opnsense.org

Onko kukaan uskaltautunut päivittämään?

 

[Gobi]

Onko kukaan uskaltautunut päivittämään?

Eilen asensin ja ei ole mitään ongelmia noussut esille.

 

[k70]

Onko kukaan uskaltautunut päivittämään?

Joo, ei ongelmia.

 

[j7u]

Onko kukaan uskaltautunut päivittämään?

Hyvin pelittää!

 

[Hulmuri]

Kyhäsin youtuben ohjeiden mukaan reitittimen niin, että taloyhtiön verkko menee Zimaboardiin, jossa on Proxmox VM ja siinä pfsense. Verkkokaupasta ostin aika edullisen TP-Linkin 5-porttisen hallittavan kytkimen. (TP-LINK TL-SG105E -5-porttinen kytkin 24,99)
Ajatus oli vähän parannella kotiverkkoa, ettei noi kaikki kiinalaiset IoT-lamput ois samassa kuin kaikki muut laitteet ja samalla vähän oppia jotain.

Osaatteko sanoa mistä kiikastaa, kun kytkin siirtyy mielivaltaisesti eri vlanien välillä vaikka laittaisin pfsensestä sille staattisen iipeen. Koitin myös pakottaa sitä kytkimen omasta hallintapaneelista tiettyyn IP:hen, mutta sitten sitä ei näkynyt enää missään. Mielellään laittasin kytkimen johonkin omaan VLAN:iinsa. Kytkimen asetukset pitäis vissiin olla aika perus ja oon tarkastanu monesta, että noin ihmiset ne on laittanut. Kaikkia asioita oon myös restarttaillu, mutta kytkin seikkailee. Piti alunperin hankkia Ubiquitin Flex mini -kytkin, mutta niitä ei ollu heti saatavilla niin päädyin TP-Linkkiin. Jos on outoa, että näin käy, niin ehkä hankin eri kytkimen. Jos mun asetuksissa näkyy outoa, niin ehkä pidän tän

Mielellään haluisin niin, että tuo wifireititin antais pfsensen hoitaa DHCP:een, mutta se ei millään onnistunut. Nyt näkyy vaan wifin ip, siellä wifissä on sitten omat wlanit sen reitittimen kautta. Ihan ok, mutta en pääse niitä vlaneja säätämään tuolta pfsensestä.

Nyt tuossa ID1 on kaikki portit untagged, mutta niin jengi on tehnyt. Tuo guest on vaan tuollanen, kun yks portti jäi yli, niin aattelin et voin siihen piuhalla liittää tarvittaes jonkun koneen jos säädän jotain.

 

[Khauron]

Kyhäsin youtuben ohjeiden mukaan reitittimen niin, että taloyhtiön verkko menee Zimaboardiin, jossa on Proxmox VM ja siinä pfsense. Verkkokaupasta ostin aika edullisen TP-Linkin 5-porttisen hallittavan kytkimen. (TP-LINK TL-SG105E -5-porttinen kytkin 24,99)
Ajatus oli vähän parannella kotiverkkoa, ettei noi kaikki kiinalaiset IoT-lamput ois samassa kuin kaikki muut laitteet ja samalla vähän oppia jotain.

Osaatteko sanoa mistä kiikastaa, kun kytkin siirtyy mielivaltaisesti eri vlanien välillä vaikka laittaisin pfsensestä sille staattisen iipeen. Koitin myös pakottaa sitä kytkimen omasta hallintapaneelista tiettyyn IP:hen, mutta sitten sitä ei näkynyt enää missään. Mielellään laittasin kytkimen johonkin omaan VLAN:iinsa. Kytkimen asetukset pitäis vissiin olla aika perus ja oon tarkastanu monesta, että noin ihmiset ne on laittanut. Kaikkia asioita oon myös restarttaillu, mutta kytkin seikkailee. Piti alunperin hankkia Ubiquitin Flex mini -kytkin, mutta niitä ei ollu heti saatavilla niin päädyin TP-Linkkiin. Jos on outoa, että näin käy, niin ehkä hankin eri kytkimen. Jos mun asetuksissa näkyy outoa, niin ehkä pidän tän

Mielellään haluisin niin, että tuo wifireititin antais pfsensen hoitaa DHCP:een, mutta se ei millään onnistunut. Nyt näkyy vaan wifin ip, siellä wifissä on sitten omat wlanit sen reitittimen kautta. Ihan ok, mutta en pääse niitä vlaneja säätämään tuolta pfsensestä.

Nyt tuossa ID1 on kaikki portit untagged, mutta niin jengi on tehnyt. Tuo guest on vaan tuollanen, kun yks portti jäi yli, niin aattelin et voin siihen piuhalla liittää tarvittaes jonkun koneen jos säädän jotain.

No on kyllä mielestäni turhan monimutkainen setuppi tuon pfSensen osalta. Nuo block -säännöt ovat turhia, koska pfSense blockkaa oletuksena liikenteen; et tarvitse siihen sääntöä. Ja mikä tuo wifi lanin sääntö on (tai mitä sillä koetetaan saavuttaa, että estät IP4 TCP liikenteen palomuurille?

Yksinkertainen on kaunista, joten ota vaikka setupit talteen tiedostoon ja aloita täysin alusta. pfSensestä ajat factory defaultit, ja luot ne VLANit sinne. Proxmoxiin tuot yhden WAN-langan ja toisen pyhität LANille. LAN voi sisältää monta VLANia.
Proxmoxiin voinet joutua tekemään säännön sen virtuaaliseen kytkimeen, että VLAN on 4095. Itse olen ESXi-miehiä, ja tämän joutuu ESXiin tekemään, jotta VLANit kulkevat esim. palomuurilta --> ESXi virtuaalinen kytkin --> kohdelaite (vaikka kytkin).

TP-Linkin kytkimessä on pakko olla VLAN1, n.s. "feature-by-design".
Täten koetat saada puhtaasta pfSensestä valutettua kytkimelle IP-osoitteen, ja tämän jälkeen voit vaikka kytkeä kytkimen johonkin porttiin vaikka kannettavan, ja koetat saada sille portille eri VLANin (jotka kaikki siis luot pfSensessä, ja kopiot sellaisenaan TP-Linkkiin). Kun saat sille eri VLANin, voit tehdä siitä interfacen ja antaa sille eri verkon ja eri DHCP-alueen.

Mikä sun WIFI-reititin on? Esimerkiksi Asuksen vehkeissä on "kiva" ominaisuus, että router-modessa Asus haluaa hoitaa DHCP:na ja oikeastaan kaiken muunkin. Ja se käsittelee sitä ulkopuolista verkkoa pahana internetinä, niin ulkopuolelta ei pääse WIFI-puolen vehkeisiin kiinni.
Ainoa mahdollisuus on pistää (Asuksen) purkki Access-Point -moodiin, ja tämä sitten tarvitseekin jo Asus-Merlin firmwaren sisään ja komentoriviä että saa homman pelaamaan.

Vaikea selittää ja tajuta mitä kaikkea sinulla on siellä, mutta ainakin yritin. Kysele lisää tässä threadissa kun joku askarruttaa. Ihan ensimmäisenä voit kokeille tuota Proxmoxin virtuaalisen kytkimen VLAN ID:n pistämistä 4095.

 

[Hulmuri]

No on kyllä mielestäni turhan monimutkainen setuppi tuon pfSensen osalta. Nuo block -säännöt ovat turhia, koska pfSense blockkaa oletuksena liikenteen; et tarvitse siihen sääntöä. Ja mikä tuo wifi lanin sääntö on (tai mitä sillä koetetaan saavuttaa, että estät IP4 TCP liikenteen palomuurille?

Yksinkertainen on kaunista, joten ota vaikka setupit talteen tiedostoon ja aloita täysin alusta. pfSensestä ajat factory defaultit, ja luot ne VLANit sinne. Proxmoxiin tuot yhden WAN-langan ja toisen pyhität LANille. LAN voi sisältää monta VLANia.
Proxmoxiin voinet joutua tekemään säännön sen virtuaaliseen kytkimeen, että VLAN on 4095. Itse olen ESXi-miehiä, ja tämän joutuu ESXiin tekemään, jotta VLANit kulkevat esim. palomuurilta --> ESXi virtuaalinen kytkin --> kohdelaite (vaikka kytkin).

TP-Linkin kytkimessä on pakko olla VLAN1, n.s. "feature-by-design".
Täten koetat saada puhtaasta pfSensestä valutettua kytkimelle IP-osoitteen, ja tämän jälkeen voit vaikka kytkeä kytkimen johonkin porttiin vaikka kannettavan, ja koetat saada sille portille eri VLANin (jotka kaikki siis luot pfSensessä, ja kopiot sellaisenaan TP-Linkkiin). Kun saat sille eri VLANin, voit tehdä siitä interfacen ja antaa sille eri verkon ja eri DHCP-alueen.

Mikä sun WIFI-reititin on? Esimerkiksi Asuksen vehkeissä on "kiva" ominaisuus, että router-modessa Asus haluaa hoitaa DHCP:na ja oikeastaan kaiken muunkin. Ja se käsittelee sitä ulkopuolista verkkoa pahana internetinä, niin ulkopuolelta ei pääse WIFI-puolen vehkeisiin kiinni.
Ainoa mahdollisuus on pistää (Asuksen) purkki Access-Point -moodiin, ja tämä sitten tarvitseekin jo Asus-Merlin firmwaren sisään ja komentoriviä että saa homman pelaamaan.

Vaikea selittää ja tajuta mitä kaikkea sinulla on siellä, mutta ainakin yritin. Kysele lisää tässä threadissa kun joku askarruttaa. Ihan ensimmäisenä voit kokeille tuota Proxmoxin virtuaalisen kytkimen VLAN ID:n pistämistä 4095.

Kiitos tosi paljon hyvistä vinkeistä!
Sillon kun wlaneja oli vähemmän, niin kytkin pysy samassa aliverkossa ja pystyin päättämään sen IP:een. Sitten otin sen hallintaan läppärillä toisesta GUEST aliverkosta yhteyden ja siirty sinne missä läppäri. Sit ku kytkin 10.10.20.0 verkkoon wifin, niin sit kytkin olikin siellä.

Sillä tubettajalla jonka setuppia kopioin oli vähän erilainen systeemi ja voi olla, että ne blockit oli sillä perusteltuja.



Täytyypä kokeilla tota Proxmox-sääntöä.
Mulla on tommonen Huawein OptiXstar K562 -meshi (Huawei OptiXstar K562 - Huawei Enterprise) jonka sain, mutta koska kämppä pieni, niin käytän vaan yhtä pönttöä. Siinä ei varmaan oo mitään ap-modea, taitaa olla vaan bridge. Jos laitan WAN:in DHCP, niin sitten ei suostu laittamaan LAN:in IP:tä esim 10.10.20.1, koska pfSense on laittanu sen meshin WAN:in siksi. Oon kokeillu vähän kaikkea, mutta pfSense ei oikeen suostu antaa meshin laitteille IP:itä.

 

[miksu8]

Onko kukaan tutkinut kulkeeko Windowsin kaikki verkkoliikenne "standardireittiä", johon softapalomuuri puree? Jos siis haluaa estää Windowsin verkkoliikenteen? Vai onko ainoa pomminvarma sulku ulkoinen rautapalomuuri?

 

[dataaja95]

Tutkimpa tässä miten voin toteuttaa high availability palomuurijärjestelmän opnsensellä. Käytössä on siis kaksi dellin opticplex masiinaa ja perinteinen dynaaminen dhcp:llä jaettava ip-osoite operaattorilta. Tuossa konfiguraatiossahan carp vaatii wanille kiinteän ip-osoitteen joten homma tökkää heti alkuunsa siihen, tutkiskelin hieman foorumeita ja löysin tällaisen ratkaisun kyseiseen ongelmaan. EN tätä ole vielä testannut, mutta kommenttien mukaan pitäisi toimia. Onko kenelläkään tästä, tai jostain vastaavasta virityksestä kokemusta

CARP with DHCP on WAN

CARP with DHCP on WAN

forum.opnsense.org

 

[dataaja95]

Testailimpa sitten tuota carpskriptiä ja hienosti heittää yhteydet kulkemaan backupmuurin kautta, palautuksessa tuntuu sen siaan olevan jotain ongelmia, kun mastermuuri käynnistyy uudelleen sen wan tuntuu jäävän alas ja slavemuuri pysyy edelleen päämuurina, kun molemmat käynnistetään uudelleen alkaa homma taas rokata, mutta jatketaan säätämistä, saattaa pi olla opnsense 24.1:n bugeja vielä, tuolla kommenteissahan mainittiin että jotain interfaceihin liittyvää olisi tässä versiossa muutettu, mutta niin siis toimii failover perus kuluttajayhteydellä ilman kiinteitä julkisia ip osoitteita

 

[user9999]

Reilu 6 tuntia oli Intel i3-N305 tuossa päällä eli ei merkittävää liikennettä. Mitä nyt verkossa olevat laitteet ottaa nettiin yhteyttä. Aika hyvin käyttää C3:sta.

Laitoin samat asetukset myös Shuttle DS77U laitteeseen. Jonkin aikaa ollut päällä ja tuossa koneessa ei CPU0 mennyt koskaan C3.

Ei noista muutoksista ole mitään haittaa. Kaikki toimii.

Tuli säädettyä tuon HUNSN RJ35 (i3-N305) kokoonpanon virrankulutusta. Neljä verkkokorttia käytössä ja idle kulutus oli 13.4W. Ainoastaan verkkokorttien speed säädöillä sai tiputettua idle kulutuksen 12.5W. Eli mulla on esim. Elisa interfacen nopeus max. 93Mbps niin korttiin 100baseTX <full-duplex>. Yksi interface on hallintajuttuihin niin siihen kanssa 100baseTX <full-duplex>.

Aika turhaa hommaa, mutta nyt tehty

Löyty hyvä ohje virrankulutuksen säätöön. Tuossa laitteena

• N100
• 8 GB Crucial 4800
• 128GB Patriot P300 M.2 SSD

CWWK/Topton/... Nxxx quad NIC router

Hi, I purchased a barebones CWWK with Model C case, which has arrived. I also purchased a Crucial 16GB RAM stick (model CT16G48C40S5, which has worked well for others in this thread) & a Team Group 256GB NVMe SSD (model TM8FP6256G0C101). I'm having issues installing pfSense CE 2.7.2 on bare...

forums.servethehome.com

Itsellä i3-N305 ja kolme verkkokorttia käytössä. En huomannut katsoa mikä kulutus oli ennen muutoksia, mutta nyt idle pyörii 9.6 - 9.8W välillä.

Edit: Mun verkkolaitteet kuluttaneet noin 48W. Eli tuossa on pfsenset, kytkin, AP ja modeemit jne. Nyt menee noin 43W.

 

[user9999]

Pari haavoittuvuutta löytynyt Unboundista:
Two DNSSEC validation vulnerabilities have been discovered in Unbound:
CVE-2023-50387 (referred here as the KeyTrap vulnerability) and CVE-2023-50868 (referred here as the NSEC3 vulnerability).

Unbound - CVE-2023-50387 and CVE-2023-50868

Was just reading about CVE-2023-50387 which seems to affect all DNS resolvers that support DNSSec. It seems NLnetlabs has released an Unbound patch today. ht...

forum.netgate.com

Todo #15256: Upgrade Unbound to >= 1.19.1 - pfSense - pfSense bugtracker

Redmine

redmine.pfsense.org

https://nlnetlabs.nl/downloads/unbound/CVE-2023-50387_CVE-2023-50868.txt

 

[Aaltoliike]

Onko muilla minkä verran Errors In virheitä ja pitäskö tuosta huolestua?

OPNsense 24.1.1-amd64
FreeBSD 13.2-RELEASE-p9
OpenSSL 3.0.13

 

[Khauron]

Onko muilla minkä verran Errors In virheitä ja pitäskö tuosta huolestua?

OPNsense 24.1.1-amd64
FreeBSD 13.2-RELEASE-p9
OpenSSL 3.0.13

pfSense 23.09.1
uptime 8 päivää + tunteja päälle

WAN:
In/out packets
197841769/143691060 (197.00 GiB/81.35 GiB)
In/out packets (pass)
197841769/143691060 (197.00 GiB/81.35 GiB)
In/out packets (block)
10535472/2 (4.98 MiB/152 B)
In/out errors
0/0
Collisions
0

LAN:
In/out packets
140116759/190904940 (80.62 GiB/191.03 GiB)
In/out packets (pass)
140116759/190904940 (80.62 GiB/191.03 GiB)
In/out packets (block)
5499/0 (354 KiB/0 B)
In/out errors
0/0
Collisions
0
Interrupts
92902753 (128/s)

VLAN DUUNI:
In/out packets
1318313/3986443 (542.26 MiB/5.02 GiB)
In/out packets (pass)
1318313/3986443 (542.26 MiB/5.02 GiB)
In/out packets (block)
4045/0 (332 KiB/0 B)
In/out errors
0/0
Collisions
0

VLAN IoT:
In/out packets
723293/516551 (191.28 MiB/40.14 MiB)
In/out packets (pass)
723293/516551 (191.28 MiB/40.14 MiB)
In/out packets (block)
616/0 (34 KiB/0 B)
In/out errors
0/1
Collisions
0

VLAN GUESTS:
In/out packets
101177/302059 (7.61 MiB/426.44 MiB)
In/out packets (pass)
101177/302059 (7.61 MiB/426.44 MiB)
In/out packets (block)
265/0 (15 KiB/0 B)
In/out errors
0/1
Collisions
0


____________________________________

Kyllä sinulla jotain vikaa on? WAN-kaapeli kunnolla paikallaan ja muutenkin kunnossa? opnSense saa julkisen IP-osoitteen, eikä ole mitään tupla-NATteja?

 

[Gobi]

Onko muilla minkä verran Errors In virheitä ja pitäskö tuosta huolestua?

OPNsense 24.1.1-amd64
FreeBSD 13.2-RELEASE-p9
OpenSSL 3.0.13

Puhdasta näyttää täällä, nettiyhteydessä jotain häikkää?

OPNsense 24.1-amd64
FreeBSD 13.2-RELEASE-p9
OpenSSL 3.0.12

 

[Aaltoliike]

Kiitoksia vastauksista. Lähdetään selvittämään asiaa. Palomuuri tosiaan saa julkisen ip, eikä mulla tietääkseni pitäisi olla mitään tupla nat himmeleitä, kun netti tulee suoraan asunnon pistokkeesta palomuuriin.

 

[k70]

	Packets In	Packets Out	Bytes In	Bytes Out	Errors In	Errors Out	Collisions
LAN	804 418 726	3 996 961 063	82.19 GB	5.97 TB	0	0	0
WAN	4 001 235 463	808 366 013	5.97 TB	78.73 GB	0	0	0

 

[Grazer]

Täytyy Lounealta varmaan tiedustella tarkemmin, mutta osaako joku viisaampi kertoa, miten on mahdollista että internettiin päin näkyy whatsmyip, grc.com ym. sivustoilla julkinen IP-osoite, samaten IPFire päivittää no-ip.comiin tuon julkisen IP-osoiteen, mutta palomuurin tiedoissa näkyy wan-puolen IP:nä 100.65-sarjan osoite, eli tuota carrier grade NAT -avaruutta?

 

[escalibur]

Onko muilla minkä verran Errors In virheitä ja pitäskö tuosta huolestua?

OPNsense 24.1.1-amd64
FreeBSD 13.2-RELEASE-p9
OpenSSL 3.0.13

Syy on hyvin suurella todennäköisyydellä jossain näistä neljässä asiassa:

1. Viallinen verkkokaapeli
2. Viallinen yhteys (olipa vikakohde missä tahansa)
3. Viallinen verkkokortin liitin
4. Pakettien MTU-arvot ovat ristiriidassa yhteyden päiden välillä


Toki kaapelin pituudellakin voi olla väliä, mutta oletan että et käytä jotain 100m vetoja.

 

[Grazer]

Täytyy Lounealta varmaan tiedustella tarkemmin, mutta osaako joku viisaampi kertoa, miten on mahdollista että internettiin päin näkyy whatsmyip, grc.com ym. sivustoilla julkinen IP-osoite, samaten IPFire päivittää no-ip.comiin tuon julkisen IP-osoiteen, mutta palomuurin tiedoissa näkyy wan-puolen IP:nä 100.65-sarjan osoite, eli tuota carrier grade NAT -avaruutta?

Kuluttajien Valokuitu-liittymiin jatkossa myös verkon sisäisiä ipv4-osoitteita | Lounea

Otamme 15.3.2021 käyttöön järjestelmän, jossa kuluttajien Valokuitu-liittymiin jaetaan julkisten, vaihtuvien ip-osoitteiden sijasta Lounean verkon sisäinen ip-osoite. Toiminne otetaan ensin käyttöön hitaimmissa nopeusluokissa. Verkon sisäinen ip-osoite toimii asiakkaiden käyttämien palveluiden...

lounea.fi

Vastaus löytyikin. Näköjään aika pitkä ja häilyvä hanke ollut kun keväällä 2021 alkanut ja itse huomasin tämän ongelman vasta tuossa pari viikkoa sitten, kun en päässyt enää vanhempien serveriin kiinni. Pitääkin tilata julkinen IP.

 

[Khauron]

Kuluttajien Valokuitu-liittymiin jatkossa myös verkon sisäisiä ipv4-osoitteita | Lounea

Otamme 15.3.2021 käyttöön järjestelmän, jossa kuluttajien Valokuitu-liittymiin jaetaan julkisten, vaihtuvien ip-osoitteiden sijasta Lounean verkon sisäinen ip-osoite. Toiminne otetaan ensin käyttöön hitaimmissa nopeusluokissa. Verkon sisäinen ip-osoite toimii asiakkaiden käyttämien palveluiden...

lounea.fi

Vastaus löytyikin. Näköjään aika pitkä ja häilyvä hanke ollut kun keväällä 2021 alkanut ja itse huomasin tämän ongelman vasta tuossa pari viikkoa sitten, kun en päässyt enää vanhempien serveriin kiinni. Pitääkin tilata julkinen IP.

Koeta nyt ensi hätään vaikka nollata nuo virheet, ja poistaa asetukset (nämä pfSensestä --> Interfaces --> WAN), mutta opnSensessä varmaan melko samassa paikkaa:

Block private networks and loopback addresses
&
Block bogon networks

Ja kerro mitä tapahtuu virheille tämän jälkeen. Varsinkin tuolla WAN-puolella, jossa sinulla on "vaatimattomasti"
46,87 GB sisään ja 811936 errors in
tekee ratioksi 5,773
Errors out on 0, joten en usko että verkkokaapelissa on vikaa, tai joku liitin olisi paskana. Tuo CG-NAT on nyt mihin rahani pistäisin.
Onko sinulla VPN-yhteyttä, millä voisit testata? Joku Linux-torrentti (tai vaikka kolme) lataukseen sen kautta, ja jos errorit näyttää nollaa niin eiköhän se tuo CG-NAT ole.

 

[mikajh]

Lähdetään selvittämään asiaa.

Kokeile etsiä minkä niminen laite on kyseessä (ehkä ix, jos Intelin ohjain). Sitten tarkempaa statistiikkaa, minkälaisia virheitä löytyy, esim.:

Spoileri: root@OPNsense2:~ # sysctl -a | egrep "^dev" | grep -i netw

dev.vtnet.2.%desc: VirtIO Networking Adapter
dev.vtnet.1.%desc: VirtIO Networking Adapter
dev.vtnet.0.%desc: VirtIO Networking Adapter
dev.virtio_pci.4.%desc: VirtIO PCI (legacy) Network adapter
dev.virtio_pci.3.%desc: VirtIO PCI (legacy) Network adapter
dev.virtio_pci.2.%desc: VirtIO PCI (legacy) Network adapter
root@OPNsense2:~ # sysctl dev.vtnet.1 | grep sum
dev.vtnet.1.txq0.csum: 0
dev.vtnet.1.rxq0.csum_failed: 0
dev.vtnet.1.rxq0.csum: 144396854
dev.vtnet.1.tx_csum_offloaded: 0
dev.vtnet.1.tx_tso_without_csum: 0
dev.vtnet.1.tx_csum_proto_mismatch: 0
dev.vtnet.1.tx_csum_unknown_ethtype: 0
dev.vtnet.1.rx_csum_offloaded: 0
dev.vtnet.1.rx_csum_failed: 0
dev.vtnet.1.rx_csum_bad_proto: 0
dev.vtnet.1.rx_csum_bad_offset: 0
dev.vtnet.1.rx_csum_bad_ipproto: 0
dev.vtnet.1.rx_csum_bad_ethtype: 0

 

[naguttaha]

Täällä myös tänään pfsense havainnut loss-ratea Lounean kuidun kanssa. Tähän saakka käyttöönotosta joulukuu23 ei kertaakaan...

 

[Aaltoliike]

Syy on hyvin suurella todennäköisyydellä jossain näistä neljässä asiassa:

1. Viallinen verkkokaapeli
2. Viallinen yhteys (olipa vikakohde missä tahansa)
3. Viallinen verkkokortin liitin
4. Pakettien MTU-arvot ovat ristiriidassa yhteyden päiden välillä

Toki kaapelin pituudellakin voi olla väliä, mutta oletan että et käytä jotain 100m vetoja.

MTU-arvoihin ei ole koskettu ikinä. Ovat oletuksella siis jokapaikassa.

Koeta nyt ensi hätään vaikka nollata nuo virheet, ja poistaa asetukset (nämä pfSensestä --> Interfaces --> WAN), mutta opnSensessä varmaan melko samassa paikkaa:

Block private networks and loopback addresses
&
Block bogon networks

Ja kerro mitä tapahtuu virheille tämän jälkeen. Varsinkin tuolla WAN-puolella, jossa sinulla on "vaatimattomasti"
46,87 GB sisään ja 811936 errors in
tekee ratioksi 5,773
Errors out on 0, joten en usko että verkkokaapelissa on vikaa, tai joku liitin olisi paskana. Tuo CG-NAT on nyt mihin rahani pistäisin.
Onko sinulla VPN-yhteyttä, millä voisit testata? Joku Linux-torrentti (tai vaikka kolme) lataukseen sen kautta, ja jos errorit näyttää nollaa niin eiköhän se tuo CG-NAT ole.

En tiedä sekotitko mun tapauksen ja @Grazer tapauksen. Joskin testasin ottaa nuo pari block täppää pois, ei vaikutusta.

Vaihtelin piuhoja ja nyt parisen tuntia ollut pystyssä näillä tuloksilla: