Schade, dass es mit strongSwan nicht geklappt hat, lag aber bestimmt an uns. Mit OpenVPN hast Du wenigstens einen Interface und eine gute Anleitung. 
Albert
[Suche] Empfehlung für Router mit Kabel Deutschland unter openWRT
-
-
Wenn ATD nicht noch eine Idee hat, dann wäre das vielleicht der Punkt das ganze hier zu schildern: https://forum.openwrt.org/
Ich weiß nicht wie exotisch StrongSwan ist, aber die Chance, da jemanden zu finden, der das ganze unter OpenWRT schon eingerichtet hat, ist sicher deutlich größer als hier.
-
Vielleicht hat ja noch jemand den entscheidenden Hinweis ;-).
Aber nur vielleicht. Versuch über /etc/firewall.user:/etc/firewall.user
Codeiptables -I INPUT -m policy --dir in --pol ipsec --proto esp -j ACCEPT iptables -I FORWARD -m policy --dir in --pol ipsec --proto esp -j ACCEPT iptables -I FORWARD -m policy --dir out --pol ipsec --proto esp -j ACCEPT iptables -I OUTPUT -m policy --dir out --pol ipsec --proto esp -j ACCEPT iptables -I FORWARD -s 88.198.76.220/32 -j ACCEPT iptables -I FORWARD -d 88.198.76.220/32 -j ACCEPT
Albert -
Allerdings brechen dann bestehende ssh-Verbindungen zum Server ab und es ist auch nicht mehr möglich, neue aufzubauen oder den Server zu pingen.
Heißt es, dass mit Deinem neuen Konfiguration das pingen funktioniert hat?Albert
-
Nein, auch 'ping' geht damit nicht. Aber zumindest ist laut Log und 'ipsec statusall' der Tunnel komplett aufgebaut.
Ja, der Tunnel steht. Wir laufen aber bei der Adresse in einem REJECT rein oder das Paket nimmt die Adresse der NAT an.Geht der Ping von dem gemieteten Server aus auf die Lokale Adresse?
Albert
-
Zeige mal eine aktuelle iptables-save > /etc/iptables/rules.v4.
Albert
-
/etc/firewall.user
Codeiptables -I INPUT -i eth0 -p udp --dport 500 -j ACCEPT iptables -I FORWARD -i eth0 -s 88.198.76.220/32 -d 192.168.1.0/24 -m policy --dir in --pol ipsec -j ACCEPT iptables -I FORWARD -o eth0 -s 192.168.1.0/24 -d 88.198.76.220/32 -m policy --dir out --pol ipsec -j ACCEPT iptables -t nat -I POSTROUTING -s 192.168.1.0/24 -o eth0 -m policy --dir out --pol ipsec --proto esp -j ACCEPT iptables -t nat -I PREROUTING -s 88.198.76.220/32 -i eth0 -m policy --dir in --pol ipsec --proto esp -j ACCEPT
iptables-save ?Albert
-
Klaus, hier noch ein Versuch.
/etc/firewall.user
Codeiptables -I INPUT -m policy --dir in --pol ipsec --proto esp -j ACCEPT iptables -I FORWARD -i eth0 -s 88.198.76.220/32 -d 192.168.1.0/24 -m policy --dir in --pol ipsec -j ACCEPT iptables -I FORWARD -o eth1 -s 192.168.1.0/24 -d 88.198.76.220/32 -m policy --dir out --pol ipsec -j ACCEPT iptables -t nat -I POSTROUTING -s 192.168.1.0/24 -o eth0 -m policy --dir out --pol ipsec --proto esp -j ACCEPT iptables -t nat -I PREROUTING -s 88.198.76.220/32 -i eth0 -m policy --dir in --pol ipsec --proto esp -j ACCEPT
iptables-save ?Bitte den Ping beidseitig versuchen.
Hilft es auch nicht, dann schließe ich mich M-Reimer (Post 144) an.
Siehst Du oder irgendwer eine Möglichkeit OpenWRT in eine VM irgendwie soweit zu bekommen, dass ich die LuCI Oberfläche nutzen könnte? Ohne LuCI kann ich die Zone/Rule Einträge in der /etc/config/firewall nicht nachvollziehen und damit ist mir der "ofizieller" Weg versperrt.
Albert
-
Siehst Du oder irgendwer eine Möglichkeit OpenWRT in eine VM irgendwie soweit zu bekommen, dass ich die LuCI Oberfläche nutzen könnte?
ich verstehe ehrlich gesagt nicht, wie man mit so Spezial-Systemen wie 'OpenWRT' ueberhaupt so viel Zeit verschwenden kann. Warum das Ganze? Nur damit es auf einer Billighardware laeuft? Das oben im Thread genannte pc-engines APU Board + eine Standard Linux Distribution -> und schon passt die reichlich vorhandene Standard-Dokumentation zu den angesprochenen Themen. -
Manchmal ist der Weg das Ziel, dass einen glücklich macht.
Gruß
iNOB -
Normalerweise ist OpenWRT unproblematisch. Klaus hat eine Konfiguration vor, die die meisten Nutzer nicht brauchen. Vielleicht gibt es an der Stelle tatsächlich einen Bug, der noch nicht aufgefallen ist. Großer Vorteil der "Fertigrouter" ist halt, neben dem Preis, der geringe Stromverbrauch. Bei einem Gerät, was 24/7 läuft ist das zumindest für mich ein wichtiges Argument.
-
Normalerweise ist OpenWRT unproblematisch.
das mag sein. Wenn man das macht was 95% der anderen Nutzer machen.
QuoteKlaus hat eine Konfiguration vor, die die meisten Nutzer nicht brauchen. Vielleicht gibt es an der Stelle tatsächlich einen Bug, der noch nicht aufgefallen ist
und das ist genau der Punkt. Warum die eigene Zeit nicht lieber in 'allgemeingueltiges' Wissen, das Quasi-Standard ist investieren? Entscheidend ist die dort vorhandene Dokumentation, die meist sehr gut ist. Wenn ich dort noch Bugs finde beteilige ich mich gerne daran einen Fix zu finden. Mir waere aber meine Zeit zu schade die hochspeziellen Bugs irgendwelcher (obendrein noch schlecht dokumentierter) Spezialdistributionen zu debuggen.
QuoteGroßer Vorteil der "Fertigrouter" ist halt, neben dem Preis, der geringe Stromverbrauch
die heutzutage erhaeltliche routerfaehige PC-Hardware braucht kaum mehr Leistung als die (teil)-vernagelten Fertigloesungen.
zudem laesst sich Standard-Hardware auch auf lange Sicht automatisch mit der Distribution deines Vertrauens updaten. Bei Spezialdistributionen ist man immer auf das Wohlwollen der Mainplayer angewiesen.
just my 2c
Participate now!
Don’t have an account yet? Register yourself now and be a part of our community!