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

Rakentelin joutessani tuossa pfsense koneen jossa Ryzen 5600G, Asus ProArt B550-Creator emolla, missä on 2x Intel 2.5G verkkiksiä integroituna ja 16gb muistia kaveriks. Näyttäis vievän 42W. Tuohon sitten jossain vaiheessa joku 2x10G tai nopeempi Intelin kortti kaveriks. En vielä laittanu käyttöön.. asetuksia laittelin kuntoon. Voishan tuota testailla. Valoon 2gbit kuituun ajattelin laitella loppuvuodesta, jos se olis vaikka sillon kytketty jo.
 
Kustannustehokas, virtapihi mutta riittävän nopea purkki ns. routteriksi etsinnässä.
Tällä hetkellä 5G modeemin perässä on joku Asuksen AC-sarjan purkki hoitamassa routtauksen (+dhcp, openVPN). OpenVPN on jo pitkään huutanut että not secure kun niin vanha versio. Viime aikoina purkki on muutenkin tökkinyt ja vaatii boottailua. Jostain syystä ulkoverkosta päin tulevat kutsut nykyään hyvin harvoin menee purkin läpi. Eli OpenVPN tai muutamat webbikutsut mitä lähettelen ulkomaailmasta timeouttaa.
Eli jotain pitäisi keksiä tilalle. Mitä? Netti tosiaan 5G ja 1000mbps liittymä josta tulee ehkä 600mbps nykysetupilla.
Laitteita verkossa n. 100kpl joista suurin osa kotiautomaatiokrääsää. Kaikki laitteet on kyllä yhdessä ja samassa wanissa, en käytä vlaneja.

Yllä suositeltiin NanoPi R5C:tä ja siihen openwrt. Onko tämä järkevin omaan käyttöön?

EDIT: WIFIä en tarvitse, sen hoitaa mesh purkit.

Jos päädyt NanoPi, niin mulla on myyntiosiossa R5S myynnissä.
 
Tuli ostettua https://www.amazon.de/S-079DE-Processor-Alternate-Bluetooth-Fanless/dp/B0BV2F3TQH , ja tarkoitus oli laittaa uusin Sophos palomuuri tuonne. Kaksi gigaista verkkokorttia, kun Sophos ei tue vielä niitä Intellin 2.5 GBn kortteja.
USB-bootti Rufuksella vaati, että tehdään USB-muisti DD-moodissa. Sitten piti asentaa Win11, että BIOSista oli mahdollista disabloida secure boot.
Noiden jälkeen asennusohjelma meni läpi, mutta ruutu on kivasti kohdassa:
Booting ’20_0_2_377’

Joka onkin sitten ihan ok, mitään konsolia ei tuonne tule. Kone kiinni toiseen porttiin ja selaimella konffimaan asennuksen loppusäädöt.
 
Viimeksi muokattu:
R5C päätyi lopulta tuotantokäyttöön, ei ollut aikaisemmin säätöintoa palomuurin vaihtoon. No nyt pelaa se tärkein uutuus cake SQM:
1724493993800.png

vähän aikaa piti hakea up/down limittiä kohdalleen, eli raja niin ylös kuin mahdollista ilman että ping heikkenee. Tämä on sikäli tärkeää että kun tekee etätöitä niin Teams yms. puhelut ei ala pykimään kun nuoriso tulee koulusta ja laittaa Steamin tms. lataamaan putken täydeltä. Ilma SQM:ää pingit saattoi hyppiä satoihin.
 
R5C päätyi lopulta tuotantokäyttöön, ei ollut aikaisemmin säätöintoa palomuurin vaihtoon. No nyt pelaa se tärkein uutuus cake SQM:
1724493993800.png

vähän aikaa piti hakea up/down limittiä kohdalleen, eli raja niin ylös kuin mahdollista ilman että ping heikkenee. Tämä on sikäli tärkeää että kun tekee etätöitä niin Teams yms. puhelut ei ala pykimään kun nuoriso tulee koulusta ja laittaa Steamin tms. lataamaan putken täydeltä. Ilma SQM:ää pingit saattoi hyppiä satoihin.
Joo kyllähän se QoS parantaa yhteyttä vaikka perusyhteys olisikin nopea. Tosin tuo fast.com ei ole mikään optimaalinen testipalvelin, kun perusidea on vain testata että onko kaistaa riittävästi videostriimaukseen, johon jo muutama 30M riittää hyvin. Speedtestillä löytyy usein selkeästi nopeampia palvelimia.
 
Joo kyllähän se QoS parantaa yhteyttä vaikka perusyhteys olisikin nopea. Tosin tuo fast.com ei ole mikään optimaalinen testipalvelin, kun perusidea on vain testata että onko kaistaa riittävästi videostriimaukseen, johon jo muutama 30M riittää hyvin. Speedtestillä löytyy usein selkeästi nopeampia palvelimia.
Eipätässä nopeammalla tee mitään, kyseessä 250M kuitu. Lähinnä tuossa on nyt tuo ping arvo joka on sama unloada ja loaded tilanteissa. Eli pingi ei muutu miksikään vaikka yhteys on kuormitettu tappiin.
 
Pääsin nopean liittymän ääreen ja ajoin wireguard testit, iperf3 antoi seuraavan tuloksen:
[SUM] 0.00-10.00 sec 294 MBytes 247 Mbits/sec sender
[SUM] 0.00-10.00 sec 293 MBytes 245 Mbits/sec receiver

Alla tässä testissä normaali IPv4 NAT, palomuuri ja SQM cake. Huvittavaa tässä oli se että wireguard yhteyden yli pingi tippui iperf3-testin aikana:

Reply from: bytes=32 time=12ms TTL=64
Reply from: bytes=32 time=12ms TTL=64
Reply from: bytes=32 time=14ms TTL=64
Reply from: bytes=32 time=11ms TTL=64
Reply from: bytes=32 time=11ms TTL=64
Reply from: bytes=32 time=10ms TTL=64
Reply from: bytes=32 time=10ms TTL=64
Reply from: bytes=32 time=10ms TTL=64
Reply from: bytes=32 time=10ms TTL=64
Reply from: bytes=32 time=11ms TTL=64
Reply from: bytes=32 time=10ms TTL=64
Reply from: bytes=32 time=11ms TTL=64
Reply from: bytes=32 time=10ms TTL=64
Reply from: bytes=32 time=10ms TTL=64
Reply from: bytes=32 time=11ms TTL=64
Reply from: bytes=32 time=12ms TTL=64
Reply from: bytes=32 time=12ms TTL=64

Ilman tunnelin kuormitusta ping on tasaiset 12ms ja testin alussa piikkaa 14 ja sitten tippuu 10-11 tasolle. Kun testi päättyy niin palataan normaaliin 12ms tasoon. Käytännössä wireguard jaksaa saturoida 250M kuituliittymän kotona, ajoin testin gigasen kuidun päästä. NanoPi R5C soveltuu siis hyvin tälläiseen reunareititykseen alle gigasilla liittymillä.
 
Tulipa päivitettyä oma pfSense-rauta yli viiden vuoden jälkeen edellisestä päivityksestä.

Intel i226 dual 2,5GbE
i5 9500T
16GB DDR4 RAM
jne

1724852760705.png


400/200 kuitu:

1724852859559.png


Jospa tällä pärjäisi taas muutaman vuoden. :)
 
Viimeksi muokattu:
Odroid H4+/Ultra vois olla ihan passeli reititin käyttöön, vanhempi H3 varmaan myös riittäis mutta ovat kalliimpia ja hitaampia sekä realtekin verkkopiireillä vaikka en tiedä onko se nykyään enää ongelma.

Tässä valmistajan sivut ODROID-H4 PLUS – ODROID

Saksasta näyttäs saavan myös lisäverkkoporttien ja koteloiden kera https://www.reichelt.com/fi/en/shop/category/ODROID/industrial_solutions-9104?&PAGE=0

Melkeen tekis miele vaihtaa tää cwwk:n tekele tommoseen mutta H4 tarvinee tuulettimen ja nykyinen menee passiivisena.
 
Mulla on HUNSN RJ35, jossa on i3 N305 ilman tuuletinta.
Tossa HUNSN:ssä taitaa koko kotelo toimia jäähdyttimenä kun taas Odroidissa erillinen rivasto prossun päällä joka ei kotelossa ollessaan varmaan kovin hyvin jäähdytä ilman että tuuletin puhaltaa raitista ilmaa siihen. En tiedä kummassa enemmän pintalaa mutta mutta massaa varmasti vähemmän Odroidissa.
 
Tossa HUNSN:ssä taitaa koko kotelo toimia jäähdyttimenä kun taas Odroidissa erillinen rivasto prossun päällä joka ei kotelossa ollessaan varmaan kovin hyvin jäähdytä ilman että tuuletin puhaltaa raitista ilmaa siihen. En tiedä kummassa enemmän pintalaa mutta mutta massaa varmasti vähemmän Odroidissa.
Joo tuossa HUNSH toimii kotelo jäähdyttimenä eli se lämpenee.
Kuva eri mallista HUNSN [CWWK] RJ36
Replacement%20Thermal%20Compound%20-%20HUNSN%20copy.jpg
 
Tulipa päivitettyä oman pfSense-raudan yli viiden vuoden jälkeen edellisestä päivityksestä.

Intel i226 dual 2,5GbE
i5 9500T
16GB DDR4 RAM
jne

1724852760705.png


400/200 kuitu:

1724852859559.png


Jospa tällä pärjäisi taas muutaman vuoden. :)
On kyllä melko jyrmyä rautaa pfSenselle :D
Mitä ajattelit tehdä tuolla kapasiteetilla? Sehän nyt idlaa ~95% CPU:sta ja RAM:sta koko ajan, vaikka pistäisit siihen mitä sääntöjä, VLANeja, filttereitä, tai SNORTteja.
 
On kyllä melko jyrmyä rautaa pfSenselle :D
Mitä ajattelit tehdä tuolla kapasiteetilla? Sehän nyt idlaa ~95% CPU:sta ja RAM:sta koko ajan, vaikka pistäisit siihen mitä sääntöjä, VLANeja, filttereitä, tai SNORTteja.
Mä ajattelin että tuo i9-13900K ja 64gb muistia olisi varmasti riittävä, Proxmoxissa sit 64gb jää muille leikeille. ;)
 
On kyllä melko jyrmyä rautaa pfSenselle :D
Mitä ajattelit tehdä tuolla kapasiteetilla? Sehän nyt idlaa ~95% CPU:sta ja RAM:sta koko ajan, vaikka pistäisit siihen mitä sääntöjä, VLANeja, filttereitä, tai SNORTteja.
Laite on rakennettu lähinnä YouTube-sisällön vuoksi. Jossain vaiheessa voisin kokeilla jotain vastaavaa projektia "hinnat alkaen"-spekseillä. :)
 
Kummallinen probleema OPNsense 24.7.3_1 päivityksen jälkeen, jos Wireguardissa pitää site-to-site clientit päällä (allowed IP 0.0.0.0/0) niin IPv4 reititys WANista ulos kuolee LAN puolella. IPv6 toimii. Pelkällä Wireguard -> LAN access clienteillä ei mitään ongelmaa.

Jotain NAT kipua ilmeisesti, ennen päivitystä site-to-site clientit ja IPv4 toimi tuolla samalla Wireguard asetuksella ilman ongelmia.
 
Sophos XG firewall v21 early access...

Uutena mm. Let's encrypt-supportti. Uudempaa Linuxin kerneliä (ja paremmin 2.5Gbitin ethernettikortteja tukevaa versiota) saadaan vielä odotella. V22 ehkä?

 
Rakensin serverin, jonka alustana toimii Proxmox. Proxmoxissa pyörii virtuaalisena Home Assistant ja OPNsense. Proxmoxin etäkäyttö hoituu serverin emolevylle integroidun verkkokortin kautta. Integroidun verkkokortin nimi on eno1 ja se on sillattuna vmbr0. (Integroitu verkkokortti on käytössä Proxmoxin hallintaan, sekä jaettu myös Home Assistant virtuaalikoneelle.)

Lisäsin serveriin kaksi erillistä verkkokorttia integroidun lisäksi. Nämä ovat Proxmoxissa enp2s0 ja enp6s0, joista tein Linux sillat vmbr1 ja vmbr2.
eno1 (vmbr0) -> Proxmox ja Home Assistant
enp2s0 (vmbr1) -> OPNsense LAN
enp6s0 (vmbr2) -> OPNsense WAN

Sain OPNsensen asennettua ja reitittämään, mutta tämän jälkeen Proxmox katoaa sisäverkosta. Vmbr0 silta vaikuttaisi kuitenkin toimivan, sillä Home Assistant toimii edelleen normaalisti sisäverkon kautta.

Proxmox käyttää kiinteää IP-osoitetta ja portti on default: 192.168.11.200:8006.
OPNsense jakaa IPv4-osoitteet 192.168.11.10 - 192.168.11.254 väliltä.
Home Assistant hakee dynaamisen IP:n automaattisesti.
Kaikki sisäverkon koneet ovat dynaamisella IPv4 osoitteella samassa 192.168.11.xxx sisäverkossa. Gateway on 192.168.11.1.

Kaikki sisäverkon koneet ovat kiinni samassa kytkimessä:
Netti tulee suoraan OPNsense enp6s0 verkkokorttiin (vmbr2 WAN).
OPNsense reitittää liikenteen ja verkkokortti enp2s0 (vmbr1 LAN) on kytketty kytkimeen.
Proxmox ja Home Assitant yhdistyvät eno1 verkkokortista (vmbr0 silta) kytkimeen.

Miten tätä pitäisi alkaa selvittää, jotta myös Proxmox olisi käytettävissä sisäverkon kautta? Joudun tällä hetkellä siirtämään eno1 verkkokortista piuhan toiseen reitittimeen ja sen kautta kirjautumaan etähallintasivulle.
proxmox.png
 
Yksi mahdollisuus olisi, että HA saa OPNsenseltä saman IP-osoitteen kuin Proxmox kun Proxmoxiin kiinteästi asetettu IP on DHCP:n jakaman alueen sisällä ja DHCP:lle ei ole mitään tietoa, että sen jakamalla alueella voi olla jo varattuja IP-osoitteita, jos sitä ei ole sille kerrottu.

Itse vaihtaisin tuon Proxmoxin IP:n tuon DHCP:n alueen ulkopuolelle (IP:t 192.168.11.1 - 192.168.11.9 tuon sun conffin mukaan), ettei tule päällekkäisyyksiä. Samalla laittaisin Home Assistantille kans kiinteän IP:n. Esim. Proxmoxille 192.168.11.2 ja HA:lle 192.168.11.3.
 
Rakensin serverin, jonka alustana toimii Proxmox
Mä olen kanssa saanut proxmoxin sekaisin laittamalla verkkokortteja jälkeenpäin.
Säätöä voi yrittää /etc/network/interfaces tiedostossa
Toimiiko jos opnsense on irti niin ainakaan dhcp ei sotke.
Näkyykö arp taulukossa?
Ja perustesti ping 192.168.11.200

Tuossa on vain pari konetta ehkä helpompi tehdä kuten minä ja jasentaa kaikki uusiksi.
 
Viimeksi muokattu:
Miten tätä pitäisi alkaa selvittää, jotta myös Proxmox olisi käytettävissä sisäverkon kautta? Joudun tällä hetkellä siirtämään eno1 verkkokortista piuhan toiseen reitittimeen ja sen kautta kirjautumaan etähallintasivulle.
proxmox.png
Tuola on näköjään /32 maski koita vaihtaa /24
 
Rakensin serverin, jonka alustana toimii Proxmox. Proxmoxissa pyörii virtuaalisena Home Assistant ja OPNsense. Proxmoxin etäkäyttö hoituu serverin emolevylle integroidun verkkokortin kautta. Integroidun verkkokortin nimi on eno1 ja se on sillattuna vmbr0. (Integroitu verkkokortti on käytössä Proxmoxin hallintaan, sekä jaettu myös Home Assistant virtuaalikoneelle.)

Lisäsin serveriin kaksi erillistä verkkokorttia integroidun lisäksi. Nämä ovat Proxmoxissa enp2s0 ja enp6s0, joista tein Linux sillat vmbr1 ja vmbr2.
eno1 (vmbr0) -> Proxmox ja Home Assistant
enp2s0 (vmbr1) -> OPNsense LAN
enp6s0 (vmbr2) -> OPNsense WAN

Sain OPNsensen asennettua ja reitittämään, mutta tämän jälkeen Proxmox katoaa sisäverkosta. Vmbr0 silta vaikuttaisi kuitenkin toimivan, sillä Home Assistant toimii edelleen normaalisti sisäverkon kautta.

Proxmox käyttää kiinteää IP-osoitetta ja portti on default: 192.168.11.200:8006.
OPNsense jakaa IPv4-osoitteet 192.168.11.10 - 192.168.11.254 väliltä.
Home Assistant hakee dynaamisen IP:n automaattisesti.
Kaikki sisäverkon koneet ovat dynaamisella IPv4 osoitteella samassa 192.168.11.xxx sisäverkossa. Gateway on 192.168.11.1.

Kaikki sisäverkon koneet ovat kiinni samassa kytkimessä:
Netti tulee suoraan OPNsense enp6s0 verkkokorttiin (vmbr2 WAN).
OPNsense reitittää liikenteen ja verkkokortti enp2s0 (vmbr1 LAN) on kytketty kytkimeen.
Proxmox ja Home Assitant yhdistyvät eno1 verkkokortista (vmbr0 silta) kytkimeen.

Miten tätä pitäisi alkaa selvittää, jotta myös Proxmox olisi käytettävissä sisäverkon kautta? Joudun tällä hetkellä siirtämään eno1 verkkokortista piuhan toiseen reitittimeen ja sen kautta kirjautumaan etähallintasivulle.
proxmox.png
Laita nuo lisätyt verkkokortit WAN + LAN suoraan rautatasolla OPNsenselle passthroughlla ja sitten tuo vmbr0 siltä OPNsensessä sillaten samaan LAN:n. DCHP-alue alkamaan vaikka .10, OPNsense on vaikka .1 ja Proxmox .2.
 
/32 maski sallii vain yhden osoitteen ehkä tuo HA varas sen?
Esim /32 ja /24 maski
Mahdollista. Toinen vaihtoehto olisi Huawei B715, joka oli samassa verkossa WIFI Access pointtina. Siitä oli DHCP serveri pois päältä ja oli ainoastaan laajentamassa langatonta verkkoa yläkertaan. Olin vaihtanut siihen joskus aikaisemmin 192.168.11.2 osoitteen, mikä muistui mieleeni, kun aloin vaihtamaan Proxmoxin ip-osoitetta. Vaihdoin Proxmoxiin /24 maskin, sekä ip-osoitteen ja lisäksi otin Huawein verkosta pois, jonka jälkeen yhteydet alkoivat toimia.

En tiedä oliko syyllinen häröilevä Huawei vaiko mahdollisesti Home Assistantin varaama IP-osoite.
 
Missaankohan jotain simppeliä... Unraid purkissa Home Assistant jossa Homekit bridge IOS laitteita varten. IoT vehkeet on oman VLANin alla Wifissä ja toimii trusted LANin kautta ok, mutta vaikka teen OPNSenseen mDNS repeaterin ja 5353 portti auki VLAN ja trusted LAN välille, niin IOS laitteiden Homekit ei pysty hallitsemaan/näkemään IoT VLAN laitteita.

Jos lyön IoT laitteet samaan trusted LANiin, niin toimii ok IOS puolella. Toisaalta jos IoT kamat on trusted LANissa kiinni, niin silloin IOS ei myöskään pääse niihin kiinni, jos on Wireguardin kautta kotiin yhteys, mutta tuo lienee Layer 2/3 + mDNS VPN ongelma?

Onko helpompi mennä suosiolla siitä mistä aita on matalin ja luovuttaa taistelu hankkimalla joku Homepod tai Apple TV Homekit hubiksi, joka on IoT VLANin sisällä ja hoitamalla IoT ohjaukset iCloudin kautta?
 
Ainakin uusin iOS 18 rikkoi jotain Homepodissa. Ennen ohjasin sen kautta Hueta ongelmitta mikä oli oman vlanin takana. Nyt laitteet menee vain no response tilaan. Vaihdoin sitten HAn kautta nuokin niin toimii ongelmitta taas.

Onhan se hub ehkä helpoin. Kannattaa muistaa että Applen laitteet on samalla wlanissa kuin muut Applen laitteet. Että ei voi suoraan pakottaa omaan vlaniin.
 
Ainakin uusin iOS 18 rikkoi jotain Homepodissa. Ennen ohjasin sen kautta Hueta ongelmitta mikä oli oman vlanin takana. Nyt laitteet menee vain no response tilaan. Vaihdoin sitten HAn kautta nuokin niin toimii ongelmitta taas.

Onhan se hub ehkä helpoin. Kannattaa muistaa että Applen laitteet on samalla wlanissa kuin muut Applen laitteet. Että ei voi suoraan pakottaa omaan vlaniin.
Apple TV verkkopiuhalla mielestäni aika ehdoton jos Homekitiä käyttää. Matter / Thread -tuki siinä samalla.
 
Näyttää olevan siis jotain IOS 18 muutoksia, harmi kun en ehtinyt ottaa Homekittiä käyttöön IOS 17 puolella, niin olisi voinut varmistaa onko versioiden välillä tullut jotain tiukennuksia VLANin takana oleville laitteille. Hiukan kyllä vieläkin ihmettelen, puuttuuko vain joku portti Homekitille mikä täytyisi puhkaista auki, koska oman järjen mukaan IoT VLAN <-> trusted LAN välillä pitäisi kyllä Homekit toimia, kunhan portit ja säännöt on kunnossa.

Bonjour/Zeroconf on tosin aina ollut yhtä helvettiä saada toimimaan VLANien kanssa, joten mene ja tiedä.

Täytyy laittaa Apple TV hankintaan, kunhan saavat uuden sukupolven ulos ja mennä siihen asti pelkästään käsin ohjaamalla Home Assistantin kautta.
 
Apple TV verkkopiuhalla mielestäni aika ehdoton jos Homekitiä käyttää. Matter / Thread -tuki siinä samalla.
Homepodeissakin on tuki.

Itsellä toimi kaikki hyvin ennen iOS 18 päivitystä ja moni muukin valitellut redditissa että päivityksen jälkeen hajosi.

Vahdoin sitten HAn nuo valot ja se kommunikoin Applen kanssa.
 

Statistiikka

Viestiketjut
253 826
Viestejä
4 411 053
Jäsenet
73 260
Uusin jäsen
Avaruuslapsi

Hinta.fi

Back
Ylös Bottom