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

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
Napsauta laajentaaksesi...

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
 
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
Napsauta laajentaaksesi...
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.
 
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?
 
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?
Napsauta laajentaaksesi...

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...
 
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.
 
Viimeksi muokattu:
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...
Napsauta laajentaaksesi...
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.
1608565047221.png
 
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.
1608565047221.png
Napsauta laajentaaksesi...

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?
 
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.
1608565047221.png
Napsauta laajentaaksesi...
No sehän voisi olla vaikka machinecert+user autentikointi. Jolloin certissä nimenä vaikka workstation-x ja käyttäjänä onkin user-y
 
@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ä.
 
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?
Napsauta laajentaaksesi...
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
Napsauta laajentaaksesi...
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.
1608567837097.png


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.
 
Viimeksi muokattu:
@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...
 
Pistän tähän kuvankaappausina oman OpenVPN:n asetuksia, jos sieltä löytys jotain joka auttais:

General Inforrmation
general.JPG

Cryptographic Settings
crypto_1.JPG
crypto_2.JPG

Advanced Configuration
advanced.JPG

Certification Manager:
CAs
ca.JPG
 
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.
1608565047221.png
Napsauta laajentaaksesi...
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?
 
Viimeksi muokattu:
mikajh sanoi:
Ei, se on VPN / OpenVPN / Servers / Cryptographic Settings / TLS Key, tarkista!
Napsauta laajentaaksesi...
Sama avain mikä noissa VPN profiileissa mitä ylempänä esimerkkinä laitoin.

1608576489594.png


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?
Napsauta laajentaaksesi...
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ä.
 
Viimeksi muokattu:
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ä.
Napsauta laajentaaksesi...
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ä.
 
Viimeksi muokattu:
mikajh sanoi:
Täysin samaa mieltä. Se, että tuo "Strict User-CN Matching" ei ole oletuksena päällä on bugi.
Napsauta laajentaaksesi...
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ä!
 
Viimeksi muokattu:
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.

OpenVPN Configuration Options | pfSense Documentation

docs.netgate.com docs.netgate.com
 
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::sfacepalm:.

Mä poistun netistä, jatkakaa...
 
A Lake Elk sanoi:
...salasananhallinta softaa antamaan käyttäjätunnuksen ja salasanan
Napsauta laajentaaksesi...
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.
 
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.
Napsauta laajentaaksesi...

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...
 
Tälläinenkin purkki julkaistiin: NA347

1608581807553.png


Aika näyttää miltä tuon saatavuus tulee näyttämään.
 
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?
Napsauta laajentaaksesi...

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.
 
Viimeksi muokattu:
Gobi sanoi:
pfSense-rautaan. Offloadit on disabloitu, NIC on neliporttinen Dell 0CWKPJ D42543 CPUlla
Napsauta laajentaaksesi...
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>
 
Viimeksi muokattu:
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>
Napsauta laajentaaksesi...

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.
 
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.
 
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.
Napsauta laajentaaksesi...

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ä.
 
Gobi sanoi:
voisi viitata yhteensopimattomaan hardwareen
Napsauta laajentaaksesi...
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.
 
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.
Napsauta laajentaaksesi...

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.
 
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?

grafana_speedtestplus_cli.jpg
 
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?
 
Gobi sanoi:
Kone: HP ProDesk 400 G3 SFF i5-6500/8/120SSD
NIC: Dell 0CWKPJ, Intel D42543-piirillä
Napsauta laajentaaksesi...
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?
 
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?
Napsauta laajentaaksesi...

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.
 
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 ?
 
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 ?
Napsauta laajentaaksesi...

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.
 
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
 
mikajh sanoi:
Vertailun vuoksi omasta pfSensestä eri kortilla näköjään samanlainen Unsupported Request Detected
Napsauta laajentaaksesi...

Soitin aspaan ja pyysin siltauksen poistoa testatakseni sen vaikutusta. Hidastelut lähti, pientä lossia jäi. Mennään tällä nyt hetki.
 
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
1609878379826.png


On siis X määrä "älykoti" laitteita mihin EN halua automaattista firmwaren päivitystä, koska toiminta vaikeutuu sen jälkeen.
 
juhaa sanoi:
Pitää blokata tietyt sisäverkon laitteet, että eivät saa otettua WAN:n kautta yhteyttä internettiin. Meneekö se vai näin..?
Napsauta laajentaaksesi...
Destination "WAN net" on varmaankin väärin, laita siihen Any (*)
WAN net olisi (vain) se verkko, missä WAN IP osoite sattuu olemaan
 
mikajh sanoi:
Destination "WAN net" on varmaankin väärin, laita siihen Any (*)
WAN net olisi (vain) se verkko, missä WAN IP osoite sattuu olemaan
Napsauta laajentaaksesi...

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.
 
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?
Napsauta laajentaaksesi...
Eikös tuossa tapauksessa tarvitse kikkailemaan aliaksilla?

Itse olen tehnyt näin.
1609879994012.png

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.

1609880068773.png


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.
 
Viimeksi muokattu:
Jos tuo laite saa LANissa toimia ihan vapaasti, niin ne yhteydet ei mene reitittimen kautta, olettaen, että siinä ei ole useampaa pfSense-interfacea
 
@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.
 
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.
Napsauta laajentaaksesi...

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... :)

1609881152509.png


1609881189083.png


1609881287301.png


1609881368127.png


1609881433889.png


edit: Pilvestä saan noita vielä ohjattua, mikä ei ollut suotavaa.
 
Kirjaudu tai rekisteröidy kirjoittaaksesi tänne.

Uutiset

Uutisia lyhyesti

Uusimmat viestit

Statistiikka

Viestiketjuista
259 090
Viestejä
4 501 551
Jäsenet
74 328
Uusin jäsen
Arttu1337

Hinta.fi

Back
Ylös Bottom