Netzwerk Erweiterung Richtfunk mit unifi/ubiquiti NanoBeam

noplan

Grüssi!
Kabel verlegen ist zu viel Aufwand (ja es ist kalt) haben wir schnell
eine NanoBeam 5AC raus geschraubt um von a nach b zu kommen.
Link steht speed ist ok und es rennt halt.

da auf beiden Endpunkten je eine pfS box rennt und zufällig noch ein jeweils ein interface frei ist, KÖNNTE man ja ein bissal herumspielen.

a)
die Richtunfkstrecke auf ein eigenes interface legen, und nur den trafficdrauf schieben der auch über die Strecke soll. (firewall rule für gewisse IPs mit different gateway)

b) den traffic der Richtfunkstrecke in einen VPN Tunnel packen und dann das von pkt a) umsetzen

was eigentlich nicht geplant wäre ist ein streched LAN von einer pfS box zu nächsten.

überseh ich was oder könnte man noch wo herumspielen

lgNP

viragomann

@noplan said in Netzwerk Erweiterung Richtfunk mit unifi/ubiquiti NanoBeam:

a)
die Richtunfkstrecke auf ein eigenes interface legen, und nur den trafficdrauf schieben der auch über die Strecke soll. (firewall rule für gewisse IPs mit different gateway)

Eine simple statische Route für das jeweilige andere Netz, sollte reichen, wenn nur Traffic drüber soll, der für dieses Netz bestimmt ist.

noplan

Jop ich seh das auch so.

Aber es juckt so in den fingern die gesamte Strecke in einen Tunnel zu packen
Hab mir aber noch 0 Null Gedanken gemacht wie das umzusetzen wäre und ob man es überhaupt braucht

Rico

Je nachdem wieviel Horsepower du auf beiden Seiten an der pfSense hast und wieviel Traffic über die Strecke muss/soll ist es schon charmant das Ganze durch IPsec oder OpenVPN zu tunneln.
Im günstigen Segment bedeutet "Richtfunk" ja nichts anderes als WLAN (von der Technik her) und kann u.U. mit einfachen Mitteln angegriffen werden.
Ob das Sinn macht kommt aber auch auf die Art des Traffic an, wenn die Strecke nur gedacht ist um ein weiteres Gateway ins Internet zu haben ist das nicht wirklich kritisch. Greift die Buchhaltung über die Strecke auf interne Server zu, vielleicht sogar über teilweise alte Protokolle die selbst nicht verschlüsseln.....ja bitte alles in einen VPN Tunnel sobald "LAN" Traffic spätestens das Gebäude verlässt, da würde ich mich nicht auf WPA2 oder sowas verlassen wollen. ;-)

-Rico

noplan

jop ich seh das genau so!
und ich kenn diese schnell hingestellten spielereien nur zu gut ;)
die rennen so lange bis irgendwas kaputt.
was viel schlimmer is, man vergisst was alles über diese leitung darf und soll.

performant sollten beide pfS boxen für einen IPsec oder openVPN Tunnel sein.
problem wird halt das beide boxen auch noch ihre ursprungs Aufgaben erfüllen müssen
Firewall / openVPN & pfB aber mal sehen.

da beide boxen openVPN einsetzen, werden wir den Tunnel über Funk wohl mit IPsec spannen
zwecks der Übung wäre es :) und das ich mir um 3 in der Früh nicht überleg wieso da was ist was ich sonst nicht mach ;)

Das Argument mit Buchhaltung & alten Protokollen ist schon spitze
aber der Killer ist LAN Traffic der das Gebäude verlässt !

ich glaub ich geh mal aufzeichnen was da zu erledigen ist
interface aufschalten / ip zuweisen / IPsec einrichten / tunnel spannen / firewall rule LAN -> tunnel netzwerk & tunnel netz -> LAN /

edit002
~~hoffentlich haben die beiden LANs nicht auch noch die gleichen IP Adressen~~ ggg Beide LANs haben die gleichen IP Adressen und auch noch die gleichen DHCP ranges ;(
inkl. Mapping im DHCP. einzig positive Sache ist das die beiden pfs boxen nicht die gleiche LAN ip am eth1 haben. box1 = 0.1 box2 = 0.2

?was hab ich mir da eingetreten?

huch das wird eine nette ~~Spielerei.~~ SPINNEREI

ich halt euch aufm laufenden ... das geht eh siche rnicht so glatt wie ich mir das denk ;)

lgNP

edit001
die beiden Beams als transparente bridge einrichten (die eine als WDS die andere als APf WDS) das müsste das ganze so aussehen lassen als würde man ein Netzwerkkabel spannen, quasi ein WirelessLanKabel ;)

whatever comes in one side goes out the other

edit002

NOCling

Keine Cisco Switch auf beiden Seiten die einen MACsec Tunnel aufbauen können, dann rennt das auch und es ist entsprechend hard verschlüsselt?

Wir haben damit ein paar RiFu Strecken zwischen Gebäuden gesichert über die das komplette LAN läuft.
Da merkst nix von was die Performace angeht, sehr geniale Lösung.

noplan

@NOCling
Problem is aber nix Cisco switch hier bei der Hand ;) nur 2 freie ports auf der pfS (je 1 li & re)

Wird a lustige Sache glaub ich

JeGr

Kommt drauf an wie die beiden NanoBeam5er konfiguriert sind. Wenn die sauber konfiguriert sind mit WPA2 und fettem Key sehe ich das nicht als so einfach an, da "sich reinzuklinken" und dementsprechend auch den Bedarf das alles über nen Tunnel zu juckeln eher geringer. Kommt sicher auch auf die Daten an die Drüberfliegen. Aber sehe da nicht so den Punkt für Doppelverschlüsselung.

Was man machen kann:

WiFi auf zusätzl. Interface packen
Standorte via WiFi verbinden
statisches Routing
gucken obs läuft
VPN über extern / WAN machen (OVPN) und statische Route darüber machen statt über WiFi
gucken obs läuft ^^
wenn beide Alternativen laufen:
- FRR Package auspacken
- OSPF konfigurieren
- WiFi priorisieren, VPN nachranging mitnehmen
- Route in beide Richtungen via FRR/OSPFd verteilen lassen
- testen indem man WiFi abklemmt

Mein Setup bei einem Kunden hatte gerade mal einen Ping gebraucht um zu switchen auf VPN und keinen für Failback. OSPF ist da extrem fix das Gateway zu sehen wenns wieder da ist.

noplan

@JeGr

mein Problem is das ich jetzt genau jetzt einen Denkfehler hab

ich komm von pfs1 auf die beiden antennen
komm aber von pfs2 nicht zu den beiden antennen

komm auch nicht trotz any2any rules auf den beiden (pfs1 & pfs2) auf die anderen Netze

irgendwas mit routing passt nich nicht ...

übers WAN wird das sehr zäh da einen box nur 2Mbit Down und 0,5Mbit up am WAN (best case) hat ... das reicht gerade so für nix !

ich versteh glaub isch die satanischen routen nicht ...

viragomann

@noplan said in Netzwerk Erweiterung Richtfunk mit unifi/ubiquiti NanoBeam:

übers WAN wird das sehr zäh da einen box nur 2Mbit Down und 0,5Mbit up am WAN (best case) hat ... das reicht gerade so für nix !

Das kann aber nur ein alter Vertrag sein. Der letzte Winkel unseres Landes ist doch schon deutlich besser versorgt.

Ein freundlicher Anruf beim Provider sollte reichen, um den Anschluss upzugraden. Falls nicht, dann eben ein unfreundlicher.

noplan

@viragomann

auch der wink mit Anwalt bringt beim provider nix.
denn wenn du auch nix Handy/Daten Empfang hast und das einzige kabel hin geht bist fertig.

ich muss mir die hardware die da liegt anschauen
denn das mieseste das wir hier in AT so am Land haben ist 5Down und 0,5 Up (avg)
7 down und 0,7 up ist unser ADSL Standard.

ich glaub ich brauch jetzt a) kaffee und b) nachhilfe in statischen routen
denn ich will das ding nicht als streched LAN haben

JeGr

@noplan said in Netzwerk Erweiterung Richtfunk mit unifi/ubiquiti NanoBeam:

ich komm von pfs1 auf die beiden antennen
komm aber von pfs2 nicht zu den beiden antennen

Dann liegt da dein Problem. Jede Antenne sollte ja zumindest problemlos von Ihrer Seite aus erreichbar sein? Weiß ja nicht wie du die Antennen konfiguriert hast.

Aber in HH haben wir da ein Setup, da ist (bspw.):

pfS-A (10.1.2.1/24) - Antenne A (10.1.2.2/24) --- Antenne B (10.1.2.253/24) - pfS-B (10.1.2.254/24)

Und da kann jede Seite 1/2/3/4 die Reihe durch anpingen.

noplan

@JeGr said in Netzwerk Erweiterung Richtfunk mit unifi/ubiquiti NanoBeam:

Was man machen kann:

WiFi auf zusätzl. Interface packen erledigt auf beiden boxen
Standorte via WiFi verbinden erledigt Verbindung steht und hat guten Durchsatz 100 Mbit Sync
statisches Routing !! satanische ROUTEN !! auweh --> ToDo
gucken obs läuft !! ab hier breaking point da zuerst das statische routing gelöst werden muss

und ja OSPF und will man einfach haben wenn man sich schon so herumspielt !
es wäre aber schon auch noch sehr cool wenn man den bereits im WPA2 verpackten traffic noch einmal in einen VPN tunnel packt oder ?

JeGr

Find ich zwar sinnlos aber kann man machen.

Und WTF, ne statische Route aufs LAN von A via Interface Adresse Wifi von A ist doch jetzt kein übles Drama? Nimm dir ein Snickers, du bist nicht du wenn du Hunger hast

Ansonsten mach'n Netzplan, dann zeig ich dir deine Routen ;)

noplan

@JeGr said in Netzwerk Erweiterung Richtfunk mit unifi/ubiquiti NanoBeam:

pfS-A (10.1.2.1/24) - Antenne A (10.1.2.2/24) --- Antenne B (10.1.2.253/24) - pfS-B (10.1.2.254/24)
Und da kann jede Seite 1/2/3/4 die Reihe durch anpingen.

hmm ... ja jetzt wirds komisch.
die IP Aufteilung ist fast exkt so wie im BSP.
lediglich die beiden Antennen haben als Gateway (zuwas auch immer) die IP der pfS-A

was funktioniert:

von LAN hinter pfs-A auf beide Antennen kommen ssh & web
funktstrecke mittels Antennen tools testen
logfiles & states werden auf der pfS-A angezeigt
von bash pfs-A mittels ssh auf pfs-B kommen

was NICHT funktioniert:

to be ...

..... ich habe kein Snickers zur Hand ... ich geh jetzt mint Hund zur Tanke und hol mir was zum essen .....

noplan

@JeGr said in Netzwerk Erweiterung Richtfunk mit unifi/ubiquiti NanoBeam:

dann zeig ich dir deine Routen

ich glaub ich geh a) zuerst was essen
b) hardware suchen
c) das upgraden

und dann schau ma weiter ;)

JeGr

@noplan said in Netzwerk Erweiterung Richtfunk mit unifi/ubiquiti NanoBeam:

lediglich die beiden Antennen haben als Gateway (zuwas auch immer) die IP der pfS-A

Warum? Macht ja nur begrenzt Sinn. A zu A und B zu B. Bei WiFi Ausfall will man ja Zugriff haben ;)

und dann schau ma weiter ;)

Es ist halt komplett einfach:

Seite A (.1) bekommt ein neues GW auf dem WiFi Interface wo die Nanos dran hängen auf die .254 (Seite B pfSense).
Seite B (.254) bekommt ein Gateway auf die .1 von Seite A

die beiden anderen (Nanos) sind komplett irrelevant (.2 / .253) und nur wenn man die WifiBridge reparieren müsste entscheidend.

Wenn man die GWs auf dem WiFi Interface auf jeder Seite hat (pingbar) ist die Chose eigentlich gelaufen. Dann trägste auf Seite A ne statische Route fürs Netz von B mit GW Wifi-B ein und machst das ganze umgekehrt auf Seite B mit statischer Route fürs Netz von A zum GW Wifi-A. Fertig ist der Lack.

DANACH kann man immer noch mit OSPF oder Kram rumspielen.

noplan

@JeGr said in Netzwerk Erweiterung Richtfunk mit unifi/ubiquiti NanoBeam:

Macht ja nur begrenzt Sinn

solange du von pfS-A Zugriff auf beide Antennen haben willst brauchst das gateway gleich in diesem Fall die IP d pfS-A. (zwecks d Administration behaupte ich jetzt kühn)

wenn das wifi weg ist kannst eh nur am mast klettern und dir die Antenne anschauen
Diagnose ist bei den Teilen nicht ;)

auswirkungen hat das gateway ja NULL auf die Funkstrecke.

noplan

@JeGr
pfs-A kann pfs-B von der Console aus pingen gleiches gilt für umgekehrt und auch für ssh

jetzt sind wir wieder bei square 1 (essen holen und routen legen) oder seh ik das falsch?

JeGr

@noplan said in Netzwerk Erweiterung Richtfunk mit unifi/ubiquiti NanoBeam:

solange du von pfS-A Zugriff auf beide Antennen haben willst brauchst das gateway gleich in diesem Fall die IP d pfS-A. (zwecks d Administration behaupte ich jetzt kühn)

Nö. Gleiches Subnetz braucht kein Gateway. Das kannst du simpel mit Outbound NAT auf WiFi lösen, dass das zu Admin Zwecken auf beiden Seiten erreichbar ist, aber WiFi-down tritt eher auf, als dass die andere pfSense weg ist (der Erfahrung nach) und daher komme ich via VPN bspw. an beide pfSensen problemlos ran - wenn aber WiFi weg ist an die andere Antenne schwerer. Aber geht beides.

jetzt sind wir wieder bei square 1 (essen holen und routen legen) oder seh ik das falsch?

Essen ist immer gut.
Da hast du Bild:

A bekommt GW y.y.y.254 angelegt
B bekommt GW y.y.y.1 angelegt

x.x.x.0/24 ist Seite A
z.z.z.0/24 ist Seite B

statische Route auf Seite A:
z.z.z.0/24 via GW B (y.y.y254)

statische Route auf Seite B:
x.x.x.0/24 via GW A (y.y.y.1).

Fertig