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

escalibur · 17.12.2020

pfBlockerNG v3.0.0_6 on nyt ladattavissa:

Fix incorrect function name call
Add safety belt for DNS Python mode and the DNS Resolver OpenVPN Client Registration option.
Add a Phishing Army alternative feed.
Remove any empty < config >< /config > config.xml entries
DNSBL - NAT / Floating rule modifications when Localhost interface is selected
Preliminary DNSBL Group Policy configuration

Näyttäisi yhä kaatavan unbound-palvelun päivityksen päätteeksi. Asia on tiedossa ja pfSensella selvityksessä: Bug #10610: Package upgrade or reinstall hangs indefintely on the console - pfSense - pfSense bugtracker

sra2010 · 17.12.2020

escalibur sanoi:
pfBlockerNG v3.0.0_6 on nyt ladattavissa:

Näyttäisi yhä kaatavan unbound-palvelun päivityksen päätteeksi. Asia on tiedossa ja pfSensella selvityksessä: Bug #10610: Package upgrade or reinstall hangs indefintely on the console - pfSense - pfSense bugtracker

Tätä jo ehdin odotella. Tuossa pitäisi olla korjattuna oikeat portit tuohon dnsbl-nat sääntöön. Edellisessä versiossa yritti yhteyttä 443 portin kautta ja aiheuttaa palomuuri hälytyksiä, koska hallintaportit on estetty.

maninthemoon · 21.12.2020

Täällä oli aikaisemmin puhetta pfsensessä ajettavassa OpenVPN:ssä käyttäjäkohtaisista sertifikaateista. Tässä on nyt varmaan jotain mitä en ymmärrä. Olen tehnyt käyttäjille omat sertit (2 käyttäjää), ja kun exporttaa noi vpn profiilit wizardilla, niin ne kyllä näyttävät erilaisilta näiltä osin:
</ca>
<cert>
myös tämäkin osa
</cert>
<key>
sitten tämä on sama kummassakin sertissa:
</key>
<tls-crypt>
Nuo edellä olevat asia siis ilmenevät, kun avaa noi profiilit tekstinkäsittelyohjelmaan. Toivottavasti ymmärrätte mitä yritän tuoda tällä esiin.

OpenVPN pyörii puhelimessa ja jos importaaan käyttäjän 1 profiilin, mutta käytän käyttäjän 2 tunnuksia, niin läpi menee ja yhteys muodostuu. Olen itsellei antanut ymmärtää, että tämän ei pitäisi olla mahdollista, kun palvelimen päässä käytössä (server mode) on "Remote Access SSL/TSL + User Auth ".

Olenko siis ymmärtänyt tässä jotain totaalisen pieleen vai enkö vain osaa?

A Lake Elk · 21.12.2020

maninthemoon sanoi:
Täällä oli aikaisemmin puhetta pfsensessä ajettavassa OpenVPN:ssä käyttäjäkohtaisista sertifikaateista. Tässä on nyt varmaan jotain mitä en ymmärrä. Olen tehnyt käyttäjille omat sertit (2 käyttäjää), ja kun exporttaa noi vpn profiilit wizardilla, niin ne kyllä näyttävät erilaisilta näiltä osin:
</ca>
<cert>
myös tämäkin osa
</cert>
<key>
sitten tämä on sama kummassakin sertissa:
</key>
<tls-crypt>
Nuo edellä olevat asia siis ilmenevät, kun avaa noi profiilit tekstinkäsittelyohjelmaan. Toivottavasti ymmärrätte mitä yritän tuoda tällä esiin.

OpenVPN pyörii puhelimessa ja jos importaaan käyttäjän 1 profiilin, mutta käytän käyttäjän 2 tunnuksia, niin läpi menee ja yhteys muodostuu. Olen itsellei antanut ymmärtää, että tämän ei pitäisi olla mahdollista, kun palvelimen päässä käytössä (server mode) on "Remote Access SSL/TSL + User Auth ".

Olenko siis ymmärtänyt tässä jotain totaalisen pieleen vai enkö vain osaa?

Nyt kun ite testasin omassa luurissa (Androidin OpenVPN Connect), niin en pysty käyttämään ristiin noita certtejä, eli ne toimii käyttäjä kohtaisesti. Mulla on tosin lisänä vielä pfSensessä FreeRADIUS hoitamassa tuota käyttäjän autentikointia. Voin testata ilman tuota RADIUS:sta illempana, ellei joltakin muulta tuu mitään ideaa miksi sulla ne certit toimii ristiin...

maninthemoon · 21.12.2020

Tuli tässä vielä mieleen,että täytyykö käyttäjän alla olla sertifikaatti kerrottuna? Ainakin siinä tapauksessa täytyy,kun exporttaa vpn profiilin. Muuten ei tuota pysty tekemään. Kokeilin tätä myös niin, että poistin sertin käyttäjältä ja siltikin vpn yhdisti. Ajattelin, että kaikki tieto on kerrottu vpn profiilissa, niin sen takia menee läpi,mutta mahtaakohan olla näin?

Edit. Testasin myös niin, että muutin vpn profiilista jokusta kirjainta toiseen, niin se sentään ei toiminut.

maninthemoon · 21.12.2020

A Lake Elk sanoi:
Nyt kun ite testasin omassa luurissa (Androidin OpenVPN Connect), niin en pysty käyttämään ristiin noita certtejä, eli ne toimii käyttäjä kohtaisesti. Mulla on tosin lisänä vielä pfSensessä FreeRADIUS hoitamassa tuota käyttäjän autentikointia. Voin testata ilman tuota RADIUS:sta illempana, ellei joltakin muulta tuu mitään ideaa miksi sulla ne certit toimii ristiin...

Olisikohan nyt tämäki keissi selvinnyt. Täytyy testailla vielä, mutta toisen käyttäjän tunnuksilla en nyt pystynyt kirjautumaan vaan herjaa autetikoinnista. Pistin tähän ruksin. Jotenkin ei ole niin looginen (itselleni ainakaan), jos ylhäällä määritellään jo, että certi + user autetinkointi ja sitten vielä pitää jostain laittaa ruksi erikseen johonkin.

A Lake Elk · 21.12.2020

maninthemoon sanoi:
Olisikohan nyt tämäki keissi selvinnyt. Täytyy testailla vielä, mutta toisen käyttäjän tunnuksilla en nyt pystynyt kirjautumaan vaan herjaa autetikoinnista. Pistin tähän ruksin. Jotenkin ei ole niin looginen (itselleni ainakaan), jos ylhäällä määritellään jo, että certi + user autetinkointi ja sitten vielä pitää jostain laittaa ruksi erikseen johonkin.

Itellä ei oo tuota valintaa päällä, joten se ei taida olla sekään. Ja koitin nyt ilman FreeRADIUSsia, niin en voi käyttää ristiin noita certtejä ja tunnuksia siltikään. Onhan sulla User Managerissä määritelty vain yksi "User Certificate"/käyttäjä ja molemmille on varmasti eri certti?

kuukie · 21.12.2020

maninthemoon sanoi:
Olisikohan nyt tämäki keissi selvinnyt. Täytyy testailla vielä, mutta toisen käyttäjän tunnuksilla en nyt pystynyt kirjautumaan vaan herjaa autetikoinnista. Pistin tähän ruksin. Jotenkin ei ole niin looginen (itselleni ainakaan), jos ylhäällä määritellään jo, että certi + user autetinkointi ja sitten vielä pitää jostain laittaa ruksi erikseen johonkin.

No sehän voisi olla vaikka machinecert+user autentikointi. Jolloin certissä nimenä vaikka workstation-x ja käyttäjänä onkin user-y

user9999 · 21.12.2020

pfBlockerNG v3.0.0_7 on nyt ladattavissa:

Reddit - Dive into anything

www.reddit.com

A Lake Elk · 21.12.2020

@maninthemoon Vertasin nyt omaa vpn:n konfikki tiedostoa ja ainoastaan, <ca> </ca> ja <tls-crypt> </tls-crypt> on samoja eri konfigeissä, muuten on eri avaimet/certit. Eli sulla on siellä jotain hämärää, jos nyt oikein luin tuota sun aiempaa viestiä.

maninthemoon · 21.12.2020

A Lake Elk sanoi:
Itellä ei oo tuota valintaa päällä, joten se ei taida olla sekään. Ja koitin nyt ilman FreeRADIUSsia, niin en voi käyttää ristiin noita certtejä ja tunnuksia siltikään. Onhan sulla User Managerissä määritelty vain yksi "User Certificate"/käyttäjä ja molemmille on varmasti eri certti?

Voihan däämn vaikka muuten tuntuu toimivan erilailla. On yksi serti per käyttäjä vain ja kummallakin on vain yksi serti. Täytyy varmaan tuhota koko vpn serveri käyttäjineen ja serteineen päivineen ja rakentaa se uusiksi. Jos tuokaan ei onnistu, niin täytyy postailla VPN palvelimen screenshotteja, niin joku voi ammattimaisemmilla silmillä katsoa, että onko siellä jotain näkyvää virhettä mitä en vain tajua.

kuukie sanoi:
No sehän voisi olla vaikka machinecert+user autentikointi. Jolloin certissä nimenä vaikka workstation-x ja käyttäjänä onkin user-y

Tätäkin voisi tietysti kokeilla, että onko mitään hyötyä.
Oletteko alla oleviin kenttiin laittanut jotain (value)? Äkkiseltän ei tule mitään mieleen, että miten hyödyttäisim mutta jotain kummallista tässä on, jos se ei ollut tuokaan mitä ajattelin, että olisi tilanteen ratkaissut. Tuotakin muistaaakseni kokeilin, mutta tässä nyt pari päivää testaillut, niin täytyy pitää pieni lepo hetki aivoille.

Jos vielä viitsit kokeilla, niin kokeile poistaa VPN käyttäjän alta serti ja katso meneekö läpi.

Edit. Varmaan luit oikein. Viimeisin avain on siis kummassakin profiilissa sama, mutta muuten eri tietueita mitä ylempänä mainistinkin jo. Onkohan tuo avain se määrittelevä tekijä sitten tässä?
Suttasin nyt tuota pikkaisen vaikka en tiedä onko siitä kenellekkään hyötyä vaikka näkisi kokonaan. En tosin keksinyt vielä, että miten eri certiin/profiiliin saa eri avaimet...

Edit. Kuva poistettu.

A Lake Elk · 21.12.2020

@maninthemoon Poistin User Managerista käyttäjiltä certit, niin homma toimii edelleen kuten aikasemminkin. Molemmat konfigit jätin tosin koskematta. Uutta kofigia en pysty luomaan OVPN:n Client Exportilla kun ei ole niitä certtejä annettu käyttäjile.

[edit] Joo siis toi tls-crypt -osio on itelläkin sama kuin myös ca-osio. Muut erilaiset...

maninthemoon · 21.12.2020

@A Lake Elk
Editoin edellistä viestiä vielä tuon avaimen suhteen mikäli meni jo ohitse.

A Lake Elk · 21.12.2020

maninthemoon sanoi:
@A Lake Elk
Editoin edellistä viestiä vielä tuon avaimen suhteen mikäli meni jo ohitse.

Joo menee täällä päässä sekasin noi kaikki avaimet ja certit

. En oo noihin niin perehtynyt muutakuin sen verran, että tiedän mitkä certit/avaimat OpenVPN vaatii toimiakseen ja miten ne luodaan

.

mikajh · 21.12.2020

maninthemoon sanoi:
Viimeisin avain on siis kummassakin profiilissa sama, mutta muuten eri tietueita mitä ylempänä mainistinkin jo. Onkohan tuo avain se määrittelevä tekijä sitten tässä?

Ei, se on VPN / OpenVPN / Servers / Cryptographic Settings / TLS Key, tarkista!

A Lake Elk · 21.12.2020

Pistän tähän kuvankaappausina oman OpenVPN:n asetuksia, jos sieltä löytys jotain joka auttais:

General Inforrmation

Cryptographic Settings

Advanced Configuration

Certification Manager:
CAs

A Lake Elk · 21.12.2020

Certificates

mikajh · 21.12.2020

maninthemoon sanoi:
Olisikohan nyt tämäki keissi selvinnyt. Täytyy testailla vielä, mutta toisen käyttäjän tunnuksilla en nyt pystynyt kirjautumaan vaan herjaa autetikoinnista. Pistin tähän ruksin. Jotenkin ei ole niin looginen (itselleni ainakaan), jos ylhäällä määritellään jo, että certi + user autetinkointi ja sitten vielä pitää jostain laittaa ruksi erikseen johonkin.

Minulla ei ollut tuota päällä. Kun vaihdoin Android OpenVPN-sovelluksessa profiilissa username (sama kuin certin CN) toiseksi käyttäjäksi, OpenVPN-tunneli yhdistyi. Lisäsin rastin tuohon, jolloin tuli auth failure.

EDIT: Minulla ei ole rastia kohdassa "Username as Common name" kuten A Lake Elk:illä
EDIT2: maninthemoon, eikös se nyt siis toimi niin kuin halusit?

maninthemoon · 21.12.2020

mikajh sanoi:
Ei, se on VPN / OpenVPN / Servers / Cryptographic Settings / TLS Key, tarkista!

Sama avain mikä noissa VPN profiileissa mitä ylempänä esimerkkinä laitoin.

mikajh sanoi:
Minulla ei ollut tuota päällä. Kun vaihdoin Android OpenVPN-sovelluksessa profiilissa username (sama kuin certin CN) toiseksi käyttäjäksi, OpenVPN-tunneli yhdistyi. Lisäsin rastin tuohon, jolloin tuli auth failure.

EDIT: Minulla ei ole rastia kohdassa "Username as Common name" kuten A Lake Elk:illä
EDIT2: maninthemoon, eikös se nyt siis toimi niin kuin halusit?

Näillä testeillä toimii kuten toivoinkin, mutta onko tämä nyt sitten oikea tapa lopputuloksesta mitä hain? Täytyy vielä perata nuo A Lake Elk:in kuvat läpi ja vertailla niitä omiin.
Mikäli oikein ymmärsin, niin sinulla tämä toimi samalla tavalla kuin minulla A Lake Elk:illä taas toimii erilailla? Jotenkin tuntuu kikkaululta, että laitetaan tuollainen rasti päälle ja seurataan common namea, kun ylempänä server modessa se pitäisi jo itsessään olla ja kertoa. <- Ääneen ajattelua lähinnä.

mikajh · 21.12.2020

maninthemoon sanoi:
Jotenkin tuntuu kikkaululta, että laitetaan tuollainen rasti päälle ja seurataan common namea, kun ylempänä server modessa se pitäisi jo itsessään olla ja kertoa. <- Ääneen ajattelua lähinnä.

Täysin samaa mieltä. Se, että tuo "Strict User-CN Matching" ei ole oletuksena päällä on bugi.

EDIT: Perusteluja: Virtual Private Networks — OpenVPN — OpenVPN Configuration Options | pfSense Documentation
"Remote Access (SSL/TLS + User Auth)
The most secure choice offered. Not only does it get the benefits of other SSL/TLS choices, but it also requires a username and password from the client when it connects. Client access can be removed not only by revoking the certificate, but also by changing the password. Also, if a compromised key is not immediately discovered, the danger is lessened because it is unlikely that the attacker has the keys and the password. When using the OpenVPN wizard, this is the mode which is configured during that process."

Nyt ~~jos/~~kun "Strict User-CN Matching" ei ole oletuksena päällä, tuo "The most secure choice offered." romuttuu aika lailla. Pelkällä toisen käyttäjän salasanalla voi käytännössä esiintyä toisena käyttäjänä.

maninthemoon · 21.12.2020

mikajh sanoi:
Täysin samaa mieltä. Se, että tuo "Strict User-CN Matching" ei ole oletuksena päällä on bugi.

Se sitten selittäisi jo paljon, jos se pitäisi olla oletuksena päällä, mutta ei kuitenkaan ole. Sitten A Lake Elk:illä on jotain kummalisuuksia, jos hänellä tämä toimii halutusti ilman ruksia.

Voitaisiin ajatellä tämä niin päin, niin ei tarvitse tuskailla tämän kanssa.

Edit. Aika samalta A Lake Elk:in asetukset servein päässä näyttää kuin itsellänikin pois lukien tuo raksi mistä ollaan puhuttu. Ehkä tämä piisaa itselleni, kun pelaa kuitenkin halutulla tavalla, niin ei tarvitse enempää säätää.

Kiitos ukoille avusta ja vaivannäöstä!

sra2010 · 21.12.2020

Onkohan tämä se asetus jolla tuo väärällä käyttäjänimellä kirjautuminen estetään vaikka cert onkin oikea, mutta väärälle käyttäjälle?
Eikö tuolta user managerin kautta luoda jokaiselle omat tunnukset ja cert joka valitaan client exportissa?

Ei ole omaa kokemusta muuten kuin testi käytössä aliverkosta toiseen.

Strict User-CN Matching
For SSL/TLS+User Authentication server, when enabled, this option enforces a match between the username supplied by the user and the Common Name of their user certificate. If the two do not match, the connection is rejected. This prevents users from using their own credentials with another person’s certificate and vice versa.

Virtual Private Networks — OpenVPN — OpenVPN Configuration Options | pfSense Documentation

docs.netgate.com

A Lake Elk · 21.12.2020

Voi vitt... sitä on ihminen typerä... Nyt hävettää ihan totaalisesti... Mä se oon munannu täällä omissa testeissä ihan kympillä... Oon käyttäny salasananhallinta softaa antamaan käyttäjätunnuksen ja salasanan, tai oikeastaan tässä tapauksessa pelkän salasanan kun se keleen tunnus on ollu jo valmiina konffeissa, niin tottakait se ei toimi ristiin kun oon yrittäny käyttäjätunnus y:llä ja käyttäjä x:n salasanalla :sholiday:

.

Mä poistun netistä, jatkakaa...

mikajh · 21.12.2020

A Lake Elk sanoi:
...salasananhallinta softaa antamaan käyttäjätunnuksen ja salasanan

Ainakin LastPass toimii aika huonosti muilla pfSensen web-konfiguraatiosivuilla kuin pelkässä web-hallinnan loginissa. Muut paikat, missä salasanoja tulee vastaan, ei tietenkään toimi kun se yrittää tuupata sitä login-salasanaa vaikka DDNS-palveluun, jossa on ihan eri käyttäjätunnus.

A Lake Elk · 21.12.2020

mikajh sanoi:
Ainakin LastPass toimii aika huonosti muilla pfSensen web-konfiguraatiosivuilla kuin pelkässä web-hallinnan loginissa. Muut paikat, missä salasanoja tulee vastaan, ei tietenkään toimi kun se yrittää tuupata sitä login-salasanaa vaikka DDNS-palveluun, jossa on ihan eri käyttäjätunnus.

Tässä tapauksessa käyttelin Bitwardenia Android luurissa antamaan sen salasanan OpenVPN Connect appiiin, enkä tajunnu että ainoo kohta johon sen tarvi mitään täyttää oli se pelkkä salasana, vaikka toistin sen useasti peräkkäin testailun aikana. Ilmeisesti menny "pikkasen" lihasmuistiin Bitwardenin käyttö kun ei tuu kiinnitettyä huomiota ollenkaan siihen mitä silmät näkee...

escalibur · 21.12.2020

Tälläinenkin purkki julkaistiin: NA347

Aika näyttää miltä tuon saatavuus tulee näyttämään.

kuukie · 21.12.2020

Täytyy olla halpa, että kykenee kilpailemaan Fitlet2 kanssa noilla specseillä

escalibur · 21.12.2020

kuukie sanoi:
Täytyy olla halpa, että kykenee kilpailemaan Fitlet2 kanssa noilla specseillä

Noin 150€ olisi varsin passeli hinta. Veikkaan vaan ettei tuota nähdä Aasian markkinoiden ulkopuolella lainkaan.

ps. pfBlockerNG:sta ilmestyi 3.0.0_7 versio: pfBlockerNG v3.0.0_7 by BBcan177 · Pull Request #1008 · pfsense/FreeBSD-ports

Gobi · 29.12.2020

mikajh sanoi:
Toistuuko sama jos kytket WinMTR:n suoraan siihen ethernet-"nousuun"? Jos kyllä, niin operaattorilla loppuu kaista ja tiputtelevat paketteja. Jos ei, niin pfSense-raudassa ongelmaa. Onko offloadit pois päältä, esim. checksum-offloading? Realtekin vai Intelin NIC?

Kuitu-ketjusta tänne:

En ole jaksanut vetäistä pitkää kaapelia suoraan kuitupäätteeltä koneelle, sen kun joutuisi kytkimen kautta vetämään, nyt vetäisin ja n. 10 min testi aikana ei hävinnyt kuin yksi paketti toisessa päässä yhteyttä. Eli vika parani tuolla ja siirtyi pfSense-rautaan. Offloadit on disabloitu, NIC on neliporttinen Dell 0CWKPJ Intelin D42543 CPUlla. BIOSista disabloitu sisäinen NIC ja kaikki muu turha. Jatketaan selvittelyä tässä ketjussa, kuitu-ketjuun ei enää kuulu.

mikajh · 29.12.2020

Gobi sanoi:
pfSense-rautaan. Offloadit on disabloitu, NIC on neliporttinen Dell 0CWKPJ D42543 CPUlla

Onko vaikutusta, jos enabloit hardware offloadin, alkaen vaikka checksummasta? Jotta muutos tulisi voimaan, boottaa pfSense tai käy niiden porttien asetuksissa, jotka ovat testin aikana käytössä.
Varmaan pfSensen logista tai komentoriviltä (ifconfig <ifname> ?) pitäisi nähdä, missä asennossa hw offload varmasti on ja miten se muuttuu

192.168.2.6 on pfSense LAN, host on Ubuntu

Koodi:

$ sudo ping -f -c 1000000 192.168.2.6
PING 192.168.2.6 (192.168.2.6) 56(84) bytes of data.

--- 192.168.2.6 ping statistics ---
1000000 packets transmitted, 1000000 received, 0% packet loss, time 127331ms
rtt min/avg/max/mdev = 0.048/0.114/10.392/0.019 ms, ipg/ewma 0.127/0.109 ms

Windowsille löytyy sysinternals.com PsPing flood pingailuun: psping.exe -t -i 0 -q <dest>

Gobi · 29.12.2020

mikajh sanoi:
Onko vaikutusta, jos enabloit hardware offloadin, alkaen vaikka checksummasta? Jotta muutos tulisi voimaan, boottaa pfSense tai käy niiden porttien asetuksissa, jotka ovat testin aikana käytössä.
Varmaan pfSensen logista tai komentoriviltä (ifconfig <ifname> ?) pitäisi nähdä, missä asennossa hw offload varmasti on ja miten se muuttuu

192.168.2.6 on pfSense LAN, host on Ubuntu

Koodi:

$ sudo ping -f -c 1000000 192.168.2.6 PING 192.168.2.6 (192.168.2.6) 56(84) bytes of data. --- 192.168.2.6 ping statistics --- 1000000 packets transmitted, 1000000 received, 0% packet loss, time 127331ms rtt min/avg/max/mdev = 0.048/0.114/10.392/0.019 ms, ipg/ewma 0.127/0.109 ms

Windowsille löytyy sysinternals.com PsPing flood pingailuun: psping.exe -t -i 0 -q <dest>

Eipä ollut vaikutusta, kaikkia komboja en varmasti testannut, mutta joitakin kävin läpi. ifconfig näyttää muutoksen heti. Gateways-logissa esiintyy koko ajan seuravaa virhettä:

Koodi:

Dec 29 18:31:16    dpinger        WAN_DHCP ***.***.***.1: sendto error: 65

Tuo IP tuossa on ilmeisesti kuitupäätteen gateway, tutkitaan taasen.

mikajh · 29.12.2020

Jos tuota virhettä tulisi jatkuvasti, niin silloinhan packet loss -näyttö olisi 100% eikä 0.x% Troubleshooting — Troubleshooting Gateway Monitoring | pfSense Documentation

Joskus aiemmin gateway monitoring on sinulla toiminut järkevästi. Mutta jos esim. default gateway ei vastaa pingiin, niin monitorointiosoite pitää laittaa jonnekin kauemmas. Varsinkiin siinä tapauksessa laittaisin pingausintervallit huomattavan paljon harvemmaksi kuin ne oletuksena ovat.

Gobi · 29.12.2020

mikajh sanoi:
Jos tuota virhettä tulisi jatkuvasti, niin silloinhan packet loss -näyttö olisi 100% eikä 0.x% Troubleshooting — Troubleshooting Gateway Monitoring | pfSense Documentation

Joskus aiemmin gateway monitoring on sinulla toiminut järkevästi. Mutta jos esim. default gateway ei vastaa pingiin, niin monitorointiosoite pitää laittaa jonnekin kauemmas. Varsinkiin siinä tapauksessa laittaisin pingausintervallit huomattavan paljon harvemmaksi kuin ne oletuksena ovat.

Nuo onkin näköjään pätkiä joissa kaapeli irti tms. Vetäisin asennuksen uusiksi juuri, eipä vaikuttanut toimintaan, voisi viitata yhteensopimattomaan hardwareen. Siirsin gatewayn monitoring IPn kauemmaksi, tuokaan ei auttanut asiaan. Jatkan säätämistä.

mikajh · 29.12.2020

Gobi sanoi:
voisi viitata yhteensopimattomaan hardwareen

Voit kokeilla myös ottaa käyttöön sen emon NIC:n. Jos se on Realtek, niin sen kanssa voi tulla myös luotettavuusongelmia, mutta ehkäpä se ei anna samanlaista packet lossia ainakaan alkuun. pfSense:ssä on hyvin helppoa vaihtaa interfaceja fyysisestä laitteesta toiseen Interfaces - Assignments -tabilla, koskematta mihinkään muuhun.

Gobi · 29.12.2020

mikajh sanoi:
Voit kokeilla myös ottaa käyttöön sen emon NIC:n. Jos se on Realtek, niin sen kanssa voi tulla myös luotettavuusongelmia, mutta ehkäpä se ei anna samanlaista packet lossia ainakaan alkuun. pfSense:ssä on hyvin helppoa vaihtaa interfaceja fyysisestä laitteesta toiseen Interfaces - Assignments -tabilla, koskematta mihinkään muuhun.

Realtekhan se on, voihan tuota kokeilla jos se toimisi paremmin. Noihin Realtekin ongelmiin kai jotain fixiä on tulossa 2.5 versiossa, tai näin muistan lukeneeni.

Gobi · 30.12.2020

Varsin oikukas on ongelma, netin kiertäessä pfSensen kautta se hidastuu 10 min välein ja packet loss kasvaa. Taas kun kokeilin suoralla kaapelilla, netti toimi odotetusti.

Rauta:

Kone: HP ProDesk 400 G3 SFF i5-6500/8/120SSD
NIC: Dell 0CWKPJ, Intel D42543-piirillä
Kuitupääte Calix 844G sillattuna

Alla puhdas pfSense asennus. Kotiverkossa 2 AP-toistinta, NAS ja tämä pöytäkone. Keskeytykset ei ole ristiriidassa, verkkokaapelit on kunnossa (testattu iperf-testillä). Onko jollain antaa vinkkiä miten jatkaa ongelmaratkontaa?

Khauron · 30.12.2020

Käykö verkkokortin piiri miten lämpimänä?
Itse lähtisin ensimmäisenä hakemaan syytä tuosta ProDeskistä. Mitä jos pfSensen tilalla kokeilee jotain muuta FW-distroa; ongelma poistuu vai pysyy?

Ogeli · 30.12.2020

Gobi sanoi:
Kone: HP ProDesk 400 G3 SFF i5-6500/8/120SSD
NIC: Dell 0CWKPJ, Intel D42543-piirillä

Ilmeisesti sait tuon kortin toimimaan x16 väylässä mun hp-prodesk-600-g1 ei tunnistanut kunnolla x4 intel korttia.
Testaukset vielä "vaiheessa" käyttis proxmox.
Emon NIC taitaa olla intel löytyykö pcie-x1 korttia testaukseen?

Gobi · 30.12.2020

Ogeli sanoi:
Ilmeisesti sait tuon kortin toimimaan x16 väylässä mun hp-prodesk-600-g1 ei tunnistanut kunnolla x4 intel korttia.
Testaukset vielä "vaiheessa" käyttis proxmox.
Emon NIC taitaa olla intel löytyykö pcie-x1 korttia testaukseen?

Komennolla

Koodi:

pciconf -lbcevV pci0:3:0:0

:

Koodi:

igb0@pci0:3:0:0:    class=0x020000 card=0xa02c8086 chip=0x10e88086 rev=0x01 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82576 Gigabit Network Connection'
    class      = network
    subclass   = ethernet
    bar   [10] = type Memory, range 32, base 0xe2400000, size 131072, enabled
    bar   [14] = type Memory, range 32, base 0xe1c00000, size 4194304, enabled
    bar   [18] = type I/O Port, range 32, base 0x3000, size 32, enabled
    bar   [1c] = type Memory, range 32, base 0xe2440000, size 16384, enabled
    cap 01[40] = powerspec 3  supports D0 D3  current D0
    cap 05[50] = MSI supports 1 message, 64 bit, vector masks
    cap 11[70] = MSI-X supports 10 messages, enabled
                 Table in map 0x1c[0x0], PBA in map 0x1c[0x2000]
    cap 10[a0] = PCI-Express 2 endpoint max data 256(512) FLR RO NS
                 link x4(x4) speed 2.5(2.5) ASPM disabled(L0s/L1)
    ecap 0001[100] = AER 1 0 fatal 0 non-fatal 2 corrected
    ecap 0003[140] = Serial 1 90e2baffff48a4c0
    ecap 000e[150] = ARI 1
    ecap 0010[160] = SR-IOV 1 IOV disabled, Memory Space disabled, ARI disabled
                     0 VFs configured out of 8 supported
                     First VF RID Offset 0x0180, VF RID Stride 0x0002
                     VF Device ID 0x10ca
                     Page Sizes: 4096 (enabled), 8192, 65536, 262144, 1048576, 4194304
  PCI-e errors = Correctable Error Detected
                 Unsupported Request Detected
     Corrected = Bad DLLP
                 Advisory Non-Fatal Error

Erroreita tuolla lopussa, linkki näyttäisi olevan 4x kumminkin. Taidan laittaa parempaa rautaa tilaukseen, olkoon tämä kone käytössä siihen asti. Emon NIC on Realtek, ei ole nyt muita kortteja testaukseen.

Ogeli · 30.12.2020

Tossa vois vielä koittaa teipata kortti x1 väylälle (en löytänyt ohjetta) nopeudesta tän jälkeen ei hajua.
Varmaan olet tarkistanut HP:n bios päivitykset /asetukset ?

Gobi · 30.12.2020

Ogeli sanoi:
Tossa vois vielä koittaa teipata kortti x1 väylälle (en löytänyt ohjetta) nopeudesta tän jälkeen ei hajua.
Varmaan olet tarkistanut HP:n bios päivitykset /asetukset ?

Tälläisen löysin joskus, mutta ei taida tätä korttia koskea:

Demystifying Intel PRO/1000 Quad Port NICs

Uusin BIOS päivitetty kun sain koneen, asetuksia ei liikaa noissa ole. Aika tarkkaan perkasin, väylät pois/päälle ja virransäästö taisi olla ainoita PCIe-väylää liittyviä. Katson vielä tänään uudestaan.

mikajh · 30.12.2020

Vertailun vuoksi omasta pfSensestä eri kortilla näköjään samanlainen Unsupported Request Detected

Koodi:

pciconf -lbcevV pci0:2:0:0
igb0@pci0:2:0:0:    class=0x020000 card=0x00018086 chip=0x15218086 rev=0x01 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'I350 Gigabit Network Connection'
    class      = network
    subclass   = ethernet
    bar   [10] = type Memory, range 32, base 0xa1280000, size 524288, enabled
    bar   [1c] = type Memory, range 32, base 0xa130c000, size 16384, enabled
    cap 01[40] = powerspec 3  supports D0 D3  current D0
    cap 05[50] = MSI supports 1 message, 64 bit, vector masks 
    cap 11[70] = MSI-X supports 10 messages, enabled
                 Table in map 0x1c[0x0], PBA in map 0x1c[0x2000]
    cap 10[a0] = PCI-Express 2 endpoint max data 256(512) FLR RO NS
                 link x1(x4) speed 5.0(5.0) ASPM disabled(L0s/L1)
    ecap 0001[100] = AER 1 0 fatal 0 non-fatal 1 corrected
    ecap 0003[140] = Serial 1 a0369fffff85b1e8
    ecap 0017[1a0] = TPH Requester 1
    ecap 0018[1c0] = LTR 1
  PCI-e errors = Correctable Error Detected
                 Unsupported Request Detected
     Corrected = Advisory Non-Fatal Error

Gobi · 30.12.2020

mikajh sanoi:
Vertailun vuoksi omasta pfSensestä eri kortilla näköjään samanlainen Unsupported Request Detected

Soitin aspaan ja pyysin siltauksen poistoa testatakseni sen vaikutusta. Hidastelut lähti, pientä lossia jäi. Mennään tällä nyt hetki.

juhaa · 05.01.2021

Varmistellaanpa taas kun pihalla olen.

Pitää blokata tietyt sisäverkon laitteet, että eivät saa otettua WAN:n kautta yhteyttä internettiin. Meneekö se vai näin..?

Firewall / Rules / LAN

On siis X määrä "älykoti" laitteita mihin EN halua automaattista firmwaren päivitystä, koska toiminta vaikeutuu sen jälkeen.

mikajh · 05.01.2021

juhaa sanoi:
Pitää blokata tietyt sisäverkon laitteet, että eivät saa otettua WAN:n kautta yhteyttä internettiin. Meneekö se vai näin..?

Destination "WAN net" on varmaankin väärin, laita siihen Any (*)
WAN net olisi (vain) se verkko, missä WAN IP osoite sattuu olemaan

juhaa · 05.01.2021

mikajh sanoi:
Destination "WAN net" on varmaankin väärin, laita siihen Any (*)
WAN net olisi (vain) se verkko, missä WAN IP osoite sattuu olemaan

Juuri tuossa huomasin, että ei ainakaan tuo alkuperäinen ollut oikein kun sain vielä pilven kautta ohjattua, mikä ei ole suotavaa

LAN yhteys pitää olla sallittu, joten tuo Any ei kuulosta oikealta?

Vai pitääkö olla ensin block ja sitten pass rule tiettyyn IP osoitteeseen sisäverkossa?
Eihän sen tarvitse olla yhteydessä kuin kotiautomaation ´keskukseen´, sisään ja ulos.

maninthemoon · 05.01.2021

juhaa sanoi:
Juuri tuossa huomasin, että ei ainakaan tuo alkuperäinen ollut oikein kun sain vielä pilven kautta ohjattua, mikä ei ole suotavaa

LAN yhteys pitää olla sallittu, joten tuo Any ei kuulosta oikealta?

Eikös tuossa tapauksessa tarvitse kikkailemaan aliaksilla?

Itse olen tehnyt näin.

Sourcessa on alias missä kerrotaan IP osoitteet mitkä halutaan blokata ja destinaationissa on verkota mihin halutaan päästää ja Invert täppä paikalleen. Tämä ainakin toimii itsellä, mutta en tiedä onko
"helpopaa" tapaa. Käänteisessä säännössä blokataan kaikkialle muualle pääse paitsi noihin verkkoihin (destination) mitkä olen aliakseen laittanut.

Edit. Voi olla, että olen tässä ajatellut saada useamman koneen blokattua ettei tarvitse tusinan verran muuri sääntöjä tehdä sen takia. Eli kai tähänkin jokin muukin ratkaisu on, kuin aliaksilla leikkiminen.

mikajh · 05.01.2021

Jos tuo laite saa LANissa toimia ihan vapaasti, niin ne yhteydet ei mene reitittimen kautta, olettaen, että siinä ei ole useampaa pfSense-interfacea

maninthemoon · 05.01.2021

@juhaa
Taas kun saa palauteltua tämä mieleen, niin tee niin, että sourceen tuo haluttu IP osoite (jos ei ole tarve kuin yhdelle) ja Aliakseen kerrot tuon LAN verkko alueen mihin sen haluat pääsevan. Ja ylemmän kuvan mukaan destination kohtaan samalla tavalla, niin pitäisi toimia. Silloin blokataan kaikkialle muualle pääsy paitsi aliaksessa kerrotulle verkolle.

juhaa · 05.01.2021

maninthemoon sanoi:
@juhaa
Taas kun saa palauteltua tämä mieleen, niin tee niin, että sourceen tuo haluttu IP osoite (jos ei ole tarve kuin yhdelle) ja Aliakseen kerrot tuon LAN verkko alueen mihin sen haluat pääsevan. Ja ylemmän kuvan mukaan destination kohtaan samalla tavalla, niin pitäisi toimia. Silloin blokataan kaikkialle muualle pääsy paitsi aliaksessa kerrotulle verkolle.

No joo. Rautalankaa tässä todellakin tarvitaan

Heti alkuun tarve on 3:lle IP:lle, joten Alias on varmasti se oikea polku, lisää tavaraa tuohon tulee kun pääsen kankeudesta ohi.

Kokeilin nyt alkuun näin. Se todettakoon, että on ollut liian pitkä prosessi erotella IoT vehkeet pois normaalista verkosta, ehkä tämä on sen alku...

edit: Pilvestä saan noita vielä ohjattua, mikä ei ollut suotavaa.

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

"Random Tech Channel" @ YouTube

BANNATTU

BANNATTU

BANNATTU

BANNATTU

BANNATTU

BANNATTU

BANNATTU

BANNATTU

BANNATTU

"Random Tech Channel" @ YouTube

"Random Tech Channel" @ YouTube

Uutiset

Statistiikka

Hinta.fi