Routingregel über 2 IPfire in Kundennetz -- wie?

Wie kann man das Konfigurieren?
puls
Posts: 24
Joined: May 23rd, 2019, 3:01 pm
Location: Berlin

Routingregel über 2 IPfire in Kundennetz -- wie?

Post by puls » May 29th, 2019, 2:54 pm

Hallo, nachdem das NATten meiner Pakete so gar nicht funktionieren will, versuche ich jetzt die Pakete über ein zweites Netz zu routen, von welchem aus ebenfalls eine Verbindung in das Zielnetz besteht.

Ich definiere mal was:
Unser Netz ist 192.168.1.0/24
Das Zielnetz ist 10.0.0.0/24
Das Zwischennetz ist 172.22.0.0/16

Der sendende Host sei 192.168.1.245
Der Zielhost sei 10.0.0.31
Und der Zwischenhost sei 172.22.0.40
Alle Hosts laufen mit Linux (Debian bzw CentOS).

Folgendes Szenario: Es existiert ein VPN von IPfireA (192.168.1.1) nach IPfireB (172.22.0.100) und ein zweites VPN von IPfireB in das Zielnetz. 192.168.1.245 will jetzt auf 10.0.0.31 zugreifen. Die Pakete müssen jedoch über den Host 172.22.0.40 laufen, da nur dieser das VPN nutzen darf. 172.22.0.40 muss die Pakete also maskieren, damit sie seine IP als Absender erhalten.

Wenn ich direkt auf 192.168.1.245 eine Route anlegen will, die für das Netz 10.0.0.0/24 das Gateway auf 172.22.0.40 setzt, weigert sich das System:

Code: Select all

# ip route add 10.0.0.0/24 via 172.22.0.40
RTNETLINK answers: Network is unreachable
Setze ich diese Regel im WUI von IPfireA und versuche 10.0.0.31 zu erreichen, kommt auf 172.22.0.40 nichts an. Weder wenn ich von 192.168.1.245 pinge, noch wenn ich direkt von IPfireA pinge. Auf IPfireA ist das routing aber gesetzt:

Code: Select all

# ip route list table all
10.0.0.0/24 via 172.22.0.40 dev ppp0 table static proto static
172.22.0.0/16 dev ppp0 table 220 proto static scope link src 192.168.1.1
[...] 
Ein ping von 192.168.1.245 auf 172.22.0.40 funktioniert natürlich perfekt.
Da auf 172.22.0.40 schon keine Pakete für 10.0.0.0/24 ankommen, kann auch die NAT-Regel nicht angewendet werden. Aktiviert ist sie:

Code: Select all

# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources: 
  services: ssh dhcpv6-client
  ports: xxxx/tcp yyyy/tcp zzzz/tcp
  protocols: 
  masquerade: yes
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 
Habe ich hier einen offensichtlichen Denkfehler aktiv? Oder muss das Routing wegen der VPN ganz anders aussehen? Bin für jeden Hinweis dankbar! :D

RadioCarbon
Posts: 4
Joined: February 23rd, 2017, 7:39 am

Re: Routingregel über 2 IPfire in Kundennetz -- wie?

Post by RadioCarbon » May 29th, 2019, 7:09 pm

Wie lauten die Netzwerke der VPNs?
Nicht, dass du dort schon die IP-Bereiche hast, zu denen du eigentlich hin willst.
Image

fredym
Posts: 497
Joined: November 14th, 2016, 2:45 pm

Re: Routingregel über 2 IPfire in Kundennetz -- wie?

Post by fredym » May 30th, 2019, 7:22 am

Hallo,
es fehllen paar Infos, aber

Code: Select all

# ip route add 10.0.0.0/24 via 172.22.0.40

setzt voraus, daß 172.22.0.40 dem lokalen System bekannt ist (also das Tunneleingsdevice ist)
Folgendes Szenario: Es existiert ein VPN von IPfireA (192.168.1.1) nach IPfireB (172.22.0.100) und ein zweites VPN von IPfireB in das Zielnetz. 192.168.1.245 will jetzt auf 10.0.0.31 zugreifen. Die Pakete müssen jedoch über den Host 172.22.0.40 laufen, da nur dieser das VPN nutzen darf. 172.22.0.40 muss die Pakete also maskieren, damit sie seine IP als Absender erhalten.
ip route add 10.0.0.0/24 via 192.168.1.1
-> der schickt es zum Tunnelausgang (192.168.1.2 ?) -> dort weiter...?

Was oben fehlt sind eindeutige IFs (auch Tunnel)- unterm Strich -> du routest NICHT von Netz zu Netz sondern von Device zu Device (!) durch die Netze.
ggfs. beachten daß VPN-Devices ( bei openVPN ist es definitiv so) verschwinden (incl. Route) wenn der Tunnel zusammen weg ist.
Habe das mit einem Script gelöst .
Durch 3..4 Netze hindurchrouten ist nicht das Thema - SNAT habe ich dabei nie verwendet, aber das ist ein anders Thema.

Fred

ps: und man macht kien ping !! wenn schon verwendet man traceroute , um zu sehen, wo die Pakete (manchmal falsch) langlaufen!

puls
Posts: 24
Joined: May 23rd, 2019, 3:01 pm
Location: Berlin

Re: Routingregel über 2 IPfire in Kundennetz -- wie?

Post by puls » May 31st, 2019, 4:05 am

RadioCarbon wrote:
May 29th, 2019, 7:09 pm
Wie lauten die Netzwerke der VPNs?
Nicht, dass du dort schon die IP-Bereiche hast, zu denen du eigentlich hin willst.
Die Netzwerke sind eindeutig. Hinter jedem VPN Endpunkt steht das jeweilige lokale Netzwerk. Also ein 192-er, ein 172-er und ein 10-er.

puls
Posts: 24
Joined: May 23rd, 2019, 3:01 pm
Location: Berlin

Re: Routingregel über 2 IPfire in Kundennetz -- wie?

Post by puls » May 31st, 2019, 4:30 am

fredym wrote:
May 30th, 2019, 7:22 am
Hallo,
es fehllen paar Infos, aber

Code: Select all

# ip route add 10.0.0.0/24 via 172.22.0.40

setzt voraus, daß 172.22.0.40 dem lokalen System bekannt ist (also das Tunneleingsdevice ist)
Dann müsste es ja spätestens mit der Route auf IPfire klappen. :-\
Folgendes Szenario: Es existiert ein VPN von IPfireA (192.168.1.1) nach IPfireB (172.22.0.100) und ein zweites VPN von IPfireB in das Zielnetz. 192.168.1.245 will jetzt auf 10.0.0.31 zugreifen. Die Pakete müssen jedoch über den Host 172.22.0.40 laufen, da nur dieser das VPN nutzen darf. 172.22.0.40 muss die Pakete also maskieren, damit sie seine IP als Absender erhalten.
ip route add 10.0.0.0/24 via 192.168.1.1
-> der schickt es zum Tunnelausgang (192.168.1.2 ?) -> dort weiter...?
Obige Regel würde auf einem Arbeitsplatz zum Einsatz kommen, richtig? Das macht wiederum nur Sinn, wenn 192.168.1.1 (mein IPfireA) auch weiss, über welche Strecke es das 10-er Netz erreichen kann. Also muss ich ihm beibringen, dass das Netz über den Zwischenhost geroutet werden muss.
Was oben fehlt sind eindeutige IFs (auch Tunnel)- unterm Strich -> du routest NICHT von Netz zu Netz sondern von Device zu Device (!) durch die Netze.
ggfs. beachten daß VPN-Devices ( bei openVPN ist es definitiv so) verschwinden (incl. Route) wenn der Tunnel zusammen weg ist.
Habe das mit einem Script gelöst .
Beide VPN sind auf IPsec basiert, da gibt es leider keine Devices. Daran bin ich schon im verlinkten Beitrag gescheitert.
Durch 3..4 Netze hindurchrouten ist nicht das Thema - SNAT habe ich dabei nie verwendet, aber das ist ein anders Thema.
Das SNAT ist in jedem Fall Pflicht, da wir mit unserem Netz nicht in das Kundennetz kommen. Das ist dort bereits anderweitig belegt.
ps: und man macht kien ping !! wenn schon verwendet man traceroute , um zu sehen, wo die Pakete (manchmal falsch) langlaufen!
:-[ shame on me, der Frustlevel hat offenbar meine Netzwerkgrundlagen vernebelt. Danke für das Zurechtrücken!

Also ein traceroute von 192.168.1.245 auf den Zwischenhost 172.22.0.40 sieht so aus:

Code: Select all

$ traceroute 172.22.0.40
traceroute to 172.22.0.40 (172.22.0.40), 64 hops max
  1   192.168.1.1  0,227ms  *  0,409ms 
  2   172.22.0.100  70,951ms  73,239ms  75,985ms 
  3   172.22.0.40  78,654ms !*  70,903ms !*  49,283ms !* 
Also ganz normal über IPfireA, IPfireB auf den Host. Ein traceroute mit Routingeintrag auf IPfireA von 192.168.1.245 auf 10.0.0.31 sieht dagegen so aus:

Code: Select all

$ traceroute 10.0.0.31
traceroute to 10.0.0.31 (10.0.0.31), 64 hops max
  1   192.168.1.1  0,442ms  0,405ms  0,375ms 
  2   *  *  * 
  3   *  *  * 
  4   *  *  * 
  5   *  * ^C
Leider nicht weiter erhellend. Der Routingeintrag auf IPfireA ist vorhanden:

Code: Select all

# ip route list table all|grep 172.22
10.0.0.0/24 via 172.22.10.140 dev ppp0 table static proto static 
172.22.0.0/16 dev ppp0 table 220 proto static scope link src 192.168.1.1 
Jetzt kommt der Punkt, weswegen es nicht klappt. Ein traceroute von IPfireA auf 10.0.0.31 ergibt:

Code: Select all

# traceroute 10.0.0.31
traceroute to 10.0.0.31 (10.0.0.31), 30 hops max, 60 byte packets
 1  217.X.Y.Z (217.X.Y.Z)  27.005 ms  27.559 ms  27.735 ms
 2  * * *
 3  * * *
Das Paket wird direkt über den Telekom-Uplink verschickt! Klar dass es dort nicht geroutet wird. Vielleicht darf bei der Route nicht ppp0 als device gesetzt sein? Das wurde aber automatisch eingetragen, ich habe nur im WUI eine statische Route angelegt. Muss vielleicht noch etwas hinzugefügt werden? Muss ich die Route mit anderen Parametern manuell anlegen?

fredym
Posts: 497
Joined: November 14th, 2016, 2:45 pm

Re: Routingregel über 2 IPfire in Kundennetz -- wie?

Post by fredym » May 31st, 2019, 6:45 am

puls wrote:
May 31st, 2019, 4:30 am

...
Jetzt kommt der Punkt, weswegen es nicht klappt. Ein traceroute von IPfireA auf 10.0.0.31 ergibt:

Code: Select all

# traceroute 10.0.0.31
traceroute to 10.0.0.31 (10.0.0.31), 30 hops max, 60 byte packets
 1  217.X.Y.Z (217.X.Y.Z)  27.005 ms  27.559 ms  27.735 ms
 2  * * *
 3  * * *
Das Paket wird direkt über den Telekom-Uplink verschickt! Klar dass es dort nicht geroutet wird. Vielleicht darf bei der Route nicht ppp0 als device gesetzt sein? Das wurde aber automatisch eingetragen, ich habe nur im WUI eine statische Route angelegt. Muss vielleicht noch etwas hinzugefügt werden? Muss ich die Route mit anderen Parametern manuell anlegen?
wenn ppp0 dein Tunneldevice=Tunneleingang ist - dann ist es richtig..
In sehr seltenen Fällen n ist Tunneleingang = Standardgateway :-). Alte Regel: alles was nicht woanders langgeschickt wird (= route) geht eben aufs Standadgate (wohin auch sonst)

SNAT ...(wenn entfernt ein gleiches Netz da ist )na ja..dann mußt du eben
1. deinen IP-Bereich ändern (?)
2. alles auf EINE IP mappen (die sollte im entfernten Netz frei sein) die für dein Netz als Quelle auftritt

Ansonsten... siehe Beispiel IPFireB -> wer auf Pakete eine Antwort will, muß natürlich auch die Route für den Rückweg setzen! Ich vermute mal, der weiß nicht "den Weg nach Hause" ...und probierts mit dem "Standardweg"...


Ansonsten... ich habe noch NIE mit IPSec gearbeitet :-), ich hatte immer irgendwo ein NAT dazwischen (oder mehrere) bzw. Consumer-Router, die kein ESP mochten (für portforward)..usw. - aber wäre komisch, wenn IPSec keinen "benannten" Tunneleingang hat.
Wobei (definitiv bei openVPN) "erscheinen" Tunneldevices erst dann, wenn der Tunnel aktiv ist/wird.. sonst gibts die nicht.
d.h. man kann erst danach die Routen setzen (altenativ in VPN-Config reinschreiben, aber die werden auch erst nach dem Tunnelaufbau gesetzt)

Fred

ps: warum du (permanent) n-2n in ein Kundennetz machst, hat sich mir noch nicht erschlossen, statt als RW sich dort im Bedarfsfall einzuwählen. Aber manche (Chef)Wünsche muß man nicht immer verstehen ;-)

puls
Posts: 24
Joined: May 23rd, 2019, 3:01 pm
Location: Berlin

Re: Routingregel über 2 IPfire in Kundennetz -- wie?

Post by puls » May 31st, 2019, 8:18 am

fredym wrote:
May 31st, 2019, 6:45 am
puls wrote:
May 31st, 2019, 4:30 am
...
Jetzt kommt der Punkt, weswegen es nicht klappt. Ein traceroute von IPfireA auf 10.0.0.31 ergibt:

Code: Select all

# traceroute 10.0.0.31
traceroute to 10.0.0.31 (10.0.0.31), 30 hops max, 60 byte packets
 1  217.X.Y.Z (217.X.Y.Z)  27.005 ms  27.559 ms  27.735 ms
 2  * * *
 3  * * *
Das Paket wird direkt über den Telekom-Uplink verschickt! Klar dass es dort nicht geroutet wird. Vielleicht darf bei der Route nicht ppp0 als device gesetzt sein? Das wurde aber automatisch eingetragen, ich habe nur im WUI eine statische Route angelegt. Muss vielleicht noch etwas hinzugefügt werden? Muss ich die Route mit anderen Parametern manuell anlegen?
wenn ppp0 dein Tunneldevice=Tunneleingang ist - dann ist es richtig..
In sehr seltenen Fällen n ist Tunneleingang = Standardgateway :-). Alte Regel: alles was nicht woanders langgeschickt wird (= route) geht eben aufs Standadgate (wohin auch sonst)
Schon klar, soweit verstehe ich Routingregeln auch. Allerdings sind alle VPN-"Eingänge" auf IPfireA auf das device ppp0 gelegt. Ich unterstelle mal, dass IPfire weiss, welches Zielnetz durch welches VPN geroutet werden muss. Trotzdem sendet es ein Paket, das per Routendefinition über ein VPN an 172.22.0.40 gehen sollte, direkt über den Internet-Uplink.
SNAT ...(wenn entfernt ein gleiches Netz da ist )na ja..dann mußt du eben
1. deinen IP-Bereich ändern (?)
2. alles auf EINE IP mappen (die sollte im entfernten Netz frei sein) die für dein Netz als Quelle auftritt
Genau das versuche ich die ganze Zeit. Lokalen IP-Bereich zu ändern ist indiskutabel. Also muss ich die Quell-IP ändern. Im ersten Versuch wollte ich das über ein N:N-Mapping in unserem Netzwerk erreichen. Das habe ich leider nicht hinbekommen. Jetzt versuche ich es eben über ein zweites VPN, welches an einem anderen Standort anliegt. Doch irgendwie muss ich den Systemen -- allen voran IPfire -- beibringen, dass Pakete in ebendieses Netz über den Host 172.22.0.40 als Gateway laufen sollen.
Ansonsten... siehe Beispiel IPFireB -> wer auf Pakete eine Antwort will, muß natürlich auch die Route für den Rückweg setzen! Ich vermute mal, der weiß nicht "den Weg nach Hause" ...und probierts mit dem "Standardweg"...
Ich bin noch lange nicht soweit, dass ich mir über den Rückweg den Kopf zerbrechen müsste, die Pakete finden ja nicht mal den Hinweg. Zudem sollte es doch so sein, dass für jedes Paket der Rückweg quasi automatisch bekannt ist. Die Netze sind ja auch immer direkt (wenn man das bei VPN so sagen darf) erreichbar. Von meinem PC kann ich den 172.22.0.40 direkt erreichen. Der wiederum kann den 10.0.0.31 direkt erreichen. Wenn der 172.22.0.40 Pakete von mir maskiert und an 10.0.0.31 weiterleitet, ist die gesamte Route für den Rückweg bekannt. Soweit mein Kenntnisstand.
Ansonsten... ich habe noch NIE mit IPSec gearbeitet :-), ich hatte immer irgendwo ein NAT dazwischen (oder mehrere) bzw. Consumer-Router, die kein ESP mochten (für portforward)..usw. - aber wäre komisch, wenn IPSec keinen "benannten" Tunneleingang hat.
Wobei (definitiv bei openVPN) "erscheinen" Tunneldevices erst dann, wenn der Tunnel aktiv ist/wird.. sonst gibts die nicht.
d.h. man kann erst danach die Routen setzen (altenativ in VPN-Config reinschreiben, aber die werden auch erst nach dem Tunnelaufbau gesetzt)
IPsec hat keine devices. Das ist eben so. Zudem stehen die beiden zu benutzenden Tunnel und die Routen müssten gesetzt werden können.
ps: warum du (permanent) n-2n in ein Kundennetz machst, hat sich mir noch nicht erschlossen, statt als RW sich dort im Bedarfsfall einzuwählen. Aber manche (Chef)Wünsche muß man nicht immer verstehen ;-)
Der Bedarfsfall wäre alle 2 Minuten ;) Wir brauchen die Verbindung zum Monitoring mehrerer Systeme. Die Leitung muss also permanent stehen.

puls
Posts: 24
Joined: May 23rd, 2019, 3:01 pm
Location: Berlin

Re: Routingregel über 2 IPfire in Kundennetz -- wie?

Post by puls » May 31st, 2019, 11:29 am

Vielleicht kommen wir auf diesem Weg weiter: So wie es aussieht, scheitert die Kommunikation mit dem Kundennetzwerk immer am lokalen IPfire und dessen Unwillen, Pakete in den Tunnel zu senden. Alle anderen Komponenten laufen einwandfrei:

Beim Routing über den Host 172.22.0.40 wird dort die IP maskiert und die Pakete gehen mit dessen IP weiter auf die Reise. Verifiziert durch ein traceroute von einem anderen Host im gleichen Cluster:

Code: Select all

$ ip route list
default via 172.22.0.100 dev eth0 proto dhcp metric 100 
10.0.0.0/24 via 172.22.0.40 dev eth0 
172.22.0.0/16 dev eth0 proto kernel scope link src 172.22.3.80 metric 100 
$ traceroute -n 10.0.0.31
traceroute to 10.0.0.31 (10.0.0.31), 30 hops max, 60 byte packets
 1  172.22.0.40  0.268 ms  0.213 ms  0.202 ms
 2  172.22.0.100  0.418 ms  0.490 ms  0.345 ms
 3  10.0.0.31  14.039 ms  14.021 ms  13.989 ms
 4  10.0.0.31  14.289 ms  14.263 ms  14.220 ms
Den Beweis, dass die Pakete umgeschrieben werden erspare ich mir hier, denn Firewall und das VPN lassen nur Pakete von 172.22.0.40 durch.

Das Umschreiben des lokalen Netzes von 192.168.1.0/24 auf 192.168.116.0/24 mittels netmap Target funktioniert auf IPfire ebenfalls:

Code: Select all

# tcpdump -i any net 10.0.0.0/24
10:30:50.499442 IP 192.168.1.245.44090 > 10.0.0.31.33436: UDP, length 9
10:30:50.499512 IP 192.168.116.245.44090 > 10.0.0.31.33436: UDP, length 9
10:30:53.502500 IP 192.168.1.245.44090 > 10.0.0.31.33436: UDP, length 9
10:30:53.502601 IP 192.168.116.245.44090 > 10.0.0.31.33436: UDP, length 9
10:30:56.505687 IP 192.168.1.245.44090 > 10.0.0.31.33436: UDP, length 9
10:30:56.505750 IP 192.168.116.245.44090 > 10.0.0.31.33436: UDP, length 9
Das gleiche Umschreiben des Netzwerks auf einem anderen Host in unserem Netzwerk, welcher als Gateway dienen könnte, funktioniert genauso gut. Beim Test mit dem Gateway im anderen Netzwerk ist die netmap-regel natürlich entfernt. Die Pakete haben also die original IP wenn sie in den Tunnel Richtung 172.22.0.40 gehen sollen.

Allen drei Varianten ist gemein, dass die Pakete auf IPfire ankommen und NICHT weitergeleitet werden. Ich verstehe nicht, warum das so ist. Wenn das VPN zum Kundennetz aktiv ist und ich die Adresse umschreibe, muss IPfire doch erkennen, dass das Netz dort erreichbar ist und Pakete mit der korrekten Absenderadresse hindurch routen. Im anderen Fall muss IPfire doch nur die Pakete zum Gateway 172.22.0.40 routen, welches ebenfalls erreichbar ist. :P

Irgendeine Idee, was hier schief läuft? :(

fredym
Posts: 497
Joined: November 14th, 2016, 2:45 pm

Re: Routingregel über 2 IPfire in Kundennetz -- wie?

Post by fredym » May 31st, 2019, 1:28 pm

puls wrote:
May 31st, 2019, 8:18 am
Ich bin noch lange nicht soweit, dass ich mir über den Rückweg den Kopf zerbrechen müsste, die Pakete finden ja nicht mal den Hinweg. Zudem sollte es doch so sein, dass für jedes Paket der Rückweg quasi automatisch bekannt ist.
Ganz sicher nicht - woher auch ?
Wenn (?) du bei TCP, ICMP usw. Pakten eine Antwort erwartest, mußt der Weg bekannt sein! Routen weglassen geht nur dann, wenn sie mit Standardgate identisch sind!
So machts wohl IPFire_nr_x und du bekommst keine Antwort :-)

Logge dich dort ein und sende Pakete "nach Hause" ... traceroute läßt ja auch "freie Quell-IPs" zu!

Fred

puls
Posts: 24
Joined: May 23rd, 2019, 3:01 pm
Location: Berlin

Re: Routingregel über 2 IPfire in Kundennetz -- wie?

Post by puls » June 1st, 2019, 6:24 am

fredym wrote:
May 31st, 2019, 1:28 pm
puls wrote:
May 31st, 2019, 8:18 am
Ich bin noch lange nicht soweit, dass ich mir über den Rückweg den Kopf zerbrechen müsste, die Pakete finden ja nicht mal den Hinweg. Zudem sollte es doch so sein, dass für jedes Paket der Rückweg quasi automatisch bekannt ist.
Ganz sicher nicht - woher auch ?
Wenn (?) du bei TCP, ICMP usw. Pakten eine Antwort erwartest, mußt der Weg bekannt sein! Routen weglassen geht nur dann, wenn sie mit Standardgate identisch sind!
Moin,
wie im Satz nach dem von dir zitierten erklärt ist, sind die Wege bekannt! Der einzige Weg, der vom Kundennetz aus nicht bekannt ist, ist der Weg über den Zwischenhost in unser lokales Netz. Um den mache ich mir jedoch keine Gedanken, denn dieser Weg ist praktisch irrelevant. Solange die Verbindung von unserem Netz aus aufgebaut wird, ist die Strecke bekannt, für Hin- und Rückweg. Sie müsste nur genutzt werden.
So machts wohl IPFire_nr_x und du bekommst keine Antwort :-)
:o Sorry, aber ich bekomme vom IPfire in unserem Netz durchaus eine Antwort und auf dem IPfire an unserem zweiten Standort kommen keine Pakete an, auf die geantwortet werden könnte. Was genau meinst du also damit?

fredym
Posts: 497
Joined: November 14th, 2016, 2:45 pm

Re: Routingregel über 2 IPfire in Kundennetz -- wie?

Post by fredym » June 1st, 2019, 7:14 am

puls wrote:
June 1st, 2019, 6:24 am
...
So machts wohl IPFire_nr_x und du bekommst keine Antwort :-)
:o Sorry, aber ich bekomme vom IPfire in unserem Netz durchaus eine Antwort und auf dem IPfire an unserem zweiten Standort kommen keine Pakete an, auf die geantwortet werden könnte. Was genau meinst du also damit?
Merkwürdige Aussage: du meinst, der Weg (zu IPFire B ) sei bekannt, aber die dafür bestimmten Pakete werden (trotzdem?) nicht dahin geschickt !?

(gesetzt ist: im Firewalllog steht kein Blocking)
Bleibt die Frage:
Quell IP?
Ziel IP ?
Route ?
evtl. gibts nix zum wegschicken ?

Fred

puls
Posts: 24
Joined: May 23rd, 2019, 3:01 pm
Location: Berlin

Re: Routingregel über 2 IPfire in Kundennetz -- wie?

Post by puls » June 1st, 2019, 9:10 am

fredym wrote:
June 1st, 2019, 7:14 am
puls wrote:
June 1st, 2019, 6:24 am
...
So machts wohl IPFire_nr_x und du bekommst keine Antwort :-)
:o Sorry, aber ich bekomme vom IPfire in unserem Netz durchaus eine Antwort und auf dem IPfire an unserem zweiten Standort kommen keine Pakete an, auf die geantwortet werden könnte. Was genau meinst du also damit?
Merkwürdige Aussage: du meinst, der Weg (zu IPFire B ) sei bekannt, aber die dafür bestimmten Pakete werden (trotzdem?) nicht dahin geschickt !?
Ich dachte eigentlich, ich hätte das alles schon erklärt, aber vielleicht war es unverständlich. Daher nochmal.
(gesetzt ist: im Firewalllog steht kein Blocking)
Dort ist gar nichts zu diesen beiden IP verzeichnet.
Bleibt die Frage:
Quell IP?
192.168.1.245
Ziel IP ?
10.0.0.31
Route ?
explizite Route im IPfire WUI (IPfireA): 10.0.0.0/24 via 172.22.0.40
evtl. gibts nix zum wegschicken ?
Wenn ich ein ping oder traceroute starte, gibt es Pakete zum wegschicken.
Wenn ich den 172.22.0.40 direkt anpinge / traceroute / ssh ... kommen die Pakete dort an und sogar die Antwortpakete wieder bei mir. Jede Teilroute funktioniert, nur nicht der Weg auf IPfireA in den Tunnel hinein.

fredym
Posts: 497
Joined: November 14th, 2016, 2:45 pm

Re: Routingregel über 2 IPfire in Kundennetz -- wie?

Post by fredym » June 13th, 2019, 6:23 pm

puls wrote:
June 1st, 2019, 9:10 am
Wenn ich den 172.22.0.40 direkt anpinge / traceroute / ssh ... kommen die Pakete dort an und sogar die Antwortpakete wieder bei mir. Jede Teilroute funktioniert, nur nicht der Weg auf IPfireA in den Tunnel hinein.
Und wo geht das Paket denn dann hin ?

Fred

puls
Posts: 24
Joined: May 23rd, 2019, 3:01 pm
Location: Berlin

Re: Routingregel über 2 IPfire in Kundennetz -- wie?

Post by puls » June 14th, 2019, 5:53 am

fredym wrote:
June 13th, 2019, 6:23 pm
puls wrote:
June 1st, 2019, 9:10 am
Wenn ich den 172.22.0.40 direkt anpinge / traceroute / ssh ... kommen die Pakete dort an und sogar die Antwortpakete wieder bei mir. Jede Teilroute funktioniert, nur nicht der Weg auf IPfireA in den Tunnel hinein.
Und wo geht das Paket denn dann hin ?

Fred
In dem Fall ging es direkt auf den Uplink der Telekom, sprich ins "Internet". IPfire hat hier das Paket trotz existierender Routingregeln (explizit oder implizit) nicht in den VPN Tunnel gesendet sondern versucht, daran vorbei ins Internet zu routen.

fredym
Posts: 497
Joined: November 14th, 2016, 2:45 pm

Re: Routingregel über 2 IPfire in Kundennetz -- wie?

Post by fredym » June 14th, 2019, 6:27 am

Hallo,
da mußt du schon etwas konkreter werden ...

falsche (unvollständige) Regel(n)?

Fred

Post Reply