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

[Rusna]

Veikkaan, että ongelma juontaa juurensa tuohon että oleva asennus on siirretty virtualisoiduksi. Itsellä on virtualisoituna ja tuollaista ei ole havaittu. Onhan se pfsense asennettu ja virtuaalikone määritelty pfsensen ohjeiden mukaisesti (niillä muistaakseni oli omat ohjeet proxmox asennukseen)? Onko käytössä joku verkko adapterin passthrough vai miten proxmoxissa on määritelty tuon virtuaalikoneen verkkohommat? Onko pfsensen asetuksista valittuna Disable hardware checksum offload' and 'Disable hardware TCP segmentation offload?

Kappas kehveliä, hyvä tärppi. Olin tietysti vain noudattanut jotain tubettajien random virtualisointiohjeita. Täytyy tarkistaa Netgaten oma ohje: pfSense® software Configuration Recipes — Virtualizing with Proxmox® VE | pfSense Documentation
Tarkistan ja palaan.

 

[Ogeli]

Onko muilla ollut ongelmia proxmoxin päällä pyörivän pfSensen kanssa?

Mun 100M LTE nopeuksilla ei ongelmaa OPNSensen kanssa ainoa häiritsevä tekiä on että prossukuorma hyppii välillä 100%:iin, ei pätkimisiä.
Koitin vaihtaa prossun kvm64>host (13-7100) ei vaikutusta tosin tuokin emulaatio.
Tuo taitaa tulla jostain proxmox prosessista?
Koitin laittaa verkkokortin pci-passthrough tilaan mutt tuli joku herja että käytössä, johtunee että mulla useampi testireititin joista yksi kerrallaan käytössä?

Asennuksia on ollut sekä omasta päästä että ohjeilla, ei just eroja.

 

[tarmo2011]

Alunperin oli suoraan asennetuna raudan päälle, ei ongelmia, sitten halusin asentaa virtualisoituna, koska miksi ei, ja asensin samalle raudalle xcp-ng+xen orchestra+pfsense virtuaalisena. Toki tein ohjeen mukaan säädöt asennuksen jälkeen Aluksi oli ongelmia, mutta johtui omasta dns asetus virheestä. Nyt toimii täydellisesti.

 

[dataaja95]

Olisiko järkevää virtualisoida nyt käytössä oleva opnsense, itselleni on tulossa proxmox virtualisointiklusteri kolmella koneella ja tuossahan saisi näppärästi ajettua opnsenseäkin, jos ensimmäinen kone hajoaisi siirtyisi palomuuri pyörimään toisella hostilla, näimpä katkoksia verkkoon ei tulisi. Mietinkin tässä lähinnä tietoturvakysymyksiä, itse olen tottunut pitämään aina palomuurin omalla erillisellä raudallaan. ENtä jos hyökkääjä pääsee virtualisoituun palomuuriin ja korkkaa sen, silloin hänellähän on pääsy muihinkin virtuaalikoneisiin

 

[dataaja95]

BSD-pohjaisella systeemillä et pääse apu2:lla gigabitin nopeuteen tällä hetkellä yhden striimin reitityksessä, koska se reititys pyörii käytännössä yhdellä corella. Linux-pohjaisella systeemillä tuo ei ole ongelma. Aikanaan mietin itse apu2d4:n ja fitlet2:n välillä ja valitsin apu2d4:n, koska sillä saa täysin open source -pohjaisen järjestelmän ja tuli myös halvemmaksi.

Esim. täällä pieni benchmarkki tästä reitityskyvystä.

Pyörittääkö siis bsd reititykset aina yhden coren kautta ja samoin ips:n, muistaakseni tuo meni toisinpäin, eli bsd osaa hyödyntä multicoreja ja linux ei, vai onko asia näin. Hyödyntääkö esim suricata prosessorin kaikkia ytimiä.

 

[Pörkyle]

Olisiko järkevää virtualisoida nyt käytössä oleva opnsense, itselleni on tulossa proxmox virtualisointiklusteri kolmella koneella ja tuossahan saisi näppärästi ajettua opnsenseäkin, jos ensimmäinen kone hajoaisi siirtyisi palomuuri pyörimään toisella hostilla, näimpä katkoksia verkkoon ei tulisi. Mietinkin tässä lähinnä tietoturvakysymyksiä, itse olen tottunut pitämään aina palomuurin omalla erillisellä raudallaan. ENtä jos hyökkääjä pääsee virtualisoituun palomuuriin ja korkkaa sen, silloin hänellähän on pääsy muihinkin virtuaalikoneisiin

Käsiittääkseni ei ole suositeltavaa toteuttaa palomuuria virtuaalisesti paitsi kehitys/testaus tarkoituksissa. Lisäksi tuo varmasti vaan vaikeuttaa ongelmatilanteissa vian löytämistä. Toisaalta voi myös luoda uusia ongelmatilaneita.

Virtual Environments - The IPFire Documentation

wiki.ipfire.org

Lisäksi proxmoxissa itsessänkin on kattavat palomuuri säädöt ja verkon voi säätää reitittävään tilaan mutta en ehkä lähtisi silläkään suodattamaan internet yhteyttä Proxmoxin ulkopuolisille koneille.

Network Configuration - Proxmox VE

pve.proxmox.com

Proxmox VE Firewall

Mutta jokainenhan on vapaa omassa verkossa tekemään asiat niinkuin haulaa mutta itse ehkä pitäisin opnsensen omalla koneellaan ja voihan proxmoxissa olla toinen opnsense pyörimässä eri juttujen testaamista varten.

 

[antero]

Samasta syystä itsekin tutkiskelin siirtyväni pfSensestä OPNsenseen, lisäpainoa johtuen pfSensen forkkaukseen CE ja Plus version välillä. Toki CE versiossa on aina ollut eroa retail-versioon, mutta mielestäni tuossa selvästi pyritään jättämään "ilmaisversion" kehitystä taka-alalle ja panostamaan yh....}

Nyt ce versio on saanu jonki päivitys buustin, liekö suunnitelmat muuttunu että CE tuodaan 23.05 kanssa.
Tapahtumat - pfSense - pfSense bugtracker

 

[JeanS]

Minulla on outoja nettiyhteysongelmia ja vaikuttaa liittyvän DNS kyselyihin. PfSense on käytössä, mutta olen kokeillut ohittaa sen (pelkkä modeemin palomuuri käytössä). Ja olen testannut kolmea eri 4G tai 5G modeemia router sekä bridged moodeissa. Operaattorina DNA. Eli sinänsä tämä ei ole pfSense ongelma.
Ongelma on että DNS kyselyt kestää välillä todella kauan, esim. ping www.google.com tms tulee timeout välillä. Siis DNS kysely toimii välillä normaalisi ja välilllä kestää todella kauan tai epäonnistuu täysin. Diagnostic -> DNS Lookup on välillä 5+ sekunttia tai jopa no response. Ehkä puolet DNS kyselyistä onnistuu normaalisti.
DNS servereinä on 8.8.8.8, 1.1.1.1, 9.9.9.9 ja 208.67.222.222 (olen kokeillut jopa eri järjestä).
Asetuksista olen kokeillut eri arvoilla:
- DNS Resolution Behaviour
- DNS Server Override
Olisko vielä joku asetus mitä kokeilla?

Samoja ongelmia verkossa olevassa Windows läppärissä, sekä virtuaalikoneessa pyörivässä Ubuntu serverissä.

Ja erityisesti Speedtest:issä on ongelmia, menee hyvin harvoin läpi.

Ja onko mitään ideaa mistä ongelmat johtuu?

 

[Asiantuntija]

Minulla on outoja nettiyhteysongelmia ja vaikuttaa liittyvän DNS kyselyihin. PfSense on käytössä, mutta olen kokeillut ohittaa sen (pelkkä modeemin palomuuri käytössä). Ja olen testannut kolmea eri 4G tai 5G modeemia router sekä bridged moodeissa. Operaattorina DNA. Eli sinänsä tämä ei ole pfSense ongelma.
Ongelma on että DNS kyselyt kestää välillä todella kauan, esim. ping www.google.com tms tulee timeout välillä. Siis DNS kysely toimii välillä normaalisi ja välilllä kestää todella kauan tai epäonnistuu täysin. Diagnostic -> DNS Lookup on välillä 5+ sekunttia tai jopa no response. Ehkä puolet DNS kyselyistä onnistuu normaalisti.
DNS servereinä on 8.8.8.8, 1.1.1.1, 9.9.9.9 ja 208.67.222.222 (olen kokeillut jopa eri järjestä).
Asetuksista olen kokeillut eri arvoilla:
- DNS Resolution Behaviour
- DNS Server Override
Olisko vielä joku asetus mitä kokeilla?

Samoja ongelmia verkossa olevassa Windows läppärissä, sekä virtuaalikoneessa pyörivässä Ubuntu serverissä.

Ja erityisesti Speedtest:issä on ongelmia, menee hyvin harvoin läpi.

Ja onko mitään ideaa mistä ongelmat johtuu?

Itse yhteys ei siis pätki? Miten olet varmistanut sen? Näkyykö pfsensessä gatewayn RTT, RTTsd tai loss nousevan samaan aikaan kun pätkii?
Jätä vaikka windowskoneessa komentoriville ping pyörimään ja katso jumittaako sekin samaan aikaan kun dns. widowsissa 'ping 8.8.8.8 -t' tai linuxissa 'ping 8.8.8.8'

 

[JeanS]

Mun pfSense setupissa on kaksi WAN:ia. DNA:n 5G sekä taloyhtiön kiinteä.
Jos laitan taloyhtiön WAN liittymän Tier1 ja DNA liittymän Tier2 (Failover), niin ei ole DNS tai muitakaan ongelmia. Mutta nopeudet on n 80/25Mbit/s.
Mutta jos laitan molemmat Tier1 (loadbalancing) tai vain DNA Tier1 (Failover), niin alkaa ongelmat. Toi loadbalancing konffi on aavistuksen parempi.
Jos saan menemään speedtestin läpi tossa DNA konfiksessa, niin nopeudet DL 150-300Mbit/s ja UL 70-80Mbit/s. Mutta liittymä on 600Mbit/s ja modeemikin pitäisi kyetä 800Mbit/s.
Signaalin voimakkuus on ok, RSSI n.-60dBm. Kaksi DNA tukiasemaa on n 500m etäisyydellä, vastakkaisissa suunnissa. Eli sijainti on just noiden solujen välissä. Edellinen modeemi jota kokeilin ei saanut edes 5G yhteyttä päälle (RUTX50). Oisko syynä tämä sijainti?
Tässä tarkemmet solun parametrit.

Ja itse DNS ongelma, eli satunnaisesti tollaisia 5sek+ viiveitä vaikkei olisi mitään isompaa liikennettä taustalla.
Status -> Gateways näyttää välillä parin prosentin packet lossia tolle DNA WAN:illa, mutta viiveet on mielestäni normaalit.
Ping toimii yleensä, mutta tulee välillä timeout varsinkin jos yrittää pingata DNS osoiteella johonkin uuteen osoitteeseen, esim.
C:\Users\jansu>ping www.microsoft.com
Ping request could not find host www.microsoft.com. Please check the name and try again.

C:\Users\jansu>ping www.microsoft.com
Pinging e13678.dscb.akamaiedge.net [95.100.141.130] with 32 bytes of data:
Reply from 95.100.141.130: bytes=32 time=40ms TTL=55
Reply from 95.100.141.130: bytes=32 time=60ms TTL=55
Reply from 95.100.141.130: bytes=32 time=37ms TTL=55
Reply from 95.100.141.130: bytes=32 time=31ms TTL=55

Ping statistics for 95.100.141.130:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 31ms, Maximum = 60ms, Average = 42ms
C:\Users\jansu>ping www.aamulehti.fi

Pinging www-aamulehti-fi.prod.sanoma-sndp.fi [108.156.12.55] with 32 bytes of data:
Request timed out.
Reply from 108.156.12.55: bytes=32 time=14ms TTL=247
Reply from 108.156.12.55: bytes=32 time=16ms TTL=247

Alla esimerkki parista CLI speedtest ajosta:
C:\Users\jansu>speedtest.exe

Speedtest by Ookla

Server: Blue Lake Communications Oy - Savonlinna (id: 15528)
ISP: Google Cloud
Idle Latency: 63.19 ms (jitter: 7.43ms, low: 59.71ms, high: 73.11ms)
Download: 106.27 Mbps (data used: 133.0 MB)
29.37 ms (jitter: 6.25ms, low: 22.88ms, high: 158.28ms)
Upload: FAILED cy: 29.37 ms
[error] Cannot open socket

C:\Users\jansu>speedtest.exe

Speedtest by Ookla

[error] Error: [0] Unknown error
[error] Error: [0] Unknown error
[error] Error: [0] Unknown error
[error] Error: [0] Cannot open socket
[error] (null). WSA Error of type 11001 with message `╕vΦ
[error] Error: [11001] No such host is known.

[error] (null). WSA Error of type 11001 with message `⌠vΦ
[error] Error: [11001] No such host is known.

[error] (null). WSA Error of type 11001 with message ≡ó♫vΦ
[error] Error: [11001] No such host is known.

[error] (null). WSA Error of type 11001 with message á≡vΦ
[error] Error: [11001] No such host is known.

[error] (null). WSA Error of type 11001 with message ░└◄vΦ
[error] Error: [11001] No such host is known.

Server: TNNet Oy - Jyvaskyla (id: 23317)
ISP: DNA Oyj
[error] Error: [0] Cannot open socket
[error] Latency test failed

Speedtestissäkin auttaa jos yrittää uudestaan heti perään.

Eli olisko kyseessä kuitenkin mobiiilityhteysongelma tai DNA kiinteän verkon, eikä pfSensen asetus?

 

[Pörkyle]

Minulla on outoja nettiyhteysongelmia ja vaikuttaa liittyvän DNS kyselyihin. PfSense on käytössä, mutta olen kokeillut ohittaa sen (pelkkä modeemin palomuuri käytössä). Ja olen testannut kolmea eri 4G tai 5G modeemia router sekä bridged moodeissa. Operaattorina DNA. Eli sinänsä tämä ei ole pfSense ongelma.
Ongelma on että DNS kyselyt kestää välillä todella kauan, esim. ping www.google.com tms tulee timeout välillä. Siis DNS kysely toimii välillä normaalisi ja välilllä kestää todella kauan tai epäonnistuu täysin. Diagnostic -> DNS Lookup on välillä 5+ sekunttia tai jopa no response. Ehkä puolet DNS kyselyistä onnistuu normaalisti.
DNS servereinä on 8.8.8.8, 1.1.1.1, 9.9.9.9 ja 208.67.222.222 (olen kokeillut jopa eri järjestä).
Asetuksista olen kokeillut eri arvoilla:
- DNS Resolution Behaviour
- DNS Server Override
Olisko vielä joku asetus mitä kokeilla?

Samoja ongelmia verkossa olevassa Windows läppärissä, sekä virtuaalikoneessa pyörivässä Ubuntu serverissä.

Ja erityisesti Speedtest:issä on ongelmia, menee hyvin harvoin läpi.

Ja onko mitään ideaa mistä ongelmat johtuu?

Onko liittymä miten vanha? Jos data.dna.fi vielä käytössä niin kannattaa vaihtaa se julkinen.dna.fi APN:ään. Vaikka minunkin liittymä hommattu ennen 2016 niin pätkimiset väheni kun vaihdoin tuohon julkinen apn:ään. Tosin siihen saattoi sekin vaikuttaa kun minulla on TLS protokola käytössä DNS hauissa jotka menee 853 portin kautta ja tuo data.dna on huomattavasti rajoitetumpi porttien osalta.

Spoileri

Yhteysosoitteet ja IP-osoitteet
Kaikki DNA:n Liikkuva laajakaista -liittymät ja näin ollen myös DNA:n mokkulat toimitetaan ns. osoitteenmuunnoksella (NAT). NAT-osoitteenmuunnosta IPv4 puolella käyttävillä liittymillä voidaan käyttää sovelluksia, jotka avaavat itse yhteyden Internetissä sijaitsevaan palvelimeen päin (esimerkiksi: http(s), telnet, ssh, irc, ftp).

Jos liittymäsi ja päätelaitteesi toimivat hyvin, sinun ei tarvitse tehdä mitään muutoksia. Jos tarvitset julkisen IPv4-osoitteen, tämä onnistuu helposti vaihtamalla päätelaitteen APN asetuksia. Julkista IPv4:tä voidaan tarvita esimerkiksi kotiserverin, peliserverin tai turvakameroiden kanssa.

Päällä oleva NAT-osoitteenmuunnosta käyttävä APN-yhteyspiste (oletuksena joulukuusta 2016 lähtien) on:

internet (Sisältää yhden NAT-osoitemuunnetun, vaihtuvan IPv4-osoitteen ja yhden julkisen vaihtuvan 64-bittisen IPv6-verkon.)

Saadaksesi käyttöön julkisen IPv4-osoitteen sinun on vaihdettava päätelaitteeseen (mokkula, mobiilireititin, SIM-kortillinen kamera, jne.) seuraava APN-yhteyspiste:

julkinen.dna.fi (Sisältää yhden julkisen, vaihtuvan IPv4-osoitteen ja yhden julkisen, vaihtuvan 64-bittisen IPv6-verkon.)

Jos liittymäsi on hankittu ennen joulukuuta 2016, sillä voi olla käytössä alla oleva APN-yhteysosoite, mikä antaa edelleen julkisen IPv4-osoitteen:

data.dna.fi (Sisältää yhden julkisen, vaihtuvan IPv4-osoitteen ja yhden julkisen, vaihtuvan 64-bittisen IPv6-verkon.)

DNA Koti 5G - ja DNA Dataprepaid -liittymät saavat aina yhden julkisen, vaihtuvan IPv4-osoitteen ja yhden julkisen, vaihtuvan 64-bittisen IPv6-verkon.

HUOM! Suositeltu APN on aina data.dna.fi silloin, kun mokkulassa on yritysliittymä ja kuluttajaliittymissä, kun liittymä on hankittu ennen joulukuuta 2016.

Sallitut portit DNA kuluttajaliittymille (yhteyspiste julkinen.dna.fi), DNA Koti 5G- ja DNA Dataprepaid -liittymille
Julkisia IPv4- ja IPv6-osoitteita käytettäessä liikennettä rajoitetaan seuraavasti:
(huom. myös NAT-liittymissä IPv6 on julkinen)

Estetyt portit (IPv4 ja IPv6):

• 25 UL (TCP)
• 53 DL (UDP)
• 123 DL (UDP)
• 1900 DL (UDP)
• 7547 UL/DL (TCP)

Lähtevä sähköpostiliikenne (SMTP-liikenne) liittymästä porttiin 25 on sallittu vain DNA:n omille SMTP-palvelimille Traficomin määräyksen mukaan.

DNA on jatkanut portin 7547 suodatusta, vaikka virallinen suositus on päättynyt.

UL tarkoittaa päätelaitteelta Internetiin suuntautuvaa liikennettä ja DL Internetistä päätelaitteelle suuntautuvaa liikennettä.

Palvelinosoitteet:

• DNA:n SMTP-sähköpostipalvelimen osoite on smtp.dnainternet.fi
• DNA:n NTP-aikapalvelimen osoite on ntp.dnainternet.fi
• DNA:n DNS-nimipalvelimien IPv4-osoitteet: 62.241.198.245 ja 62.241.198.246
• DNA:n DNS-nimipalvelimien IPv6-osoitteet: 2001:14b8:1000::1 ja 2001:14b8:1000::2

Sallitut portit DNA yritysliittymille ja kuluttajaliittymille, jotka on hankittu ennen joulukuuta 2016 (yhteyspiste data.dna.fi):
Julkisia IPv4- ja IPv6-osoitteita käytettäessä liikennettä rajoitetaan seuraavasti:
(Huom. myös NAT-liittymissä IPv6 on julkinen)

Estetyt TCP-portit (IPv4):

25 UL (Katso tarkennus alta)
1-499 DL
501-1023 DL
7547 UL/DL

Estetyt UDP-portit (IPv4):

1-122 DL
124-258 DL
260-499 DL
501-1023 DL
1900 DL

Estetyt portit (IPv6):

25 UL (TCP) (Katso tarkennus alta)
53 DL (UDP)
1900 DL (UDP)
7547 UL/DL (TCP)
Lähtevä sähköpostiliikenne (SMTP-liikenne) liittymästä porttiin 25 on sallittu vain DNA:n omille SMTP-palvelimille Traficomin määräyksen mukaan.

DNA on jatkanut portin 7547 suodatusta, vaikka virallinen suositus on päättynyt.

UL tarkoittaa päätelaitteelta Internetiin suuntautuvaa liikennettä ja DL Internetistä päätelaitteelle suuntautuvaa liikennettä.

Palvelinosoitteet:

• DNA:n SMTP-sähköpostipalvelimen osoite on smtp.dnainternet.fi
• DNA:n NTP-aikapalvelimen osoite on ntp.dnainternet.fi
• DNA:n DNS-nimipalvelimien IPv4-osoitteet: 62.241.198.245 ja 62.241.198.246
• DNA:n DNS-nimipalvelimien IPv6-osoitteet: 2001:14b8:1000::1 ja 2001:14b8:1000::2

Toimiiko pelkästään DNA:n omilla DNS palvelimilla onglemitta? Jos DNSSEC päällä on myös mahdollista että jokin noista palvelimista aiheuttaa konfliktin johtuen esim DNS palvelun omista suodattimista. Ainakin tuo OpenDNS ja Quad9 on "not recomended" listalla IPFiren wikissä. Luulisi saman pätevän PfSenseenkin DNSSECiä käyttäessä.

List of Public DNS Servers - The IPFire Documentation

wiki.ipfire.org

 

[HikinenM]

Kokeile laittaa DNS resolver forwarding modeen ja kyselyt DNS palvelimelle johon luotat. Mullakin oli vähän väliä todella pitkiä miettimistaukoja (5-10s) kun Unbound teki aina itse raskaan työn, kunnes tein tuon vaihdon. DNS resolver forwarding modessa siksi, koska Unbound pitää tällöin paikallista cachea, kun DNS forwarder ei pidä.

E: Jos välttämättä haluaa pitää DNS resolverina eikä halua kolmannen osapuolen näkevän DNS kyselyitä, niin voi kokeilla laittaa Advanced resolver optionsista Prefetch Support, Prefetch DNS Key Support ja Serve Expired päälle ja katsoa jos se auttaa (ei auta heti).

Services — DNS Resolver — DNS Resolver Advanced Options | pfSense Documentation

docs.netgate.com

 

[JeanS]

Kiitokset vinkeistä, sain pfSensen ja DNS kyselyt pelittämään!
Olen sen verran uusi pfSensen käyttäjä, etten hoksannut edes tarkistaa noita Services alla olevia DNS asetuksia.
Muutokset jolla sain toimimaan:
System -> General Setup:
- otin kaikki manuaalisesti määritetyt DNS serverit pois
- laitoin päälle 'DNS Server Override'
- vaihdoin DNS resolution: Use local DNS, fall back to remote DNS servers

Muita DNS asetuksia:
Services -> Enable DNS forwarder ei ollut päällä.
Mutta Enable DNS resolver oli päällä, ja myös DNSSEC Support. En ole varma oliko nämä default asetuksia, vaiko joskus aikaisemmin laittanut päälle.

APN oli julkinen.dna.fi ja SIM kortti & liittymä muutaman vuoden vanha, mutta reilusti uudempi kuin 2016. Hiljattain nostin liittymän nopeuden 4G - 150Mbit/s -> 5G - 600Mbit/s, mutta SIM pysyi samana.
Aloin epäilemään että joku tässä muutoksessa meni pieleen DNA:lla, kun nämä ongelmat alkoi samoihin aikoihin.

Eli tällä hetkellä DNS kyselyt toimii luotettavasti, eikä ongelmia speedtestissä paitsi DL nopeus hieman alakanttiin, n. 200Mbit/s. Täytyy ihmetellä lisää kun saan oman rautapurkin tolle pfSense:lle (nyt pyörii virtuaalikoneessa). Ja LoadBalancing konffi näyttäisi olevan aavistuksen hitaampi kuin Failover (johtuen hitaasta kakkos WAN:ista?)

 

[dataaja95]

Tarkoituksena olisi uudistaa palomuuripurkkia ja kahdentaa kyseinen masiina, nyt muurina toimii fitpc joka on muuten oikein mukava, mutta ips:ää lähinnä suricataa käytettäessä sekä vpn:iä suorituskyky romahtaa täysin aes/ni puutteen takia, kyseinen muuri olisi tulossa 1000/100mbps yhteydelle ja toiveena olisi, että se pystyisi reitittämään yhteyttä täydellä kapasiteetilla myös ips:n ollessa käytössä, kyseisen muurin taakse tulee ulkoverkkoon hostattavia palveluita, siksi suricata käytössä, verkkoliitäntöjä olisi hyvä olla kolme tai neljä ja masiina olisi mielellään äänetön, mutta hiljainen tuulettimien humina ei haittaa, olisiko näin raskaaseen käyttöön jo parempi rakentaa itse perusraudasta pc palomuurikoneeksi kuin katsoa muita vaihtoehtoja. Muureja tulisi siis kaksi kahdentamaan toisiaan, jos ensimmäinen muuri menee alas.. Käyttöjärjestelmäksi tuohon tulisi ihan perus opnSense tai openbsd, mitä arvon raati suosittelee tähän käyttötarkoitukseen.

 

[escalibur]

Tarkoituksena olisi uudistaa palomuuripurkkia ja kahdentaa kyseinen masiina, nyt muurina toimii fitpc joka on muuten oikein mukava, mutta ips:ää lähinnä suricataa käytettäessä sekä vpn:iä suorituskyky romahtaa täysin aes/ni puutteen takia, kyseinen muuri olisi tulossa 1000/100mbps yhteydelle ja toiveena olisi, että se pystyisi reitittämään yhteyttä täydellä kapasiteetilla myös ips:n ollessa käytössä, kyseisen muurin taakse tulee ulkoverkkoon hostattavia palveluita, siksi suricata käytössä, verkkoliitäntöjä olisi hyvä olla kolme tai neljä ja masiina olisi mielellään äänetön, mutta hiljainen tuulettimien humina ei haittaa, olisiko näin raskaaseen käyttöön jo parempi rakentaa itse perusraudasta pc palomuurikoneeksi kuin katsoa muita vaihtoehtoja. Muureja tulisi siis kaksi kahdentamaan toisiaan, jos ensimmäinen muuri menee alas.. Käyttöjärjestelmäksi tuohon tulisi ihan perus opnSense tai openbsd, mitä arvon raati suosittelee tähän käyttötarkoitukseen.

Itse harkitsisin Shuttlea. Tein kokonaisen videon eri rautavaihtoehdoista eri hintakategorioissa. En ehkä stressaisi liikaa porttien perään, vaan käyttäisin kytkintä reitittimen perässä.

 

[kya]

Tarkoituksena olisi uudistaa palomuuripurkkia ja kahdentaa kyseinen masiina, nyt muurina toimii fitpc joka on muuten oikein mukava, mutta ips:ää lähinnä suricataa käytettäessä sekä vpn:iä suorituskyky romahtaa täysin aes/ni puutteen takia, kyseinen muuri olisi tulossa 1000/100mbps yhteydelle ja toiveena olisi, että se pystyisi reitittämään yhteyttä täydellä kapasiteetilla myös ips:n ollessa käytössä, kyseisen muurin taakse tulee ulkoverkkoon hostattavia palveluita, siksi suricata käytössä, verkkoliitäntöjä olisi hyvä olla kolme tai neljä ja masiina olisi mielellään äänetön, mutta hiljainen tuulettimien humina ei haittaa, olisiko näin raskaaseen käyttöön jo parempi rakentaa itse perusraudasta pc palomuurikoneeksi kuin katsoa muita vaihtoehtoja. Muureja tulisi siis kaksi kahdentamaan toisiaan, jos ensimmäinen muuri menee alas.. Käyttöjärjestelmäksi tuohon tulisi ihan perus opnSense tai openbsd, mitä arvon raati suosittelee tähän käyttötarkoitukseen.

Mä katselisin tohon noita Decison omia purkkeja tyyliin DEC740 (tai räkkiversio DEC2750) kun puhutaan HA-setupista ja hostattavien palveluiden ajamisesta.

 

[dataaja95]

Itse harkitsisin Shuttlea. Tein kokonaisen videon eri rautavaihtoehdoista eri hintakategorioissa. En ehkä stressaisi liikaa porttien perään, vaan käyttäisin kytkintä reitittimen perässä.

Mikäs tuon shuttlen malli oikein oli, joskus tuosta luin ja vaikutti pätevältä, segmentoin verkon muutenkin vlaneilla, joten porttien määrä ei ole olennainen kynnyskysymys.

 

[dataaja95]

Editoidaas turha viesti pois

 

[escalibur]

Mikäs tuon shuttlen malli oikein oli, joskus tuosta luin ja vaikutti pätevältä, segmentoin verkon muutenkin vlaneilla, joten porttien määrä ei ole olennainen kynnyskysymys.

XPC-sarja. Myös Supermicrolla on loistavia vaihtoehtoja. En muista malleja ulkoa. Videolla näkyy tarkat mallit perusteluineen.

 

[dataaja95]

Mä katselisin tohon noita Decison omia purkkeja tyyliin DEC740 (tai räkkiversio DEC2750) kun puhutaan HA-setupista ja hostattavien palveluiden ajamisesta.

Olinkin unohtanut tämän vaihtoehdon kokonaan, kiitos tästä.

 

[JeanS]

Iloitsin liian aikaisin, ajoittain edelleen isoja ongelmia yhteyksissä. Ilmeisesti ongelmat ei liitykkään DNS kyselyihin, nslookup menee aina läpi.
Mutta jotain matalamman tason ongelmia. Wireshark logissa iso määrä TCP Syn hukkumisia, eli ei mene perille, tai vastaus siihen hukkuun. Myösköön pingeihin ei tule aina vastauksia, varsinkin jos on ns. uusi IP osoite.
Ja pingit ulkopuolelta omaan julkiseen IP:hen epäonnistuvat usein (käytän UpTimeRobot:ia).

Ilmeisesti jonkinlainen reititysongelma, joko omassa verkossa tai DNA:n.

Ihmettely jatkuu...

 

[dataaja95]

Täällä kun näyttää shuttletietäjiä olevan paikalla, niin kyselisin onko ds20U:ssa normaalipituista pcie paikkaa, shuttlen sivuilta tuo ei käy kovinkaan selkeästi ilmi, kovasti puhuvat vain m.2 ssd:n paikasta. Lisäksi minkälainen suorituskykyero on celeronilla ja i3:lla palomuurikäytössä. Yhteytenä tosiaan 1000/100, tarkoitus pyörittää suricataa sekä highavailability klusterointia kahdella opnsensellä ja myöskin verkosta ulospäin hostattavia palveluita ja saisi reitittää yhteyden täydeltä, sekä myöskin wireguard ja openvpn olisivat tulilla, kannattaisiko ottaa varmuudenvaralta i3, vai jaksaako celeron näin rankassa menossa mukana.

 

[MOS6510]

Fitlet 3 saapui vihdoin noin vuosi ja 2kk tilauksesta. Tuotanto on aloitettu pari kuukautta sitten ja purkavat nyt jonoa (joka on varmaankin pitkä).

Muutamia huomioita:
- On ulkoisesti jokseenkin identtinen Fitlet 2:n kanssa (mikä nyt oli toki tiedossa aikaisemminkin)
- Sisäiset verkkokortit perustuvat SOCin omiin sisäisiin verkkokortteihin ja lisäkorttina saatava 2:n portin Ethernet-kortti perustuu Intel i210:aan
- Kumpaakaan verkkokorttia ei perus ESXi-image tai Hyper-V Server 2019 tunnista - vaativat custom-imagea asennukseen

Alunperin tilasin tämän korvaamaan 5 vuotta käytössä olleen Fitlet 2:n Sophos XG-palomuurikäytössä, mutta taidan asentaa tähän ESXi:n ja siihen virtuaalikoneena Sophos XG:n ja toisena Home Assistantin. Tai sitten jätän Fitlet 2:n edelleen muuriksi - suorituskyvystähän tuo ei ole kiinni.

Erittäin laadukkaan oloinen ja hyvin tehty laite tämä(kin). Jos vain saa järkevällä toimitusajalla tilattua, niin suosittelen.

Tähänhän saa sisälle max. 32 GB DDR4-muistia sekä normaalimittaisen PCIe M.2-levyn. Lisäksi saa vielä toisen lyhyemmän M.2 Sata-levyn. Laite on täysin passiivinen ja siinä ei ole minkäänlaisia tuulettimia.

Fitlet3 - fit-PC wiki

fit-pc.com

 

[MOS6510]

Tarkoituksena olisi uudistaa palomuuripurkkia ja kahdentaa kyseinen masiina, nyt muurina toimii fitpc joka on muuten oikein mukava, mutta ips:ää lähinnä suricataa käytettäessä sekä vpn:iä suorituskyky romahtaa täysin aes/ni puutteen takia, kyseinen muuri olisi tulossa 1000/100mbps yhteydelle ja toiveena olisi, että se pystyisi reitittämään yhteyttä täydellä kapasiteetilla myös ips:n ollessa käytössä, kyseisen muurin taakse tulee ulkoverkkoon hostattavia palveluita, siksi suricata käytössä, verkkoliitäntöjä olisi hyvä olla kolme tai neljä ja masiina olisi mielellään äänetön, mutta hiljainen tuulettimien humina ei haittaa, olisiko näin raskaaseen käyttöön jo parempi rakentaa itse perusraudasta pc palomuurikoneeksi kuin katsoa muita vaihtoehtoja. Muureja tulisi siis kaksi kahdentamaan toisiaan, jos ensimmäinen muuri menee alas.. Käyttöjärjestelmäksi tuohon tulisi ihan perus opnSense tai openbsd, mitä arvon raati suosittelee tähän käyttötarkoitukseen.

Minulla on vastauksena kaikkeen tällaiseen Fitlet 3. Laadukkaita laitteita, joihin löytyy bios-päivityksiä vuosia ja hyvä tuki.

 

[dataaja95]

Fitlet 3 saapui vihdoin noin vuosi ja 2kk tilauksesta. Tuotanto on aloitettu muutamia viikkoa sitten ja purkavat nyt jonoa (joka on varmaankin pitkä).

Muutamia huomioita:
- On ulkoisesti jokseenkin identtinen Fitlet 2:n kanssa (mikä nyt oli toki tiedossa aikaisemminkin)
- Sisäiset verkkokorit ovat Marvell-pohjaisia ja lisäkorttina saatava 2:n portin Ethernet-kortti perustuu Intel i210:aan
- Kumpaakaan verkkokorttia ei perus ESXi-image tai Hyper-V Server 2019 tunnista - vaativat custom-imagea asennukseen

Alunperin tilasin tämän korvaamaan 5 vuotta käytössä olleen Fitlet 2:n Sophos XG-palomuurikäytössä, mutta taidan asentaa tähän ESXi:n ja siihen virtuaalikoneena Sophos XG:n ja toisena Home Assistantin. Tai sitten jätän Fitlet 2:n edelleen muuriksi - suorituskyvystähän tuo ei ole kiinni.

Erittäin laadukkaan oloinen ja hyvin tehty laite tämä(kin). Jos vain saa järkevällä toimitusajalla tilattua, niin suosittelen.

Mikäs prosessori tuossa fitlet 3:ssa oikein on, jaksaako reitittää 1000/100 yhteyttä suricatan kanssa, tuohan voisi olla myös yksi vaihtoehto shuttlen lisäksi omaan palomuuriprojektiini, tarkoitus siis uudistaa nykyinen fitpc:hen perustuva palomuuri suorituskyvyn takia, ja kahdentaa muuri opnsense HA setupilla.

 

[dataaja95]

Minulla on vastauksena kaikkeen tällaiseen Fitlet 3. Laadukkaita laitteita, joihin löytyy bios-päivityksiä vuosia ja hyvä tuki.

Mitä bsd pohjaiset jakelut tykkäävät marvelin verkkokorteista, sääntönä ainakin aijemmin on ollut, että inteliä kehiin.

 

[user9999]

Mitä bsd pohjaiset jakelut tykkäävät marvelin verkkokorteista, sääntönä ainakin aijemmin on ollut, että inteliä kehiin.

Ainakin Netgate 1100 ja 2100 malleissa on Marvell 88E6141 networking switch. En sen tarkemmin tiedä.

 

[dataaja95]

Tuota fitlet 3:a näyttäisi olevan saatavila kolmella eri prosessorikokoonpanolla, mitkä prosessorien erot ovat ja mikä niistä on suorituskykyisin.

fitlet3 – Compulab Nordic

www.compulabnordic.dk

 

[dataaja95]

Taitaapa tuo fitlet 3 jaksaa reitittää 1000/100 kuitua täydellä vauhdilla ja ips-päällä, tässä netgaten purkissa taitaa olla suorituskyvyltään samaa tasoa vastaava prosessori, nyt vaikuttaa hyvältä, seuraava kysymys on vain millä prosessorilla tuon fitletin otan, atom vaiko jompikumpi celeroneista ja mistä olisi järkevintä tilata.

Tuoteryhmät - BCC Solutions Oy

Tarjoamme tuhansien tuotteiden valikoiman maailman parhailta brändeiltä – aina kilpailukykyiseen hintaan ja hyvällä palvelulla höystettynä.

www.bccsolutions.fi

 

[escalibur]

Mitä bsd pohjaiset jakelut tykkäävät marvelin verkkokorteista, sääntönä ainakin aijemmin on ollut, että inteliä kehiin.

Ajurituki saattaa vaihdella jonkin verran. Itse en ostaisi mitään sokkona, ellet tietty halua toimia jonkinlaisena beta(testaajana).

Omassa Shuttlessa on 8 vuotta vanha Celeron 3855U ja se ainakin jaksoi käsitellä 1000/500 kuitua.

Suricatasta en stressaisi liikaa, koska kyseessä on palvelu jota en muutenkaan suosittele käytettäväksi. Suricata voi olla pätevä työkalu, jos on on aikaa ja energiaa olla jatkuvasti muuttamassa sääntöjä sen mukaan kun jokin nettipalvelu tai sovellus ei toimi oikein. Kyseessä ei siis ole "ota käyttöön ja unohda"-ratkaisu.

 

[MOS6510]

Mikäs prosessori tuossa fitlet 3:ssa oikein on, jaksaako reitittää 1000/100 yhteyttä suricatan kanssa, tuohan voisi olla myös yksi vaihtoehto shuttlen lisäksi omaan palomuuriprojektiini, tarkoitus siis uudistaa nykyinen fitpc:hen perustuva palomuuri suorituskyvyn takia, ja kahdentaa muuri opnsense HA setupilla.

Fitlet 3:ssa on Atom x6425E , joka on noin 2x nopeampi kuin Fitlet 2:n J3455. Itselläni on ollut Fitlet 2 gigaisen muurin kanssa viiden vuoden ajan ilman ongelmia. Tosin minulla ei ole päällä mitään IPS tms. ominaisuuksia.

 

[MOS6510]

Taitaapa tuo fitlet 3 jaksaa reitittää 1000/100 kuitua täydellä vauhdilla ja ips-päällä, tässä netgaten purkissa taitaa olla suorituskyvyltään samaa tasoa vastaava prosessori, nyt vaikuttaa hyvältä, seuraava kysymys on vain millä prosessorilla tuon fitletin otan, atom vaiko jompikumpi celeroneista ja mistä olisi järkevintä tilata.

Tuoteryhmät - BCC Solutions Oy

Tarjoamme tuhansien tuotteiden valikoiman maailman parhailta brändeiltä – aina kilpailukykyiseen hintaan ja hyvällä palvelulla höystettynä.

www.bccsolutions.fi

Minä tilaisin suoraan valmistajalta (näin tein itsekin):

fitlet3 - build-to-order

fit-iot.com

 

[MOS6510]

Tuota fitlet 3:a näyttäisi olevan saatavila kolmella eri prosessorikokoonpanolla, mitkä prosessorien erot ovat ja mikä niistä on suorituskykyisin.

fitlet3 – Compulab Nordic

www.compulabnordic.dk

Suorituskykyisin on se Atom x6425E. Muita en edes harkitsisi.

 

[dataaja95]

Ajurituki saattaa vaihdella jonkin verran. Itse en ostaisi mitään sokkona, ellet tietty halua toimia jonkinlaisena beta(testaajana).

Omassa Shuttlessa on 8 vuotta vanha Celeron 3855U ja se ainakin jaksoi käsitellä 1000/500 kuitua.

Suricatasta en stressaisi liikaa, koska kyseessä on palvelu jota en muutenkaan suosittele käytettäväksi. Suricata voi olla pätevä työkalu, jos on on aikaa ja energiaa olla jatkuvasti muuttamassa sääntöjä sen mukaan kun jokin nettipalvelu tai sovellus ei toimi oikein. Kyseessä ei siis ole "ota käyttöön ja unohda"-ratkaisu.

TOki suricataa käytettäessä et voi mennä mentaliteetilla asenna ja unohda, mutta näkisin sen tärkeäksi osaksi, kun tarkoitus on hostata palveluja ulkoverkkoon päin.

 

[MOS6510]

Mitä bsd pohjaiset jakelut tykkäävät marvelin verkkokorteista, sääntönä ainakin aijemmin on ollut, että inteliä kehiin.

Tilaamalla laitteeseen sen kahden Ethernet-portin lisäkortin saa käyttöön 2 x Intel i210. Ja ne Marvellit voi jättää käyttämättä.

 

[dataaja95]

Fitlet 3:ssa on Atom x6425E , joka on noin 2x nopeampi kuin Fitlet 2:n J3455. Itselläni on ollut Fitlet 2 gigaisen muurin kanssa viiden vuoden ajan ilman ongelmia. Tosin minulla ei ole päällä mitään IPS tms. ominaisuuksia.

Jos jaksaisit testata suricataa ja katsoa romahtaako sen kanssa suorituskyky totaalisesti, jaksaako reitittää yhteyttä täydellä kapasiteetilla. Riippuen käyttämästäsi palomuuridistrosta tuon asentaminen ei ole mikään hirveä homma, jos siis vain testataan. Toki sääntöjen säätämiseen oikeaan tuotantokäyttöön saa kulumaan pienen ikuisuuden.

 

[MOS6510]

Jos jaksaisit testata suricataa ja katsoa romahtaako sen kanssa suorituskyky totaalisesti, jaksaako reitittää yhteyttä täydellä kapasiteetilla. Riippuen käyttämästäsi palomuuridistrosta tuon asentaminen ei ole mikään hirveä homma, jos siis vain testataan. Toki sääntöjen säätämiseen oikeaan tuotantokäyttöön saa kulumaan pienen ikuisuuden.

Sori, en jaksa. Käytän Sophos XG Homea ja en jaksa käyttää aikaa noiden open source-tuotteiden virittelyihin.

 

[SamCer]

Miten pfSensen BIND pitää konffata, että se toimis slavena domainille? Oon nyt tapellu sen kanssa tuntikaupalla, eikä se suostu toimimaan. Zone transfer toimii kyllä Ubuntu virtuaalikoneeseen, johon asensin BIND:in, mutta vaikka kuinka kopioin toimivan setupin pfSensen BIND:iin niin, silti se ei suostu ottamaan vastaan niitä zoneja.

 

[antero]

PfSense 23.05 Beta saatavilla,huomiona että päivityksen jälkeen poistui development version valinta mahdollisuus.
Eli voi olla ettei julkaista kuin yksi versio ennen lopullista julkaisua.
Tämähän on käytännössä virhekorjausversio 23.01, isompia uudistuksia siinä ei ole.

versio 23.05.b.20230427.2246

Pienellä varauksella kannattaa kokeilla, voi olla että joutuu palaamaan ei pysty palaamaan 23.01 versioon.


e: Näyttäisi olevan repo ongelma.
ERROR: It was not possible to determine pfSense-upgrade remote version

viimeistään editoimalla 23.05 päivitys onnistuu kun julkaisu on ajankohtainen.

 

[user9999]

System_Patches 2.2.2 julkaistu pfsense 23.01 versioon.

Jotain korjauksia

 

[antero]

Nyt näyttää päivitykset pelaavan normaalisti, mutta paluu 23.05-> 23.01 ei näytä olevan mahdollista.
Mitään elkeitä CE version tuomiseksi ei näytä olevan.
( OpenWRT toi myös pikapäivitysen vikojen vuoksi jos joku sitä käyttää. itsellä reitittimiessä)

Muttta jos komentokehotteessa jostain osoitteen tavoittamuudesta kertoo ei DNS tiedot välity reitittimille.

Tuolla voi tutkia tuleeko virhettä ajamalla palomuurissa

curl -vvv https://google.com

Selvittämättä jäi muuttiko päivitys jotain sääntöä, voi olisko joskus itselle tullu joku virhe määrittelyssä
DNS resolverin kanssa.

Edit. pitää vielä selvitellä mäöärityksiä, itsellä jos DNS resolver käytössä ei näytä päivittäminen olevan mahdollista.
tuo näytti aiheuttavan ainakin päivitysongelman jos valittuna. Tämä ei ollu alkuperäinen syy, vaan luultavasti virhe päivityspalvelimen päässä.

---------------------------------------------------

Itse tykkään tarkastella tällä sivulla, että eri liitännät varmasti saa sen dns ym. mitä olen halunnu.
dnscheck.tools - test your dns resolvers


edit2:

Kannattaa huomata että config päivittyy jälleen, joten asetusten tuomisessa voi olla jollakin ongelmia tai pieniä virheitä.
Eli backup asetuksista ennen päivitystä pakollinen.
Itse käyttäisin päivityksen jälkeen laitteesta kokonaan virrat pois, niin vaivat paljastuu heti eikä esim vuorokauden jälkeen.

 

[user9999]

pfSense Plus 23.05 beta julkaistu.

pfSense Plus Software Version 23.05 BETA Now Available

Announcement of pfSense Plus Software Version 23.05 BETA availability, including links to Release Notes, and guidance on how to report issues.

www.netgate.com

 

[McPaHa]

Aargh... nyt ei ymmärrä... Kovasti olen koittanut saada OpenVPN servua pystyyn pfsensessä mutta ei vaan nyt rokkaa...

Ensimmäiseksi nyt kummastuttaa sellainen juttu että DuckDNS kertoo eri ipv4 osoitteen kuin mitä pfsense näyttää WAN osoitteena. Ei ymmärrä?

Konffattu tämän ohjeen mukaan: Use DuckDNS to Set Up DDNS on pfSense in 2023

edit: Kyllä openvpn servun konffi toimii kun laitoin clienttiin oikean wan ip:n niin heittämällä sisään... Mikä he....ti tuossa nyt on ettei duckdns updeittaa julkista osoitetta?

edit2: Joo... kun löysin tuon duckin oman ohjeen niin alkoi pelittämään. Sorry tyhmä kyssäri.

 

[Pakana]

Aargh... nyt ei ymmärrä... Kovasti olen koittanut saada OpenVPN servua pystyyn pfsensessä mutta ei vaan nyt rokkaa...

Ensimmäiseksi nyt kummastuttaa sellainen juttu että DuckDNS kertoo eri ipv4 osoitteen kuin mitä pfsense näyttää WAN osoitteena. Ei ymmärrä?

Konffattu tämän ohjeen mukaan: Use DuckDNS to Set Up DDNS on pfSense in 2023

No tuo viittaa siihen että tuota duckdns:ää ei ole konffittu oikein, joten ei se vpn servukaan voi toimia.

Koita ensin konffia tuo duckdns niiden oman ohjeen mukaan, ja kun se toimii, jatka sen vpn kanssa painimista

 

[JeanS]

Vihdoinkin mun dataliittymän yhteysongelmat ratkesi. Olin kokeillut lukemattomia modeemia - firewall/reitinin kombinaatioita ja eri asetuksia.
Ongelmana oli joko DNS kyselyt ja TCP yhteyksien luonnit (Wireshark logissa paljon TCP-SYN uudelleenlähetyksiä).
Yhteys toimi muutaman tunnin ihan hyvin modeemin buuttauksen jälkeen, mutta pikkuhiljaa yhteys alkoi pätkimään.

Vika oli jossain DNA verkon asetuksessa joka tuli kun liittymän nopeutta nostettiin. Nyt on toiminut pari päivää ilman ongelmia. No tulihan tutuksi pfSense, OPNSense jne.

 

[antero]

Virallinen 23.05 julkaisu pitäisi tulla muutaman päivän sisään.
Jos on jotain päivitysongelmia kannattaa kokeilla dns resolveria laittaa pois päältä.
Jotain hämminkiä DNS käsittelyssä on ihan viimemetreillä ollu.

e. näköjään unbound sai päivityksen pikapäivityksessä.

 

[JeanS]

Huomasin itsekkin että yhteys / DNS kyselyt toimi hieman paremmin ilman DNS resolveria pfSense:ssä. Mutta nyt se on päällä, koska käytän sitä verkon sisäisiin DNS kyselyihin.
OPNSense:ssä oli hyvä lokistus noille DNS kyselyille jos se oli tehty DNS Resolverilla, muuten pfSense tuntuu tälläiselle aloittelijalle paremmalta.

Firewallin toimintaa en ole vielä ihan sisäistänyt.
System Log:issa näkyy joitain 'outoja' blokkauksia:
37.136.139.24 on WAN:in julkinen osoite.

May 16 18:38:13 WAN Default deny rule IPv4 (1000000103) 78.71.212.202:16129 37.136.139.24:16149 UDP
May 16 18:57:44 WAN Default deny rule IPv4 (1000000103) 91.107.235.152:42852 37.136.139.24:39050 TCP:S
=> Mulla on FluxNodeja ja UPnP käytössä -> noi 16149 ja 39050 portit pitäisi olla auki. Minulla on Pass rule porteille 16124:16179 sekä 30000-39999 (vain tietyt sisäiset IP osoitteet, eli vain FluxNodet). Näitä on paljon lokissa. En ymmärrä miksi jotkut portit blokataan vaikka on Pass rule.
Status -> UPnP & NAT-PMP: Toi 16149 on siellä.


May 16 18:45:31 LAN Default deny rule IPv4 (1000000103) 176.93.241.8:58883 239.255.255.250:1900 UDP
May 16 18:45:31 LAN (1000001470) 37.136.139.24:33078 239.255.255.250:1900 UDP
=> LAN interfaces on paljon UPnP:hen liittyviä blokkauksia, mutta minulla ei ole yhtään Reject/Block sääntöä LAN interfacessa.

 

[Ogeli]

Siirrytään tänne

Sama ongelma täällä Opnsensen ja dnan kanssa. Reititin kyllä saa osoitteen. Kokeilin jopa tehdä sisäverkkoon oman privaatti osoiteavaruuden, mutta joko oma osaaminen loppui kesken, tai tuota ei voi saada toimimaan.

Tuola on hieno ohje mutku ei

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

Onko Pfsensen hallintaportti muutettu johonkin muuhun kuin 443 -porttiin? Ei kai, mutta HAproxyn kanssa ehkä kannattaa Configuration — Advanced Configuration Options — Admin Access Tab | pfSense Documentation

bbs.io-tech.fi

Mulla jäi säädöt vaiheeseen mutta miten tuo /56 vaihdetaan /64?

 

[Pakana]

Huomasin itsekkin että yhteys / DNS kyselyt toimi hieman paremmin ilman DNS resolveria pfSense:ssä. Mutta nyt se on päällä, koska käytän sitä verkon sisäisiin DNS kyselyihin.
OPNSense:ssä oli hyvä lokistus noille DNS kyselyille jos se oli tehty DNS Resolverilla, muuten pfSense tuntuu tälläiselle aloittelijalle paremmalta.

Firewallin toimintaa en ole vielä ihan sisäistänyt.
System Log:issa näkyy joitain 'outoja' blokkauksia:
37.136.139.24 on WAN:in julkinen osoite.

May 16 18:38:13 WAN Default deny rule IPv4 (1000000103) 78.71.212.202:16129 37.136.139.24:16149 UDP
May 16 18:57:44 WAN Default deny rule IPv4 (1000000103) 91.107.235.152:42852 37.136.139.24:39050 TCP:S
=> Mulla on FluxNodeja ja UPnP käytössä -> noi 16149 ja 39050 portit pitäisi olla auki. Minulla on Pass rule porteille 16124:16179 sekä 30000-39999 (vain tietyt sisäiset IP osoitteet, eli vain FluxNodet). Näitä on paljon lokissa. En ymmärrä miksi jotkut portit blokataan vaikka on Pass rule.
Status -> UPnP & NAT-PMP: Toi 16149 on siellä.


May 16 18:45:31 LAN Default deny rule IPv4 (1000000103) 176.93.241.8:58883 239.255.255.250:1900 UDP
May 16 18:45:31 LAN (1000001470) 37.136.139.24:33078 239.255.255.250:1900 UDP
=> LAN interfaces on paljon UPnP:hen liittyviä blokkauksia, mutta minulla ei ole yhtään Reject/Block sääntöä LAN interfacessa.

Voisiko olla porttiskannaus?

Ei täytä logia jokaisesta porttiskannauksesta, mutta kun skannaus on edennyt noihin avoimiin portteihin on skannaava osoite jo blokattu ja sitä myötä tulee logiin ilmoitus?

Ainakin openwrt näköjään blokkaa porttiskannausta tekevän osoitteen aika pian kun havaitsee että joku joku käy porttejä läpi, mutta logeihin ei tule tuosta mitään ilmoitusta, vain skannaavaassa päässä huomaa että vastausta ei tule avoimistakaan porteista.

 

[sra2010]

Huomasin itsekkin että yhteys / DNS kyselyt toimi hieman paremmin ilman DNS resolveria pfSense:ssä. Mutta nyt se on päällä, koska käytän sitä verkon sisäisiin DNS kyselyihin.
OPNSense:ssä oli hyvä lokistus noille DNS kyselyille jos se oli tehty DNS Resolverilla, muuten pfSense tuntuu tälläiselle aloittelijalle paremmalta.

Firewallin toimintaa en ole vielä ihan sisäistänyt.
System Log:issa näkyy joitain 'outoja' blokkauksia:
37.136.139.24 on WAN:in julkinen osoite.

May 16 18:38:13 WAN Default deny rule IPv4 (1000000103) 78.71.212.202:16129 37.136.139.24:16149 UDP
May 16 18:57:44 WAN Default deny rule IPv4 (1000000103) 91.107.235.152:42852 37.136.139.24:39050 TCP:S
=> Mulla on FluxNodeja ja UPnP käytössä -> noi 16149 ja 39050 portit pitäisi olla auki. Minulla on Pass rule porteille 16124:16179 sekä 30000-39999 (vain tietyt sisäiset IP osoitteet, eli vain FluxNodet). Näitä on paljon lokissa. En ymmärrä miksi jotkut portit blokataan vaikka on Pass rule.
Status -> UPnP & NAT-PMP: Toi 16149 on siellä.


May 16 18:45:31 LAN Default deny rule IPv4 (1000000103) 176.93.241.8:58883 239.255.255.250:1900 UDP
May 16 18:45:31 LAN (1000001470) 37.136.139.24:33078 239.255.255.250:1900 UDP
=> LAN interfaces on paljon UPnP:hen liittyviä blokkauksia, mutta minulla ei ole yhtään Reject/Block sääntöä LAN interfacessa.

Voisiko kyseessä olla esim. jo sulkeutunut yhteys johon tulee virheellinen vastaus myöhässä? Tcp:s muistaakseni viittaa siihen suuntaan. Statefull palomuuri blockaa nuo yhteydet oletuksena, koska niille ei ole tarvetta.