IPfire und statische Routen

[Steggi]

Moinsen,

Folgendes Szenario: Es gibt zwei Standorte, einen Hauptstandort und eine Zweigstelle, die über über ein Site to Site VPN (RAS über Server 2008 R2) miteinander verbunden sind. Das VPN an sich steht, aber es funktioniert bis jetzt nur in eine Richtung (Ping von Haupt zu Zweig) aber nicht umgekehrt.

In der Hauptstelle ist der Internetrouter ein IPfire, in der Zweigstelle eine Fritzbox. In beiden Routern ist eine statische Route ins jeweilige Zielnetz eingerichtet, dessen Gateway die IP des jeweiligen RAS Servers ist.

Folglich ist der Paketablauf von Haupt zu Zweig:

Client Haupt (Ping) --> IPfire --> VPN Haupt --> Tunnel --> VPN Zweig --> Client Zweig
Client Zweig (antwortet) --> Fritzbox --> VPN Zweig --> Tunnel --> VPN Haupt --> Client Haupt

Das ganze funktioniert in diese Richtung problemlos.

In die andere Richtung aber nicht:

Client Zweig (Ping) --> Fritzbox --> VPN Zweig --> Tunnel --> VPN Haupt --> Client Haupt (Ping kommt an)
Client Haupt (antwortet) --> IPfire -XXX-> VPN Haupt --> Tunnel --> VPN Zweig --> Client Zweig

Laut Sniffer kommt der Ping beim Client in der Hauptstelle an, dieser antwortet auch, allerdings kommt der Ping am VPN Server in der Hauptstelle schon nicht mehr an. Entsprechend scheint das Problem beim IPfire zu liegen, nur wo...

Bei den Clients ist jeweils der IPfire bzw die Fritzbox als Gateway eingetragen und diese sollten den Traffic dann an die VPN Server weiterleiten. Warum der IPfire das bei der Ping-Antwort des Haupt Clients nicht macht, wohl aber wenn dieser Client selber pingt ist mir ein Rätsel.

Wenn man bei dem Haupt Client direkt den VPN Server als Gateway setzt oder anstatt des IPfire temporär eine Fritzbox da hin stellt und auf ihr die statische Route einträgt funktioniert alles

Der IPfire ist die aktuellste Version und ich habe die statische Route sowohl über die GUI als auch mit

route add -net 192.168.60.0 netmask 255.255.255.0 gw 192.168.50.120 green0

in der /etc/sysconfig/firewall.local eingetragen, hat aber beides nichts gebracht.

Vielleicht hat ja einer von euch noch ne Idee...

 

[ms007]

Hinweis

Thread bei forum.ipfire.org zu dem Thema.

Das scheint auch mit der 2.11 core62 noch zu klemmen, ich habe aktuell das gleiche Problem.

 

[FLiNTx]

Öhm...

Verständnisfrage:
Ping von der Haupstelle zur Zweigstelle geht (Sprich du bekommst Antwort)
Ping von der Zweigstelle zur Hauptstelle geht nicht

Folglich ist das Routing ja i.O. - Hin- und Rückweg funktionieren ja...

Ich frag einfach mal blöd: Droppt seine IPFire vll. das Echo reply???

 

[Steggi]

@ms007

Also im Test war die Route sowohl über die GUI als auch über die /etc/sysconfig/firewall.local sofort da und auch aktiv. Ohne die ist nämlich kein Ping zwischen Haupt und Zweigstelle möglich gewesen, da die Pakete ja sonst gar nicht ihren Weg zum VPN Gateway der Hauptstellen finden würden.

Verständnisfrage:
Ping von der Haupstelle zur Zweigstelle geht (Sprich du bekommst Antwort)

Jup

Ping von der Zweigstelle zur Hauptstelle geht nicht

Genau. Es sei denn, man stellt anstelle des IPfire direkt das VPN Gateway der Hauptstelle als default Gateway ein, was eigentlich nicht das Ziel sein soll.

Folglich ist das Routing ja i.O. - Hin- und Rückweg funktionieren ja...

Ja, die Pakete gehen aber nur auf dem Hinweg über den IPfire, die Antwort aus der Zweigstelle kommt ja direkt über das VPN Gateway ins Netz der Hauptstelle, wenn mich jetzt nicht alles täuscht.

Ich frag einfach mal blöd: Droppt seine IPFire vll. das Echo reply???

Der scheint ja nicht nur die echo reply's zu verwerfen, sondern direkt alles (warum auch immer) was über ihn zurück geht.

Edit: Jep, der verwirft die Pakete

Ping von Zweig zu Haupt:

17:12:00 DROP_OUTPUT green0 ICMP 192.168.50.200
192.168.60.252 ICMP
ICMP :::::

192.168.60.252 --> Zweigstelle
192.168.50.200 --> Hauptstelle

 

[Steggi]

Moinsen,

hab das Problem inzwischen selber lösen können, wenn auch mit ein wenig Handarbeit in der Config

Fur die jenigen, die selber vor dem Problem stehen, hier die Lösung:

Man füge in die /etc/sysconfig/firewall.local folgende Zeilen im "Start-Bereich" hinzu,

/sbin/iptables -A CUSTOMFORWARD -i green0 -o green0 -j ACCEPT
/sbin/iptables -I NEWNOTSYN -i green0 -o green0 -j ACCEPT

startet die Kiste neu und siehe da, alles funzt so wie es soll