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

Vaikuttaa siltä, että tää asia on nyt korjaantunut, kun viimesin errori maili tuli viime lauantaina ja sen jälkeen ei oo kuulunut mitään.

Mitähän tää errori merkkaa kun pfSense lähettelee näitä mailitse mulle:
Koodi:
X-Cron-Env: <SHELL=/bin/sh>\
X-Cron-Env: <PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin>\
X-Cron-Env: <HOME=/root>\
X-Cron-Env: <LOGNAME=root>\
X-Cron-Env: <USER=root>\
\
Certificate verification failed for /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root\
34374270280:error:14090086:SSL routines:ssl3*get*server*certificate:certificate verify failed:/build/ce-crossbuild-245/sources/FreeBSD-src/crypto/openssl/ssl/s3*clnt.c:1269:\
fetch: <https://files.pfsense.org/lists/fullbogons-ipv4.txt>: Authentication error\
Certificate verification failed for /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root\
34374270280:error:14090086:SSL routines:ssl3*get*server*certificate:certificate verify failed:/build/ce-crossbuild-245/sources/FreeBSD-src/crypto/openssl/ssl/s3*clnt.c:1269:\
fetch: <https://files.pfsense.org/lists/fullbogons-ipv4.txt>: Authentication error\
Certificate verification failed for /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root\
34374270280:error:14090086:SSL routines:ssl3*get*server*certificate:certificate verify failed:/build/ce-crossbuild-245/sources/FreeBSD-src/crypto/openssl/ssl/s3*clnt.c:1269:\
fetch: <https://files.pfsense.org/lists/fullbogons-ipv4.txt>: Authentication error\
Certificate verification failed for /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root\
34374270280:error:14090086:SSL routines:ssl3*get*server*certificate:certificate verify failed:/build/ce-crossbuild-245/sources/FreeBSD-src/crypto/openssl/ssl/s3*clnt.c:1269:\
fetch: <https://files.pfsense.org/lists/fullbogons-ipv4.txt>: Authentication error

Noita vastaavia rivejä on satoja...
 
pfSense ei enää lataa Easylist Finlandia, näyttää 0 entries. Miten tuon voisi korjata?

Logissa on paljon tuollaisia:
[ DNSBL_Easylist - easylistprivacy ] Download Fail
Local File Failure
Restoring previously downloaded file
 
pfSense ei enää lataa Easylist Finlandia, näyttää 0 entries. Miten tuon voisi korjata?

Logissa on paljon tuollaisia:
[ DNSBL_Easylist - easylistprivacy ] Download Fail
Local File Failure
Restoring previously downloaded file
Luultavasti listan formaatti tms on muutettu.

Koodi:
[ EasyList_Finland ] Downloading update [ 06/23/20 09:05:45 ] .. 200 OK

No Domains Found! Ensure only domain based Feeds are used for DNSBL!

Feedin linkki kuitenkin toimii:
 
Luultavasti listan formaatti tms on muutettu.

Koodi:
[ EasyList_Finland ] Downloading update [ 06/23/20 09:05:45 ] .. 200 OK

No Domains Found! Ensure only domain based Feeds are used for DNSBL!

Feedin linkki kuitenkin toimii:
Joo, listassahan ei tosiaan ole enää kuin noita sivustojen elementtien piilotuksia. Tuo minun login teksti olikin vanha, uusimmat oli alimpana... Pitää poistaa tuo feedi pfSensestä, selaimessahan se kuitenkin on minulla myös käytössä.
 
Statuspäivitys pfBlockerNG:n kehittäjältä:

Jun 26 at 5:00am
June 2020 - Update
Hello Patrons and followers!

I know that its been awhile since my last Post! Its been quite an eventful year (Covid-19 aside)! Hope that all of you and your families have been safe!

In regards to the next release of pfBlockerNG-devel, it is still being actively developed but hit some issues waiting for pfSense 2.4.5 to be released, and then with the 'pfctl' issues, it was delayed until the release and soak-period of 2.4.5p1.

However, a recent change in the Unbound python code has limited some functionality which is needed for the upcoming pfBlockerNG python integration. I have been in contact with the developers from NLNET, and hope that they can re-implement the functionality that the package requires.

Ultimately, I am hoping to release the next version of pfBlockerNG-devel in the next 30-60 days and have the pfSense devs review the changes and make it available for everyone shortly after.

Thank you for your patience! and Thanks for your continued support! Its very appreciated!

BBcan177


I have to compile a list for release. The new python integration is a top-bottom change to how DNSBL works in Unbound, since it doesn't use the previous Unbound (Zone/data) functionality.

Short list:


  • DNSBL Python mode ~30-60% memory improvement
  • DNSBL Regex blocking
  • DNSBL CNAME packet inspection
  • DNSBL TLD Allow only mode to limit which TLDs are permissible
  • DNSBL IDN Blocking mode
  • DNSBL HSTS Null Blocking mode to improve Cert errors.
  • DNS Reply w/GeoIP logging
  • Reports tab timeline graphing
  • Many changes to the Reports tab for IP/DNSBL/DNS Reply
  • Pause functionality in Reports tab refresh
  • Updates to IP/DNSBL Feeds to remove closed feeds and add new ones
  • Improvements to DNSBL CARP mode
  • DNSBL Logging/No Logging/Null Blocking modes
  • Many other under-the-hood performance improvements
Working on Policy management for DNSBL, but not sure if it will make the next release.



Niille joille Python-tuki ei sano mitään, avasin asiasta tässä viestissä: Tee-se-itse: Rautapalomuurit (pfSense, Sophos UTM..) (Mitä käytätte ja miksi juuri se vaihtoehto?)
 
TUlipa sitten vaihdettua pfSense opnsenseen. Vaihdon syynä oli halu testata ja säätää sekä wireguard vpn-paketit saatavana toisin kuin pfSenseen. Näin muutaman päivän kokemuksella vaikuttaa oikeinkin hyvältä ja käyttöliittymä mielestäni mukavampi kuin pfSensessä sekä enemmän lisäpaketteja. Tietoturvapäivityksiä tulee viikoittain sekä kernelissä hardenedBSD
 
TUlipa sitten vaihdettua pfSense opnsenseen. Vaihdon syynä oli halu testata ja säätää sekä wireguard vpn-paketit saatavana toisin kuin pfSenseen. Näin muutaman päivän kokemuksella vaikuttaa oikeinkin hyvältä ja käyttöliittymä mielestäni mukavampi kuin pfSensessä sekä enemmän lisäpaketteja. Tietoturvapäivityksiä tulee viikoittain sekä kernelissä hardenedBSD

Mitenkäs mainostenestopuoli tuossa? Pärjääkö nykyään jo pfBlockerille niiden ratkaisut?
 
Piti sitten nostaa tuo Firewall Maximum Table Entries arvo 800000 --> 2000000.

Notifications in this message: 2
================================

19:02:49 There were error(s) loading the rules: /tmp/rules.debug:29: cannot define table pfB_PRI3_v4: Cannot allocate memory - The line in question reads [29]: table <pfB_PRI3_v4> persist file "/var/db/aliastables/pfB_PRI3_v4.txt"
 
Hieman apuja... DNA:lta ei jostain syystä yön jälkeen tule IPv4:sta F3686AC modeemille ja sen johdosta ei netti toimi pfSensen läpi, mikäs asetus mulla siellä on tekemättä?
WAN = IPv6
LAN = IPv4

edit: DNA oli puskenut päivityksen modeemin ja muuttanut sen ei siltaavaksi. Taas toimii.
 
Viimeksi muokattu:
Sain pari päivää sitten raudan (Minisys j3160 eli Protecli Fw4b) ensimmäistä pfSense asennusta varten. Yllättävän helposti ja nopeasti perussetupin sai tehtyä ja vanha dd_wrt purkki sai jäädä suoraan eläkkeelle ilman suurempia ongelmia uudessa.

Laitoin heti tästä ketjustä löytyvien ohjeiden mukaan Trafic Shaping asetukset. dslreports.com/speedtest bufferbloat parani A luokkaan, vaikka testiä ajoi monta kertaa.
Tänään kun ajan tuon testin, sieltä tulee sekalaisesti kaikenlaista A-D arvoa. Kuuluisiko tuo testi ajaa silloin kun omassa verkossa on mahdollisimman paljon liikennettä vai kun on hiljaista? Onko tuo testi edes luotettava tapa tutkia bufferbloatia vai onko jokin parempi tapa?
Voiko ongelma johtua siitä, että pfsense limitterit on aikalailla siinä, mitä ISP:ltä tulee (kyseessä etana nopeuden maaseutu adsl)? Kun laitoin limittejä, sain parhaat arvot noilla ja matalammilla tuli huonompi arvo.
 
Mitäs eroa on muuten ipsec vs openvpn säädettävyys, hallittavuus ja käyttöönotto jne pfsense tai opnsense muureissa tai ihan yleisesti. Itse olen ymmärtänyt että ipsec olisi suositumpi yritysympäristöissä kuin openvpn. Miksi näin?
 
Varmaan hiukan väärä topic mutta kysytään täällä mietteitä tästä laitteesta kannattaisiko satsata?
Deeper Connect Mini: Decentralized Cybersecurity
Tuntematon yritys joka lupaa "Kuun taivaalta". :) En luottaisi tuohon ilman kolmannen osapuolten auditointia ja testejä. Rahoitussivustoilla on aiemminkin ollut noita ihme-verkkolaitteita joilla lupailtiin ties mitä.

Lähes poikeuksetta kaikkien hehkutusten ohella aina "unohdetaan" kertoa millainen softa-armeija taustalla on. Jos koko projekti on yhden kaveriporukan varassa, en löisi vetoa sen puolesta että tuote on uskottavassa kunnossa vielä viiden tai kymmenen vuoden päästä. Toki jos on utelias ja haluaa leikkiä noilla, niin mikäs siinä.
 
Ok no hyvä että tuli suora vastaus tuohonkin...:speechless:
Mikäs nyt olisi sitten "edukas" vaihto ehto kun ei oikeen enää softa vpnätkään napostele jatkuvien lisenssin uusimisien ja käytön hidastuvuuden suhteen. Itsehän en näihin ole kovin paljoa perehtynyt tuo nyt vain kuullosti helpolta vaihtoehdolta. Toki kaikki diy jutut hallitsen että tavallaan olisi ihan kivakin itse viritellä aika vaan tahtoo olevan näissä kortilla.
 
Tavoitteena siirtää palvelimelta nginx reverse proxy pfsenseen haproxyyn. Kyseessä yksinkertainen koti setup muutamalla nettiin auki olevalla palvelulla.
Pari päivää yrittänyt saada haproxyä toimimaan lan:sta fqdn:llä. Wan:sta lähti kyllä yhteys heti toimimaan ja lanissa tietenkin ip:llä.

Konffeja:
-vip eli virtual ip alias, johon port forward WAN:sta 443 porttiin.
-haproxy frontend kuuntelee vip:443 ja backendit perus ssl offloading/acme sertti setupilla
-palomuurissa wan-> vip:443 avaus
-palomuurissa lan-> vip:443 avaus (tarviiko tätä?)
-dns resolverissa fqdn->vip ip host overridet

Clienteillä näkyy pfsensen dns käytössä. Kaikki (clientit, hostit) samassa subnetissa ja lan:ssa.
Ideoita mikä voisi olla vikana, että lan:sta ei vastaa fqdn:llä?
 
Clienteillä näkyy pfsensen dns käytössä. Kaikki (clientit, hostit) samassa subnetissa ja lan:ssa. Ideoita mikä voisi olla vikana, että lan:sta ei vastaa fqdn:llä?
Riittääkö, jos lisäät DNS Resolveriin Domain tai Host Overriden lania varten?
 
Riittääkö, jos lisäät DNS Resolveriin Domain tai Host Overriden lania varten?
Tämä minulla siis on: "dns resolverissa fqdn->vip ip host overridet ". Näin koska haproxy frontend kuuntelee vip ip:tä.
Olen kokeillut tuohon myös "fqdn -> host ip" yhdistelmää. Tällä toimi vanhan erillisen nginx proxyn kanssa, mutta kumpikaan yhdistelmä ei auta haproxyllä lan ongelmaan.
Nslookup windows clintiltä näyttää, että pfsense ratkoo osoitteen siksi mitä tuohon host overrideen laittaa.
 
Viimeksi muokattu:
Eli ongelma ei varsinaisesti liity fqdn:ään, vaan siihen, että lan:ista reititys ei mene siihen vip:iin? Jos näin, niin pystyykö LAN:n palomuurisäännöllä src:lan ip address/net dst:vip tuon korjaamaan? IP Aliasta ei taida sentään saada valituksi gatewayksi säännön Advanced Options -listan lopussa?

Tuon Haproxyn kanssa kannattaa olla varovainen, ettei missään tilanteessa tule pfSensen WebGUI tule servatuksi WAN:iin
 
Eli ongelma ei varsinaisesti liity fqdn:ään, vaan siihen, että lan:ista reititys ei mene siihen vip:iin? Jos näin, niin pystyykö LAN:n palomuurisäännöllä src:lan ip address/net dst:vip tuon korjaamaan? IP Aliasta ei taida sentään saada valituksi gatewayksi säännön Advanced Options -listan lopussa?

Tuon Haproxyn kanssa kannattaa olla varovainen, ettei missään tilanteessa tule pfSensen WebGUI tule servatuksi WAN:iin
Ongelma ratkesi. Syy oli väärässä virtual ip:n interfacessa. Kun sen vaihtoi localhostista LAN:iin, alkoi toimimaan.
Kiitokset kuitenkin ideoista!
 

Onko tämä emo auttamatta liian hidas johonkin tämmöiseen käyttöön? Tupla LAN liitännät olisi valmiina.
Laatikossa lojunut nyt turhana reilun vuoden ja mietin heitänkö serriin vai toimisiko tämä?
En siis itse ota käyttöön vaan jos on käypäinen niin joku saa tästä emon.. :)
 

Onko tämä emo auttamatta liian hidas johonkin tämmöiseen käyttöön? Tupla LAN liitännät olisi valmiina.
Laatikossa lojunut nyt turhana reilun vuoden ja mietin heitänkö serriin vai toimisiko tämä?
En siis itse ota käyttöön vaan jos on käypäinen niin joku saa tästä emon.. :)
LAN 2 x Realtek RTL8111E PCI-E Gigabit Ethernet

Ei välttämättä ole hidas, mutta Realtekin verkkopiirit saattavat toimia vaihtelevasti. Jos on aikaa ja kiinnostusta, eiköhän sillä voi ainakin harjoitella ja opiskella asioita. Vaihtoehtoisesti tuohon voi asentaa erillisen verkkokortin jossa on vähintään kaksi porttia.

Tuotanto- ja kriittisiin paikkoihin suosittelen pysymään Intelin verkkokorteissa. Niitä saa halvalla esim eBaystä.
 
Saisikohan pfBlockerNG:hen jollain tempulla lisättyä sivustoja, joiden mainoksia haluaa katsella?
 
Whitelistillä onnistuu.

Eihän se pfBlocker tiedä mistä ne DNS pyynnöt tulee? Sama mainosdomain voi olla monella sivulla käytössä niin ei sellaista sivukohtaisesti oikein saa whitelistattua. Vai onko tuossa joku ominaisuus mistä en tiedä?
 
Eihän se pfBlocker tiedä mistä ne DNS pyynnöt tulee? Sama mainosdomain voi olla monella sivulla käytössä niin ei sellaista sivukohtaisesti oikein saa whitelistattua. Vai onko tuossa joku ominaisuus mistä en tiedä?

Jep, pitäisi siis whitelistata kaikki osoitteet, jotka ko. sivustolla on blokattu. Samalla ne avaa muillekin sivustoille.

Sen tuntemattoman ominaisuuden perään juuri kyselen :)


https://www.doyler.net/security-not-included/pfsense-dnsbl-whitelisting
Noin tein joskus itselleni, kun tarvitsi saada www.ruutu.fi näkymään mainoksineen. Vai ymmärsinkö mitä haet väärin?

Lopputuloksen kannalta et ymmärtänyt väärin, mutta toteutus ei osunut :)
 
Onko noista asetuksista mitään iloa tai harmia alle gigan nopeuksissa...

Muistelisin että esim. Openwrt:n kanssa esim. fd_codel qos ei toiminut hwoffloadingin kanssa.
En ole itse löytänyt mitään iloa tai harmia alle gigan. Nytkin kaista on alle gigan, nuo asetukset käytössä, ja vielä BufferBloatin estämiseksi fd_codel:kin käytössä, ja kaikki toimii kuten pitääkin. Tai ei ainakaan ole tullut eteen harmeja.
 
OPNsense 20.7 päivitettävissä. Release note 20.7-RC1:stä: OPNsense 20.7-RC1 released
Mukana pari pientä fiksiä, kun ntpd time source on GPS

Viikon tai pari jos venailis, että onko porukalla ongelmia ja päivittäis oman. Ei oo ennen ollu mitään ongelmia, mutta kerta se on ensimmäinenki ja en jaksa alkaa räpeltämään.

Piti lahjottaa 50e OPNsenselle ja 50e HardenedBSD:lle, kun keväällä unohtu tehdä.
 
Mulla on OPNsense asennettu huhtikuussa yhteen koneeseen. On pitänyt tuota tutkia, mutta ei ole vain innostanut :)
Jos viikonloppuna tuota jaksaisi katsoa tai ainakin päivittäisi ajantasalle.
 
Näköjään taas yksi listatuottaja alkaa vaatimaan lisenssiä kahdelle listalleen, että niitä voisi käyttää. En tosin tiedä miten sen saisi käyttöön tuolla pfSensen pfBlockerng:ssä...

Listat on siis:
IPv4 - PRI1: https://osint.bambenekconsulting.com/feeds/c2-ipmasterlist-high.txt - BBC_C2
ja
DNSBL - Malicious: https://osint.bambenekconsulting.com/feeds/c2-dommasterlist-high.txt - BBC_DC2
 
Mulla on OPNsense asennettu huhtikuussa yhteen koneeseen. On pitänyt tuota tutkia, mutta ei ole vain innostanut :)
Jos viikonloppuna tuota jaksaisi katsoa tai ainakin päivittäisi ajantasalle.
v20.7:ssä on nyt Suricata 5 IDS/IPS vakiona(?). Jos nyt laittaisi tuon 21.1 development-branchin kolmanneksi rinnakkaiseksi palomuuriksi ihan oikeaan käyttöön.
 
Löytyykö jostain hyviä oppaita pfSense ipv6 hyödyntämiseen ja mielellään vielä dual wan niin, että vain toinen wan tukee ipv6 ja toisen kanssa käytettävä ipv4?
Onko tämmöistä ipv4 ja ipv6 sekoitusta kahden wan:n kanssa järkevä tai edes mahdollista tehdä? Olen aloittelija ipv6 ja dual wan kanssa, mutta isp ipv4 porttisulkujen takia joku tämäntapainen setup kiinnostaa.

Lawrence Systems osaa kaikkea, mutta ei ilmeisesti ipv6 asioita pfSensen kanssa.
 
Löytyykö jostain hyviä oppaita pfSense ipv6 hyödyntämiseen ja mielellään vielä dual wan niin, että vain toinen wan tukee ipv6 ja toisen kanssa käytettävä ipv4?
Parasta opasta en ole löytänyt, mutta tuollainen multi-WAN onnistuu kyllä varsin hyvin.

Mutta ihan ensimmäisenä kannattaa tarkistaa, mikä se IPv6-tarjoajan prefix delegation size on. Jos se on /64 eikä parempi (pienempi numero), niin ei kannata vaivautua ainakaan tekemään pfSensestä IPv6-palomuuria.
 
Mutta ihan ensimmäisenä kannattaa tarkistaa, mikä se IPv6-tarjoajan prefix delegation size on. Jos se on /64 eikä parempi (pienempi numero), niin ei kannata vaivautua ainakaan tekemään pfSensestä IPv6-palomuuria.
Harkinnassa oli DNA ja sehän lienee tuo /64. Muutenkin parin päivän testailut yhdellä perheenjäsenen puhelimella/liittymällä on näyttänyt niin karmeita nopeuksia, että DNA saa sen perusteellakin jäädä väliin. Cellmapper myös näytti, että talo aika huonosti keiloihin nähden.
Eli Teliaa tai Elisaa WAN2 interfaceen sitten ja niissä en pfsense ipv6 setuppia tarvi.
 
v20.7:ssä on nyt Suricata 5 IDS/IPS vakiona(?). Jos nyt laittaisi tuon 21.1 development-branchin kolmanneksi rinnakkaiseksi palomuuriksi ihan oikeaan käyttöön.
OPNsense 20.7:ssä onkin vähän ongelmia. En suosittele päivitystä siihen toistaiseksi. Varovaisuus aina palkitaan
 
OPNsense 20.7:ssä onkin vähän ongelmia. En suosittele päivitystä siihen toistaiseksi. Varovaisuus aina palkitaan

Ei ole tullut seurattua tilannetta, mitä ongelmia siinä on? Reilu viikko sitten päivitin koska joskus pitää elää reunalla. Mutta ei omassa käytössä ole ilmennyt mitään.
 
Ei ole tullut seurattua tilannetta, mitä ongelmia siinä on? Reilu viikko sitten päivitin koska joskus pitää elää reunalla. Mutta ei omassa käytössä ole ilmennyt mitään.
Itse en vielä(kään) käytä aktiivisesti, joten kaikkia ongelmia en ole huomannut. Mutta syslog-ng (Remote Syslog) kaatuu ja ntpd:llä käynnistysvaikeuksia, eikä se logita mitään päivityksen jälkeen. Nyt ei ole vanhaa 20.1-versiota enää referenssiksi.
 
Itse en vielä(kään) käytä aktiivisesti, joten kaikkia ongelmia en ole huomannut. Mutta syslog-ng (Remote Syslog) kaatuu ja ntpd:llä käynnistysvaikeuksia, eikä se logita mitään päivityksen jälkeen. Nyt ei ole vanhaa 20.1-versiota enää referenssiksi.

Aivan, juuri katsoinkin että tarjolla olisi päivitys ja change notessa viitattiin logitusongelmiin. Mutta tosiaankin jäänyt huomaamatta itseltäni kun logeja tarvitsee lähinnä kun on ongelmia taikka säätää™ jotakin, eikä ole nyt ollut toiminnassa ongelmaa eikä ole ollut aikaa/tarvetta virittelyynkään.
 
Pfsense paketteihin julkaistu seuraavat päivitykset:

Arpwatch 0.2.0_4

pfBlockerNG-devel 2.2.5_34
 
Viimeksi muokattu:
Tulipa tänään mieleen sellainen asetelma missä tulisi käytettyä puhelimesta löytyvää nopeaa rajatonta nettiä hyväksi myös kotona. Laitoin vanhan OpenWRT-reitittimeni wifin client-tilaan ja yhdistämään tuohon kännykän hotspottiin, tuntuisi toimivan oikein nätisti eli heti yhdistää jonka jälkeen piuhalla saa LAN-porttien kautta ulos kännykän nettiyhteyden. Tuo olisi tarkoitus laittaa pfSenseen toiseksi WAN-yhteydeksi ja laittaa sitten QoS ja load balancer kuntoon siten ettei latenssiongelmia tule mutta sellaiset asiat missä ei viive haittaa toimisivat sitten nopeammin. Täällä taisi jollain olla kokemuksia ainakin 4G-yhteyksien käyttämisestä tuolla tavalla, olisiko jotain hyvää ohjetta tai vinkkejä miten tuo kannattaisi tehdä?
 
Tulipa vastaan yksinkertainen, mutta ärsyttävä ominaisuus pfSensen OpenVPN asetuksissa. Kyseessä on kodin ja tallin välinen site-to-site VPN yhteys joka on toiminut ok. Nyt lisäsin tallille WLANin omana verkkona. Kodin pfSensen OpenVPN serverin asetuksiin lisäsin IPv4 Remote network(s) kohtaan tallin WLANin näin 10.1.0.0/24, 10.1.100.0/24 ja ihmettelin pari päivää miksei kotiverkosta tallin WLANiin osoitetut paketit mene tunnelia pitkin, vaan tuupattiin suoraan WAN yhteydestä ulos. Reititystauluun ei tullut tuota uutta verkkoa ja manuaalinen lisääminenkään ei jostain syystä auttanut. No syy oli sitten tuossa välilyönnissä pilkun jälkeen... Välilyönti pois ja homma alkoi pelaamaan. Nyt verkko tulee reititystauluun automaattisesti, kuten pitääkin.
 
Oletteko törmänneet hyvään step-by-step tutoriaaliin, kuinka viritellä reverse-proxy pfsenseen?
Pitäisi saada mahdollisimman "turvallinen" pääsy sisäverkon NASsiin ja siinä pyöriviin dockereihin. (mm. nextcloud ja homeassistant)

Reverse proxy on ymmärtääkseni VPN yhteyden jälkeen turvallisin vaihtoehto?
 

Statistiikka

Viestiketjuista
259 044
Viestejä
4 499 845
Jäsenet
74 324
Uusin jäsen
CapitateSnafu

Hinta.fi

Back
Ylös Bottom