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

[jad]

Hyvä kun mainitsit, aloin epäilemään itseäni. Eihän se systemd-resolved mullakaan koko verkon nimikyselyistä suoraan vastaa vaan siinä on pihole välissä. Pihole pyörii reitittimellä kontissa jolla on pääsy tuohon resolvedin stub-resolveriin joka sitten hoitaa kyselyt upstreamista DoT:lla.

Haa, olinkin unohtanut koko piholen. Pitääkin laittaa tuo vielä räpellyslistalle, kunhan nyt ensin saa muuten setupin kuntoon.

Lähteekö vastaukset wan0 ifacen ip:llä?

Näyttäisi lähtevän wan1 ip:llä, mutta kuitenkin wan0 interfacesta. tcpdump:lla kun kuuntelen joko alla olevaa fyysistä interfacea tai wan0:aa, niin wan0:aa pingatessa molemmat näyttää siltä miltä pitäisikin.
Kun pingaan wan1:tä. Niin kuunnellessa fyysistä interfacea, tcpdump näyttää normaalilta:

Mutta jos kuuntelenkin wan1:tä, niin haaviin jää pelkät requestit:

Ja replyt löytyykin wan0:aa kuuntelemalla, mutta ip osoite on kuitenkin wan1:n:

En nyt heti keksinyt syytä, että mikä bitti on vinossa, että näin pääsee käymään.

 

[user9999]

PfSense System Patches 2.2.6 julkaistu.

Bug #9889: Cannot validate Certificates against Certificate Revocation Lists for Intermediate Certificate Authorities - pfSense - pfSense bugtracker

Redmine

redmine.pfsense.org

 

[Asiantuntija]

PfSense System Patches 2.2.6 julkaistu.

Bug #9889: Cannot validate Certificates against Certificate Revocation Lists for Intermediate Certificate Authorities - pfSense - pfSense bugtracker

Redmine

redmine.pfsense.org

Asensin tuon System Patches paketin, mutta ei siellä ollut mitään sellaisia korjauksia, joita kokisin tarvitsevani.

 

[Khauron]

Tuli itse vaihdettua purkkia APU2:sta --> NetGate 2100 MAX.
Harmi että pfSensen / FreeBSD:n kytkinominaisuudet ovat suoraan sanoen paskat, eikä mitään lisäosia tähän löydy. Ajattelin, että ylimääräiset portit olisi nätisti toimineet bridgenä, jossa VLANeja, mutta ei toimi ei.
Todella hyvä purkki, ja paljon näpsäkämpi mitä vanha. Internetinä on 1000 M / 1000 M symmetrinen FTH. ISP:n kuitumuunnin on välissä siltaavana fibre --> ethernet.

Sitten onkin kovaa etsintää 2.5 Gbit/s hallittavan kytkimen hankintaan, jotta saa WIFI Access pointit ja Plexit sun muut rokkaamaan täydellä hyödyllä. Eroa en varmaan edes huomaa, mutta pakko saada

Edit: Nyt siis 1000 Mbit/s hallittavat kytkimet (3 kpl) tontilla, mitkä toimivat niin kuin voi odottaa.

 

[Eskonaama]

Tuli itse vaihdettua purkkia APU2:sta --> NetGate 2100 MAX.
Harmi että pfSensen / FreeBSD:n kytkinominaisuudet ovat suoraan sanoen paskat, eikä mitään lisäosia tähän löydy. Ajattelin, että ylimääräiset portit olisi nätisti toimineet bridgenä, jossa VLANeja, mutta ei toimi ei.

Tarkennatko vähän minkälaista konffausta haaveilit toteuttavasi? Jokaisessa portissa olisi samat vlanit ja jakaisit kuorman tasaisesti eri porttien kesken / käyttäisit jokaista porttia omana uplinkkinään per kytkin?

 

[Khauron]

Vaikea selittää, mutta koetetaan:
Purkissa 5 porttia, 1 WAN, 4 LAN. Kutsutaan niitä LAN1, LAN2, LAN3, LAN4.

Koetin bridgettää kaikki 4 LAN-porttia. Toimii.
Kun lisään VLANit samaan bridgeen, ei toimi.
Lukemani perusteella pfSensessä / opnSensessä / FreeBSD:ssä ei toimi se, että bridge-interfacessa ei toimi VLANit, jossa on untagged ja tagged -portteja. Yksi interface ja yksi VLAN toimii, mutta omassa setupissa interfaceja olisi 4 kpl ja VLANeja 4 kpl.
Tämä kaikki toimii, jos vedän sen yhden interfacen läpi. Jos teen bridgen (eli lisään portit 2-4), ei toimi enää. Testasin tämän HP J9660A -kytkimellä, sekä Hyper-V:n päällä olevalla Wire:llä.

Tämä kaikki sen vuoksi, että olisin voinut hyödyntää purkin 2.5 GBit/s -portteja.
Nyt setup toimii yhden pfSense -interfacen kautta täydelliseti, mutta seuraava hop on 1 GBit /s -kytkin.
Olisin siis halunnut pfSense-purkin kaikki portit käyttöön 2.5 GBit/s ja VLAN-tuella. Kaikki LAN-portit bridgenä.

Edit: Eli kaikki pfSense-purkin LAN-portit (bridge) heittäisivät ulos samoja VLANeja. Untagged ja tagged.

Edit 2: Koetin siis päästä yhdestä kytkimestä eroon välistä, jolloin olisin saanut WIFI-Acces-Point tukariin suoran 2.5GBit/s liitynnän.

 

[Algron28]

Vaikea selittää, mutta koetetaan:
Purkissa 5 porttia, 1 WAN, 4 LAN. Kutsutaan niitä LAN1, LAN2, LAN3, LAN4.

Koetin bridgettää kaikki 4 LAN-porttia. Toimii.
Kun lisään VLANit samaan bridgeen, ei toimi.
Lukemani perusteella pfSensessä / opnSensessä / FreeBSD:ssä ei toimi se, että bridge-interfacessa ei toimi VLANit, jossa on untagged ja tagged -portteja. Yksi interface ja yksi VLAN toimii, mutta omassa setupissa interfaceja olisi 4 kpl ja VLANeja 4 kpl.
Tämä kaikki toimii, jos vedän sen yhden interfacen läpi. Jos teen bridgen (eli lisään portit 2-4), ei toimi enää. Testasin tämän HP J9660A -kytkimellä, sekä Hyper-V:n päällä olevalla Wire:llä.

Tämä kaikki sen vuoksi, että olisin voinut hyödyntää purkin 2.5 GBit/s -portteja.
Nyt setup toimii yhden pfSense -interfacen kautta täydelliseti, mutta seuraava hop on 1 GBit /s -kytkin.
Olisin siis halunnut pfSense-purkin kaikki portit käyttöön 2.5 GBit/s ja VLAN-tuella. Kaikki LAN-portit bridgenä.

Edit: Eli kaikki pfSense-purkin LAN-portit (bridge) heittäisivät ulos samoja VLANeja. Untagged ja tagged.

Edit 2: Koetin siis päästä yhdestä kytkimestä eroon välistä, jolloin olisin saanut WIFI-Acces-Point tukariin suoran 2.5GBit/s liitynnän.

Niin oliko nuo 2,5G portit tuossa APU2:ssa? Ainakin NetGate 2100 MAX on googlen mukaan vain 1G portit.

Hankala sanoa kun ei näe konffista mutta tuossa ilmeisesti on nuo lan portit sisäisen switchin takana joten tämä varmaan vaikuttaa konffiin vrt. että olisi suoraan reitittimen portissa. Muutenkin reitittävien porttien kohdalla bridgejä kannattaa välttää sillä useinmiten suorituskyky tulee ongelmaksi kun liikenne joudutaan ajamaan prossan läpi.

 

[ponky]

Lukemani perusteella pfSensessä / opnSensessä / FreeBSD:ssä ei toimi se, että bridge-interfacessa ei toimi VLANit, jossa on untagged ja tagged -portteja. Yksi interface ja yksi VLAN toimii, mutta omassa setupissa interfaceja olisi 4 kpl ja VLANeja 4 kpl.

Frisbeen verkkostäkki ei ole itselle tuttu, mutta Linkkaripuolella "softakytkinten" tai bridgejen tapauksessa homma toimii niin, että fyysisen interfacen päälle luodaan VLAN-interface joka liikuttelee tägättyjä paketteja ja natiivi VLAN tai tägäämätön liikenne hoidetaan silloin tuolla fyysisellä interfacella. Tuossa tapauksessa joutuu luomaan jokaista L2-verkkoa varten oman bridgen joihin sitten lisäilee kunkin interfacen päälle liimatun VLAN-interfacen. Täysin mahdollista, että *BSD toteuttaa tämän jotenkin eri tavalla.

Bridging w/Vlan Interfaces

Hi there, I've been struggling to make a "basic" setup with two bridges on the LAN side of the router: Bridge1: em1 + em2 Bridge0: VLAN500 on em1 + em3 As I create Bridge1, bridge0 stops forwarding traffic. Any suggestion will be appreciated. *** Configuration: bridge0: flags=8843 metric 0...

forums.freebsd.org

Ainakin tämän perusteella menisi juuri noin, eli mainitsemasi setuppi pitäisi kyllä olla mahdollista toteuttaa. Samaan siltaan pitäisi myös pystyä lisäämään samaan aikaan interface sekä kyseisen interfacen VLAN-interfaceja, jolloin liikenne lähtee kyseisestä portista sekä tägin kanssa että ilman.

 

[ponky]

Haa, olinkin unohtanut koko piholen. Pitääkin laittaa tuo vielä räpellyslistalle, kunhan nyt ensin saa muuten setupin kuntoon.

Näyttäisi lähtevän wan1 ip:llä, mutta kuitenkin wan0 interfacesta. tcpdump:lla kun kuuntelen joko alla olevaa fyysistä interfacea tai wan0:aa, niin wan0:aa pingatessa molemmat näyttää siltä miltä pitäisikin.
Kun pingaan wan1:tä. Niin kuunnellessa fyysistä interfacea, tcpdump näyttää normaalilta:

Mutta jos kuuntelenkin wan1:tä, niin haaviin jää pelkät requestit:

Ja replyt löytyykin wan0:aa kuuntelemalla, mutta ip osoite on kuitenkin wan1:n:


En nyt heti keksinyt syytä, että mikä bitti on vinossa, että näin pääsee käymään.

Selvisikö? Mikä arvo sulla on rp_filterissä? sysctl -a | grep rp_filter

 

[Khauron]

Niin oliko nuo 2,5G portit tuossa APU2:ssa? Ainakin NetGate 2100 MAX on googlen mukaan vain 1G portit.

Hankala sanoa kun ei näe konffista mutta tuossa ilmeisesti on nuo lan portit sisäisen switchin takana joten tämä varmaan vaikuttaa konffiin vrt. että olisi suoraan reitittimen portissa. Muutenkin reitittävien porttien kohdalla bridgejä kannattaa välttää sillä useinmiten suorituskyky tulee ongelmaksi kun liikenne joudutaan ajamaan prossan läpi.

Näin itsekin olen ymmärtänyt pfSensen ja opnSensen forumeilta. TL;DR: vältä bridgejä.

Sekoilin mallinimissä, oikea malli on siis 4100. Ja tosiaan 4 kpl 2.5 GBit/s -ethernetportteja. APU2 oli vanha vehje, ja se on nyt offline tuossa pöydällä.

Frisbeen verkkostäkki ei ole itselle tuttu, mutta Linkkaripuolella "softakytkinten" tai bridgejen tapauksessa homma toimii niin, että fyysisen interfacen päälle luodaan VLAN-interface joka liikuttelee tägättyjä paketteja ja natiivi VLAN tai tägäämätön liikenne hoidetaan silloin tuolla fyysisellä interfacella. Tuossa tapauksessa joutuu luomaan jokaista L2-verkkoa varten oman bridgen joihin sitten lisäilee kunkin interfacen päälle liimatun VLAN-interfacen. Täysin mahdollista, että *BSD toteuttaa tämän jotenkin eri tavalla.

Bridging w/Vlan Interfaces

Hi there, I've been struggling to make a "basic" setup with two bridges on the LAN side of the router: Bridge1: em1 + em2 Bridge0: VLAN500 on em1 + em3 As I create Bridge1, bridge0 stops forwarding traffic. Any suggestion will be appreciated. *** Configuration: bridge0: flags=8843 metric 0...

forums.freebsd.org

Ainakin tämän perusteella menisi juuri noin, eli mainitsemasi setuppi pitäisi kyllä olla mahdollista toteuttaa. Samaan siltaan pitäisi myös pystyä lisäämään samaan aikaan interface sekä kyseisen interfacen VLAN-interfaceja, jolloin liikenne lähtee kyseisestä portista sekä tägin kanssa että ilman.

Kaikkeni koetin, mutta en vaan saa toimimaan. Tuo linkin setup kyllä onnistuu, siinä on yhdessä bridgessä yksi VLAN. Vastaavan saan siis toimimaan, mutta haluaisin bridgettää kaikki 4 kpl LAN-portteja yhdeksi bridgeksi, ja tässä bridgessä olisi 4 kpl VLANeja. Untagattynä kulkisi "perusverkko", jonka tarvisi olla saatavilla heti seuraavissa vehkeissä (WIFI-tukari, 3 kpl managed-kytkimiä). Sen voisi ehkä ajatella niin, että minulla on neljäkerroksinen talo, ja kellarikerroksessa on tuo pfSense. Kaikki toimii hienosti jos kellarikerroksessa on pfSensen perässä yksi managed-kytkin. Jos poistan tuon managed-kytkimen välistä, kytkeytyisi jokainen kerros omaan fyysiseen porttiinsa pfSensessä (bridge). Kaikille kerroksille täytyisi juosta samat VLANit. Kytkimet eivät ole kytkettyjä toisiinsa muuta kuin tuon pfSensen kautta.

Konffeja tai screenshotteja konffista voin kyllä jakaa, ja oikeastaan mitä vaan pystyn testaamaan. Täytyy vaan vähän valita aikaa, kun kooman seurauksena koko perhe on ilman internettiä sen aikaa kunnes saan palautettua edellisen version

 

[mikajh]

mutta haluaisin bridgettää kaikki 4 kpl LAN-portteja yhdeksi bridgeksi, ja tässä bridgessä olisi 4 kpl VLANeja. Untagattynä kulkisi "perusverkko",

Kuten tuossa jo mainittiin, niin suorituskykymielessä tuosta ei ehkä ole hyötyä, sillä pfSense joutuu liikuttamaan paketteja liikaa softalla vs dedikoitu hallittava kytkin

 

[jad]

Selvisikö? Mikä arvo sulla on rp_filterissä? sysctl -a | grep rp_filter

rp_filter on kaikissa interfaceissa nolla.

Ongelma sekä selvisi, että ei selvinnyt

wan3.network:

[Match]
Name=wan3

[Network]
DHCP=ipv4

[DHCP]
RouteTable=130

[RoutingPolicyRule]
OutgoingInterface=wan3
Table=130

Tämä johtaa tälläiseen lopputulokseen (wan0 ei ole RouteTable määritystä lainkaan):
$ ip route

default via xx.xx.91.1 dev wan0 proto dhcp src xx.xx.91.10 metric 1024
xx.xx.91.0/24 dev wan0 proto kernel scope link src xx.xx.91.10 metric 1024
xx.xx.91.1 dev wan0 proto dhcp scope link src xx.xx.91.10 metric 1024

$ ip route show table 130

default via xx.xx.91.1 dev wan3 proto dhcp src xx.xx.91.84 metric 1024
xx.xx.91.0/24 dev wan3 proto dhcp scope link src xx.xx.91.84 metric 1024
xx.xx.91.1 dev wan3 proto dhcp scope link src xx.xx.91.84 metric 1024

$ ip rule

0:      from all lookup local
5000:   from yy.yy.0.0/20 to yy.yy.0.0/20 lookup 5000 proto static
32757:  from all oif wan3 lookup 130 proto static
32761:  from yy.yy.3.0/24 iif lan3 lookup 130 proto static
32766:  from all lookup main
32767:  from all lookup default

Tässähän käy niin, että Elisa tarjoilee liki peräkkäisiä ip-osoitteita kaikille wan interfaceille ja jokaisessa on sama gateway.

Tällä setupilla pingatessa ulkoa päin wan3 ip:tä xx.xx.91.84, vastaukset lähtee wan0:sta, mutta wan3:n ip:llä.

Kun lisään käsin rulen wan3:n ip-osoitteella:
ip rule add from xx.xx.91.84 table 130
Alkaa paketit kulkemaan oikein wan3:n kautta.

Ongelma on se, että en keksinyt yksinkertaista keinoa jolla saisi tuon ip rulen lisättyä siinä vaiheessa kun Elisan DHCP tarjoilee leasen.
Toki voin ottaa käyttöön networkd-dispatcher:n ja kirjoitella scriptin joka rulen tekee aina kun lease saadaan, mutta siitä joutuu tekemään ikävän monimutkaisen jos huomioi sen, että ip-osoite voi myös vaihtua lennosta. Tosin Elisa kyllä pääsääntöisesti tarjoaa aina saman ip:n leasen uudistuksessa, mutta jos esim. gfast silta on tunnin pari virrattomana ja itse gateway on tämän ajan käynnissä, niin osoitteet todennäköisesti vaihtuvat ja vanha ip rule pitäisi siivota pois uuden alta.

Edit: rulen lisäämisen jälkeen:
$ ip rule

0:      from all lookup local
4999:   from xx.xx.91.84 lookup 130
5000:   from yy.yy.0.0/20 to yy.yy.0.0/20 lookup 5000 proto static
...

 

[ponky]

Kaikkeni koetin, mutta en vaan saa toimimaan. Tuo linkin setup kyllä onnistuu, siinä on yhdessä bridgessä yksi VLAN. Vastaavan saan siis toimimaan, mutta haluaisin bridgettää kaikki 4 kpl LAN-portteja yhdeksi bridgeksi, ja tässä bridgessä olisi 4 kpl VLANeja. Untagattynä kulkisi "perusverkko", jonka tarvisi olla saatavilla heti seuraavissa vehkeissä (WIFI-tukari, 3 kpl managed-kytkimiä). Sen voisi ehkä ajatella niin, että minulla on neljäkerroksinen talo, ja kellarikerroksessa on tuo pfSense. Kaikki toimii hienosti jos kellarikerroksessa on pfSensen perässä yksi managed-kytkin. Jos poistan tuon managed-kytkimen välistä, kytkeytyisi jokainen kerros omaan fyysiseen porttiinsa pfSensessä (bridge). Kaikille kerroksille täytyisi juosta samat VLANit. Kytkimet eivät ole kytkettyjä toisiinsa muuta kuin tuon pfSensen kautta.

Konffeja tai screenshotteja konffista voin kyllä jakaa, ja oikeastaan mitä vaan pystyn testaamaan. Täytyy vaan vähän valita aikaa, kun kooman seurauksena koko perhe on ilman internettiä sen aikaa kunnes saan palautettua edellisen version

Yhdellä bridgellä tuo ei onnistu, mutta suorituskykyperspektiivistä sillä ei ole mitään merkitystä. Koska bridget ovat ns. softakytkimiä, tai tässä kontekstissa kytkinportteja, paketit pyöräytetään aina CPU:n kautta. Tässä pseudokonfia millä tuo onnistuu:

Fyysiset interfacet:
- eth0
- eth1
- eth2
- eth3

VLAN-interfacet:
- eth0-vlan10
- eth0-vlan11
- eth0-vlan12
- eth0-vlan13

- eth1-vlan10
... jne, kaikille vlaneille minkä liikennettä portista liikutellaan.

Bridget:
- br-mgmt (tägäämätön liikenne tukareille yms.)
- br-vlan10
- br-vlan11
... jne.

br-mgmt:ssä sillataan eth0-3, jolloin "perusverkko" toimii suoraan tägäämättömille paketeille
br-vlan10 sillataan eth0-vlan10, eth1-vlan10... Jos haluat jonkin interfaceista juttelemaan vlan10 L2 verkkoon ilman tägejä, voit lisätä sen tähän bridgeen suoraan, vaikkapa eth3.


Jos haluaa enemmän kytkinmäisen konfiguraation niin bridget voi vaihtaa openvswitchiin. Pitäisi olla FreeBSD:llä tuettu, en tiedä saako pfSenseen kuinka helposti asennettua ja onko hallintakälissä tukea sille.

 

[ponky]

rp_filter on kaikissa interfaceissa nolla.

Ongelma sekä selvisi, että ei selvinnyt

wan3.network:

[Match]
Name=wan3

[Network]
DHCP=ipv4

[DHCP]
RouteTable=130

[RoutingPolicyRule]
OutgoingInterface=wan3
Table=130

Tämä johtaa tälläiseen lopputulokseen (wan0 ei ole RouteTable määritystä lainkaan):
$ ip route

default via xx.xx.91.1 dev wan0 proto dhcp src xx.xx.91.10 metric 1024
xx.xx.91.0/24 dev wan0 proto kernel scope link src xx.xx.91.10 metric 1024
xx.xx.91.1 dev wan0 proto dhcp scope link src xx.xx.91.10 metric 1024

$ ip route show table 130

default via xx.xx.91.1 dev wan3 proto dhcp src xx.xx.91.84 metric 1024
xx.xx.91.0/24 dev wan3 proto dhcp scope link src xx.xx.91.84 metric 1024
xx.xx.91.1 dev wan3 proto dhcp scope link src xx.xx.91.84 metric 1024

$ ip rule

0:      from all lookup local
5000:   from yy.yy.0.0/20 to yy.yy.0.0/20 lookup 5000 proto static
32757:  from all oif wan3 lookup 130 proto static
32761:  from yy.yy.3.0/24 iif lan3 lookup 130 proto static
32766:  from all lookup main
32767:  from all lookup default

Tässähän käy niin, että Elisa tarjoilee liki peräkkäisiä ip-osoitteita kaikille wan interfaceille ja jokaisessa on sama gateway.

Tällä setupilla pingatessa ulkoa päin wan3 ip:tä xx.xx.91.84, vastaukset lähtee wan0:sta, mutta wan3:n ip:llä.

Kun lisään käsin rulen wan3:n ip-osoitteella:
ip rule add from xx.xx.91.84 table 130
Alkaa paketit kulkemaan oikein wan3:n kautta.

Ongelma on se, että en keksinyt yksinkertaista keinoa jolla saisi tuon ip rulen lisättyä siinä vaiheessa kun Elisan DHCP tarjoilee leasen.
Toki voin ottaa käyttöön networkd-dispatcher:n ja kirjoitella scriptin joka rulen tekee aina kun lease saadaan, mutta siitä joutuu tekemään ikävän monimutkaisen jos huomioi sen, että ip-osoite voi myös vaihtua lennosta. Tosin Elisa kyllä pääsääntöisesti tarjoaa aina saman ip:n leasen uudistuksessa, mutta jos esim. gfast silta on tunnin pari virrattomana ja itse gateway on tämän ajan käynnissä, niin osoitteet todennäköisesti vaihtuvat ja vanha ip rule pitäisi siivota pois uuden alta.

Edit: rulen lisäämisen jälkeen:
$ ip rule

0:      from all lookup local
4999:   from xx.xx.91.84 lookup 130
5000:   from yy.yy.0.0/20 to yy.yy.0.0/20 lookup 5000 proto static
...

Jeps, tuo vaatii tosiaan Routing Policyn. Dynaamisten IP:eiden tapauksessa tämän voi hoitaa lisäämällä ip-/nftablesiin säännön, joka lisää fwmarkin paketteihin jotka saapuvat wan-interfaceihin sekä [RoutingPolicyRule] -kentän networkd:n konfiin, joka sitten markin perusteella leipoo paluupaketit menemään oikeaan tauluun takaisin lähettäessä. En ole itse nähnyt tarvetta tälle, koska reititin ei palvele VPN:n lisäksi ulospäin mitään ja VPN yhdistetään aina "pää" interfaceen joka reititetään local-taulussa.

Eli jotain tähän suuntaan:

wan3.network:

[RoutingPolicyRule]
FirewallMark=130
Table=130

nftables

nft add rule ip mangle PREROUTING iifname wan3 meta mark set 130
nft add rule ip mangle PREROUTING meta mark set ct mark

 

[Khauron]

Okei. Kiitos. Taidanpa jättää tämän hautumaan, ja kokeilla uudestaan joskus tulevaisuudessa kun on taas motivaatiota.
Tällä hetkellä kaikki toimii hienosti, ja juuri managed-kytkimen läpi. Kytkin on 1 GBit/s, joten ehkä pienen nopeushyödyn voisi saada jos sen tiputtaisi pois ja ajaisi pfSense-purkin 2.5 GBit/s -porteilla. Vaikkakin paketit menevät CPU:n kautta.

 

[ponky]

Okei. Kiitos. Taidanpa jättää tämän hautumaan, ja kokeilla uudestaan joskus tulevaisuudessa kun on taas motivaatiota.
Tällä hetkellä kaikki toimii hienosti, ja juuri managed-kytkimen läpi. Kytkin on 1 GBit/s, joten ehkä pienen nopeushyödyn voisi saada jos sen tiputtaisi pois ja ajaisi pfSense-purkin 2.5 GBit/s -porteilla. Vaikkakin paketit menevät CPU:n kautta.

Mikä tahansa nykypäivän rauta jaksaa jyrsiä tuon 2.5Gbps jos liikenne on suodattamatonta L2-liikennettä, onnistuu vaikka Raspilla. Pullonkaulaa alkaa muodostua vasta monimutkaisilla muurisääntöseteillä ja silloinkin vain isommilla nopeuksilla ja tilattomilla muureilla. Perus setupeissa on aina käytössä tilallinen hallinta yhteyksille (established, related) jolloin auki olevien yhteyksien liikenne menee ns. ohituskaistaa pitkin pihalle eikä käy koko muurisäännöstöä läpi.

 

[jad]

Jeps, tuo vaatii tosiaan Routing Policyn. Dynaamisten IP:eiden tapauksessa tämän voi hoitaa lisäämällä ip-/nftablesiin säännön, joka lisää fwmarkin paketteihin jotka saapuvat wan-interfaceihin sekä [RoutingPolicyRule] -kentän networkd:n konfiin, joka sitten markin perusteella leipoo paluupaketit menemään oikeaan tauluun takaisin lähettäessä. En ole itse nähnyt tarvetta tälle, koska reititin ei palvele VPN:n lisäksi ulospäin mitään ja VPN yhdistetään aina "pää" interfaceen joka reititetään local-taulussa.

Itseasiassa tuota fwmarkia jo aiemmin pikaisesti testasin, mutta näin iptablesiin tottuneena en onnistunut arpomaan oikeita loitsuja nftableille. Nyt kun tuon nftablesin kanssa on ehtinyt vähän temuta, niin alkaa jo olemaan parempi ymmärrys ja onhan tuo loppupeleissä melkoinen edistysaskel perinteiseen iptables hässäkkän, jolla nykyisen palomuuri/gateway koneen olen conffinut.
En minäkään ole vielä lainkaan varma siitä, onko tälle ikinä mitään tarvetta, mutta onpahan toiminnassa jos jotain tarvetta keksin. Sen verran tapoihini jumittunut kuitenkin olen, että en kovin mielelläni palomuurikoneeseen mitään ylimääriäisiä palveluita asentele.

Kiitos taas kun tuuppasit oikeaan suuntaan, lopulta näin se lähti toimimaan:

nft add table ip mangle
nft 'add chain ip mangle input { type filter hook input priority 0; }'
nft 'add chain ip mangle output { type route hook output priority 0; }'
nft add rule ip mangle input iifname wan3 ct mark set 130
nft add rule ip mangle output meta mark set ct mark

$ nft list table mangle

table ip mangle {
        chain input {
                type filter hook input priority filter; policy accept;
                iifname "wan3" ct mark set 0x00000082
        }

        chain output {
                type route hook output priority filter; policy accept;
                meta mark set ct mark
        }
}

Huomionarvoista tässä on se, että set ct mark pitää pistää route- ketjuun output hookila, prerouting filter oli väärä paikka tälle. wan3 markin olisi voinut laittaa myös prerouting filtteriin, mutta päädyin nyt käyttämään inputtia.

 

[user9999]

Tuli hommattua kiinalainen pommi HUNSN RJ35.

Prosessori: Intel i3-N305 eli Alder Lake-N sarjaa ja kaikki E-ytimiä.
Muisti: Crucial RAM 8GB DDR5 4800MHz (CT8G48C40S5)
Levy: Crucial P3 500GB M.2 PCIe Gen3 NVMe
Verkkokortit: 4 x 2.5GbE I226-V

Paketin virrankulutus on noin 12W idlessä kun kaksi verkkokorttia käytössä. Kaikki bios jutut on oletuksena ja täytyy katsoa vielä mitä säätöjä on prosessoriin. Lämmöt näyttää pysyvän hyvällä tasolla vaikka on fanless.

 

[sra2010]

Mikä tahansa nykypäivän rauta jaksaa jyrsiä tuon 2.5Gbps jos liikenne on suodattamatonta L2-liikennettä, onnistuu vaikka Raspilla. Pullonkaulaa alkaa muodostua vasta monimutkaisilla muurisääntöseteillä ja silloinkin vain isommilla nopeuksilla ja tilattomilla muureilla. Perus setupeissa on aina käytössä tilallinen hallinta yhteyksille (established, related) jolloin auki olevien yhteyksien liikenne menee ns. ohituskaistaa pitkin pihalle eikä käy koko muurisäännöstöä läpi.

Eikö tuo kuitenkin ole jo L3, kun eri vlan välillä reititetään ja luultavasti niistä verkoista on tarkoitus päästä myös ulkoverkkoon? Tuohon Khauronin asiaan viitaten.

 

[escalibur]

No nyt on halpaa pfSense-rautaa

AMSO Computer Laptops gebrauchte Einkaufen

AMSO Computer aus Leasing, Wir sind ein Fachhändler für gebrauchte Leasinggeräte Geräten Dell business, HP, Lenovo und anderen Leasing-Geräte. Zu unserem angeboten gehören ständig Monitore, Drucker, Server, Smartphone. Alles mit Garantie.

amso.eu

(Postikulut Suomeen 9,90€)

 

[Gobi]

No nyt on halpaa pfSense-rautaa

AMSO Computer Laptops gebrauchte Einkaufen

AMSO Computer aus Leasing, Wir sind ein Fachhändler für gebrauchte Leasinggeräte Geräten Dell business, HP, Lenovo und anderen Leasing-Geräte. Zu unserem angeboten gehören ständig Monitore, Drucker, Server, Smartphone. Alles mit Garantie.

amso.eu

(Postikulut Suomeen 9,90€)

Laitoin yhden tilaukseen. Katsotaan tuleeko ikinä ja miten giganen saturoi tuon. Mutta tulisi ensisijaisesti varaboksiksi odottamaan varsinaisen raudan lahoa, siihen passaa oikein hyvin.

 

[escalibur]

Laitoin yhden tilaukseen. Katsotaan tuleeko ikinä ja miten giganen saturoi tuon. Mutta tulisi ensisijaisesti varaboksiksi odottamaan varsinaisen raudan lahoa, siihen passaa oikein hyvin.

Muista vaan hommata toisen verkkokortin ja PCI-E riserin tuohon. Tuo voi olla varsin pätevä laite juurikin varalaitteena tms.

 

[Desgorr]

No nyt on halpaa pfSense-rautaa

AMSO Computer Laptops gebrauchte Einkaufen

AMSO Computer aus Leasing, Wir sind ein Fachhändler für gebrauchte Leasinggeräte Geräten Dell business, HP, Lenovo und anderen Leasing-Geräte. Zu unserem angeboten gehören ständig Monitore, Drucker, Server, Smartphone. Alles mit Garantie.

amso.eu

(Postikulut Suomeen 9,90€)

Taisi mennä nopeasti: "You cannot place an order, because we have insufficient number of products you are trying to order."

 

[Gobi]

AMSO Computer Laptops gebrauchte Einkaufen

AMSO Computer aus Leasing, Wir sind ein Fachhändler für gebrauchte Leasinggeräte Geräten Dell business, HP, Lenovo und anderen Leasing-Geräte. Zu unserem angeboten gehören ständig Monitore, Drucker, Server, Smartphone. Alles mit Garantie.

amso.eu

Vähän kalliimpaa löytyy vielä.

 

[Gobi]

Muista vaan hommata toisen verkkokortin ja PCI-E riserin tuohon. Tuo voi olla varsin pätevä laite juurikin varalaitteena tms.

Nuo löytyy nykyisestä palomuurista.

Edit. Riseri onkin varmaan mallikohtainen.

 

[escalibur]

Taisi mennä nopeasti: "You cannot place an order, because we have insufficient number of products you are trying to order."

Eiköhän nuo mene nopeasti kun erät on varmaan melko pieniä ja osa laitteista todella päteviä moneenkin eri käyttöön. Tässä on esim listaus ~100€ hintaluokan vaihtoehdoista. AMSO Off-Lease Refurbished Computers, Laptops, PCs, Smartphones

 

[samim]

Sophokselta v20 EAP, jossa pitäisi olla IPv6 DHCP-PD.

Sophos Firewall v20 Early Access Announcement

We are pleased to announce that the Early Access Program (EAP) is now underway for the latest and greatest Sophos Firewall OS release. This update to Sophos Firewall brings a number of exciting enhancements and top-requested features. Active Threat ...

community.sophos.com

 

[AkQ]

No nyt on halpaa pfSense-rautaa

AMSO Computer Laptops gebrauchte Einkaufen

AMSO Computer aus Leasing, Wir sind ein Fachhändler für gebrauchte Leasinggeräte Geräten Dell business, HP, Lenovo und anderen Leasing-Geräte. Zu unserem angeboten gehören ständig Monitore, Drucker, Server, Smartphone. Alles mit Garantie.

amso.eu

(Postikulut Suomeen 9,90€)

tarkoitat varmastikkin OPNsense? vai onko sulla jokin muu syy pelkästään, vain ja ainoastaan pfsense-hehkutukselle?

 

[escalibur]

tarkoitat varmastikkin OPNsense? vai onko sulla jokin muu syy pelkästään, vain ja ainoastaan pfsense-hehkutukselle?

Ainakaan toistaiseksi mulla ei ole minkälaista kokemusta OPNsensestä. Tämän vuoksi itse keskityn pfSenseen.

 

[Infinity]

Aika vähän duunissa maastossa OPNsenseä on näkynyt, pfSenseä lähinnä jos ei ole Ciscoa infrat ollut alusta loppuun. Tuon takia itsekin kotona päätin aikoinaan valita pfSensen, saa kokemusta ja jippoja jos osuu tuulettimeen työpaikoilla.

Homelab harrastajille OPNsense varmaan se fiksuin ja loogisin vaihtoehto, itsekin siihen todennäköisesti päätyisin tällä hetkellä, jos lähtisin puhtaalta pöydältä kotiverkkoa kasaamaan. Turha pfSensen valinneita silti on alkaa sormella osoittamaan, toimiva ja vakaa muurikäyttis sekin vaikka ylläpitävä firma onkin ollut mulkun maineessa.

 

[Enhancer]

Pyydän hiukan apua, koska näin syvällä muuriasioissa ei ole tullut vielä oltua.

Oma vaatimukseni reitittimeltä / muurilta on 10gb valmiudet tulevaisuutta varten, 3 wanin käyttö kuitu/RJ45 pitkin, 2 näistä kuormanjaolla ja kolmas varayhteytenä molempien pääyhteyksien pettäessä. NextDNS käytössä, tällä hetkellä käyttäen DNS-over-HTTPS, tavalla tai toisella siis NextDNS saatava toimimaan (kaikki sisäverkon DNS-kyselyt pakotetusti NextDNS:lle). Noiden lisäksi normaalit kuviot, 4 VLAN:a, jokaiselle oma SSID:nsä. Suorituskyky tietenkin oltava kunnossa. Verkon sisällä pitää mDNS toimia, esimerkkinä vaikkapa tulostin tai Android TV joiden haku verkosta perustuu mDNS:n.

Nyt setup toteutettuna TP-Linkin Omada -sarjan kamoilla, rauta erittäin hyvää mutta softa kuraa ja perusasiat täysin hukassa. Esimerkkinä IPv6 palomuuria ei reitittimessä ole ollenkaan, vaan päästää oletuksena kaiken liikenteen läpi?!. Tykkäisin ajatuksesta, että kaikki olisi jatkossakin keskitetysti hallinnassa, ja Ubiquitin Unifi toki vastaisi valtaosaan näistä huudoista. Siinä tosin vain Dual-WAN -tuki tällä hetkellä, mutta muuten homman saisi toimimaan. Tiedän, että ominaisuuksiltaan ei puhuta edes samalla hehtaarilla olevista tuotteista, mutta toisaalta mikä lisäarvo omiin vaatimuksiini nähden sitten xxSensestä minulle olisi?

PfSense / OPNsense voisi sinällään kiinnostaa, jo ihan osaamisenkin syventämisen näkökulmasta. Kytkimet ja tukiasemat voisin pitää kunnollisen reitittävän muurin kaverina vaikka sitten Omada-taustaisina, tai miksei sitten ne vaikka erikseen Ubiquitilta kuten monet tekevät.

 

[Pakana]

@Enhancer, Ei kyllä kannata laittaa useampaa tonnia reitittimeen vaan siksi että se mahdollisesti tulevaisuudessa tulevan 10G netin pystyy hanskaamaan. 10G vaatii jo oikeasti aika järeää rautaa, eikä mikään kuluttajalaite tuohon kykene, vaikka 10G kykenevä sfp portti voikin olla.

Jos nuo omada tukarit on sulle ok, niin käytä niitä ja laita jokin tulevampi xxxSense reititin. Moneen omadaan saa myös openwrt:n sisään joka mahdollistaa orkkisfirmistä laajemmat säädöt.

 

[Enhancer]

@Enhancer, Ei kyllä kannata laittaa useampaa tonnia reitittimeen vaan siksi että se mahdollisesti tulevaisuudessa tulevan 10G netin pystyy hanskaamaan. 10G vaatii jo oikeasti aika järeää rautaa, eikä mikään kuluttajalaite tuohon kykene, vaikka 10G kykenevä sfp portti voikin olla.

Jos nuo omada tukarit on sulle ok, niin käytä niitä ja laita jokin tulevampi xxxSense reititin. Moneen omadaan saa myös openwrt:n sisään joka mahdollistaa orkkisfirmistä laajemmat säädöt.

Tonneja ei. Netgate 6100 katsoin noin esimerkiksi. Konkretisoikaa, mikä käyttökelpoinen ominaisuus xSensestä löytyy, mitä Ubiquitin reitittimistä ei löydy?

 

[Infinity]

Ubiquiti tekee hyviä kytkimiä ja tukareita joita itselläkin on käytössä, mutta muuria/reititintä en sieltä ottaisi.

 

[sra2010]

Tonneja ei. Netgate 6100 katsoin noin esimerkiksi. Konkretisoikaa, mikä käyttökelpoinen ominaisuus xSensestä löytyy, mitä Ubiquitin reitittimistä ei löydy?

Xsenseä voi ajaa omalla raudalla ja mahdollisuus asentaa tarvitsemiaan lisäosia. Itsellä käytössä muistaakseni mini-itx kone, jossa 2x1G verkkokortti, tulevaisuudessa voi vaihtaa 10G, mikäli tarvetta ilmenee. Varmuuskopiointi ja palautus on myös kätevä ja toiselle raudalle siirtokin onnistui, kun määritteli interface/vlan asetukset kohdalleen.

 

[Enhancer]

Ubiquiti tekee hyviä kytkimiä ja tukareita joita itselläkin on käytössä, mutta muuria/reititintä en sieltä ottaisi.

Tämä on yleinen, monessakin paikassa vastaan tuleva mielipide, kiitos siitä.

Yritän hahmottaa, että mitä menetän, koska Ubiquitissa saa saman kuin Omadassakin. Vaivattomuutta, keskitetyn hallinnan jne. En nyt muista ulkoa olenko juuri tuon pätkän katsonut, mutta ainakin vastaavia.
Edit: 2 vuotta vanha video, aika isoja päivityksiä ja uutta rautaakin tullut tuon jälkeen.

 

[maninthemoon]

Ubiquiti tekee hyviä kytkimiä ja tukareita joita itselläkin on käytössä, mutta muuria/reititintä en sieltä ottaisi.

Olisiko laiskalle muutama nosto videosta, että miksi ei toimi esim. palomuurina? Just nyt ei jaksa katsoa tuota videota, että miksi se on huono. Ei sillä, että itse tuota edes harkitsisin, mutta ihan yleisestä mielenkiinnosta.

 

[Pakana]

Tämä on yleinen, monessakin paikassa vastaan tuleva mielipide, kiitos siitä.

Yritän hahmottaa, että mitä menetän, koska Ubiquitissa saa saman kuin Omadassakin. Vaivattomuutta, keskitetyn hallinnan jne. En nyt muista ulkoa olenko juuri tuon pätkän katsonut, mutta ainakin vastaavia.
Edit: 2 vuotta vanha video, aika isoja päivityksiä ja uutta rautaakin tullut tuon jälkeen.

Tottakai voit hommata ubiquitin tai omadan reitittimen, ja jos olet jo sen kanssa sinut, niin ihan suositeltava vaihtoehto.

Tosin 10G liittymään kykenevää laitetta ei kumpikaan taida valmistaa, mutta ei mun mielestä muutenkaan raudan hankkiminem jonkun tulevaisuuden tarpeen perusteella ole kovin järkevää, vaan kanmattaa hankkia se vastaava rauta silloin tulevaisuudessa, kun se on halvempaa ja hiotumpaa.

 

[terpaa]

Lounea lupailee sitä 40gbps nettiä tälle vuodelle.
Osaakos kukaan arvailla millasta rautaa tommosta varten pitäs routeriks olla?

 

[samim]

Lounea lupailee sitä 40gbps nettiä tälle vuodelle.
Osaakos kukaan arvailla millasta rautaa tommosta varten pitäs routeriks olla?

Intel 40G Ethernet PCIe x8 1/2-port QSFP

Mullet Scandinavia säljer och distribuerar kvalitetsprodukter för serverbruk och datalagring. Bland våra tillverkare finns: Supermicro, Intel, LSI, Qlogic, Adaptec, Seagate, 3ware, Western Digital, AMD, Samsung, Kingston.

www.mullet.se

Näköjään PCI-e 3.0 ja 8x paikka riittää dual-kortille. Saako tuosta läpi 40Gbit/sec niin se lienee eri juttu.

 

[terpaa]

Intel 40G Ethernet PCIe x8 1/2-port QSFP

Mullet Scandinavia säljer och distribuerar kvalitetsprodukter för serverbruk och datalagring. Bland våra tillverkare finns: Supermicro, Intel, LSI, Qlogic, Adaptec, Seagate, 3ware, Western Digital, AMD, Samsung, Kingston.

www.mullet.se

Näköjään PCI-e 3.0 ja 8x paikka riittää dual-kortille. Saako tuosta läpi 40Gbit/sec niin se lienee eri juttu.

itseäni mietityttää mikä se rajapinta asiakkaan suuntaan on tuossa liittymässä... mulla on noita qsfp28 moduleita.

 

[samim]

itseäni mietityttää mikä se rajapinta asiakkaan suuntaan on tuossa liittymässä... mulla on noita qsfp28 moduleita.

What Is QSFP+ Module: QSFP+ Transceiver Wiki and Types | FS Community

What is QSFP+? How many types of 40G QSFP transceiver do you know? And what's the difference between QSFP and CFP. Get all the answers here.

community.fs.com

 

[haller]

Intel 40G Ethernet PCIe x8 1/2-port QSFP

Mullet Scandinavia säljer och distribuerar kvalitetsprodukter för serverbruk och datalagring. Bland våra tillverkare finns: Supermicro, Intel, LSI, Qlogic, Adaptec, Seagate, 3ware, Western Digital, AMD, Samsung, Kingston.

www.mullet.se

Näköjään PCI-e 3.0 ja 8x paikka riittää dual-kortille. Saako tuosta läpi 40Gbit/sec niin se lienee eri juttu.

PCI-e 3.0 ja 8x taitaa meinata 64 Gb/s, eli pahasti jää vajaaksi 40G jos se pitäisi saada kahteen suuntaan ja kahteen piuhaan. Jos se 40G pitää ihan oikeasti saada läpi, niin joku tällainen pääsee jo lähelle: CCR2216-1G-12XS-2XQ. Tämän ketjun kannalta mielenkiintoisempi tuote voisi olla CCR2004-1G-2XS-PCIe jossa kortille on laitettu 2 x 25G SFP28 porttia ja arm-siru, mutta joku pullonkaula tuossakin on kun mittaustulokset ovat noin "huonot".

 

[sra2010]

https://www.fs.com/de-en/products/141788.html?attribute=67772&id=1709881

Tuossa on nopeampi väylä käytössä, PCI-e 4.0x16, pitäisi riittää 40G käyttöön ja ehkä nopeammallekin. Kommenteissä näytti joku sanovan, että toimii FreeBsd:n kanssa "

Models :2x 100G QSFP28, PCIe 4.0 x 16
Works as expected, provides good throughput, and drivers worked with FreeBSD out of the box.
"
Ei jää netin nopeus palomuuri valinnan takia vajaaksi, Pfsensen kanssa tulevaisuus turvattu

 

[Enhancer]

Dedikoitu rauta on toki aina parempi, mutta onko kenelläkään kokemusta virtuaalikoneessa sensen pyörittämisestä?

Tajusin juuri, että M1 -prossuinen Mac Mini tuli hommattua Amazonista kun halvalla sai, ja siihen tarkoitus laittaa joka tapauksessa pyörimään pilvipalveluiden varmuuskopioinnit ja Home Assistant virtuaalikoneeseen.

Thunderbolt 4 (40Gbps) -portteja on 2, joiden perään saa tarvittaessa tietysti vaikka ulkoista väylää, mutta joka tapauksessa dongleilla X-määrän verkkoportteja aina 10Gbps tasolle asti. Tuoko nuo donglet latenssia tai jotain muuta muuttujaa liikaa?

 

[samim]

Dedikoitu rauta on toki aina parempi, mutta onko kenelläkään kokemusta virtuaalikoneessa sensen pyörittämisestä?

Hyper-Vssä pyörii. 10 Gbit virtuaaliset verkkokortit ja ulospäin giganen portti. Bootti halttas uusimmalla versiolla, mutta sitten lähti toimimaan, kun uhkasi heittää Vmwaren kehiin.

 

[Enhancer]

Hyper-Vssä pyörii. 10 Gbit virtuaaliset verkkokortit ja ulospäin giganen portti. Bootti halttas uusimmalla versiolla, mutta sitten lähti toimimaan, kun uhkasi heittää Vmwaren kehiin.

Eipä tuossa kokeilemalla korkealta putoa. Taidan aloittaa sillä, että laitan tuohon masiinaan vain yhden Thunderbolt -> 10GbE donglen, ja otan WAN:t kytkimiltä omia VLAN pitkin. En ole koskaan aiemmin tuota noin toteuttanut, vaan aina tuonut WAN:t reitittimen korvamerkittyihin portteihin. Ei ideaali, mutta riittää toistaiseksi mainiosti kun sisäverkossakaan harvoin yli 3-4Gbps nopeuksille on tarvetta.

 

[Jusaus_IT]

Ubiquiti tekee hyviä kytkimiä ja tukareita joita itselläkin on käytössä, mutta muuria/reititintä en sieltä ottaisi.

Hyvä video, mutta tiedot lokakuun 2021 tilanteessa.

Tässä vähän tuoreempi, lähempänä nykytilannetta oleva vertailu:

 

[Gobi]

No nyt on halpaa pfSense-rautaa

AMSO Computer Laptops gebrauchte Einkaufen

AMSO Computer aus Leasing, Wir sind ein Fachhändler für gebrauchte Leasinggeräte Geräten Dell business, HP, Lenovo und anderen Leasing-Geräte. Zu unserem angeboten gehören ständig Monitore, Drucker, Server, Smartphone. Alles mit Garantie.

amso.eu

(Postikulut Suomeen 9,90€)

Tämä kone saapui eilen, emolevyllä mini PCIe-liitin, johon pitäisi adapteri löytää. Näyttäisivät kaikki vaativan 12V lisävirtaa siellä varsinaisen PCIe-liittimen päässä, sitä on hintsusti emolla tarjota. Mutta eiköhän tuon saa toimimaan, löysin emolle hyvän manuaalin, jossa selvitys kaikista liittimistä ja mahdollisista virranottopaikoista.

 

[jase]

Tilasin Toptonin N100 purkin, ihan asiallisen olonen laite. Aika paljon lämpeni sinä aikana kun ArchLinuxin asensin, pitää varmaan tarkistaa että kaikki virransäästöasetukset on jiirissä. Vielä kunnolla kalibroimaton virrankulutusmittari sanoi että 10W idlenä.

Sitten vaan opettelmaan networkd:n ja nftablesin konffausta.