>"...einmal am WAN-port (wobei der deaktiviert und teil des LAN-switches war) und einmal an einem der LAN-ports, hat wie erwartet keinen unterschied gemacht..."
dann solltest du dich auch ums routing auf der serverseite kümmern. schließlich kommen die getunnelten pakete mit src-ip 172.28.254.2 am ziel-pc an. wenn dieser pc nicht weiß, wo 172.28.254.2 liegt, dann nimmt er die default route. und das ist nicht der pptp-server, sondern der einwählende (modem-)router.

lg
zid

Hallo,

in dem oben angeführten fall hast Rech. Wenn er den LInksys als Gateway nehmen würde und er die ADSL-Einwahl übernehmen würde, weiters hinter dem Linksys eine andere ip als die 10.0.0.X hat und auch in den Einstellungen zum pptp Einwahlserver wie angegeben ips aus dem selben netzt nehmen würde würds gehen.
So wie die Konstellation jetzt is müßt er auch wieder an jedem Rechner den er in seinem Netz erreichen möchte ne Route über den Linksys eintragen.
Bisschen viel Aufwand halt.

lg

hallo superuser,

es ist grundsätzlich immer praktisch ein vpn am rand zu terminieren (nat). die frage ist, ob der zugang von raistlin entbündelt ist oder nicht. ist er es nicht, dann erfolgt die einwahl über pptp, und man hat auf der strecke modem <-> gl einen doppetunnel. und mit dem hatte dd-wrt (v23-sp2, v24-sp1) in der vergangenheit immer probleme (connection tracking hat nicht geklappt, und die reinkommenden gre-pakete wurden nicht entkapselt).
bei ta-anschlüssen kommt noch zusätzlich das prob mit der wiedereinwahl nach dem 8h-zwangsdisconnect dazu und bei v24-sp1 gibts noch ein (neues) prob mit den wan-addressen nach dem zwangsdisconnect.
http://xdsl.at/viewtopic.php?f=46&t=...art=15#p388173
k.a. ob diese "features" bei v24-sp2 beseitigt sind, oder raistlin hat einen entbündelten anschluß.

lg
zid

die lösung...
 

... war so einfach und doch ist es mir entgangen.

ein kollege hat mich heute beim mittagessen (das sind die besten gespräche ;) ) darauf gebracht: was gefehlt hat, war NAT zwischen dem VPN-netz (innen) und dem LAN (außen). das problem war nämlich, daß bei einer statischen route, wie ich sie eh schon hatte, um das routing zwischen 172.28.254.0 und 10.0.0.0. zu ermöglichen natürlich trotzdem die source-IP erhalten bleibt. sprich es kamen pakete vom VPN-client mit der source-IP 172.28.254.x auf einmal ins LAN. da dieses aber die adresse 10.0.0.0 hat, wurden die pakete weiter zum default gateway des LAN-netzes (10.0.0.138) geleitet, dieses hat sie, da sie nicht ins LAN gehörten nach draußen (=ins Internet) geführt, wo sie sehr schnell von der nächsten FW gedroppt wurden.

was ich also getan habe, war erstmal bei verbundenem VPN-client mit ifconfig die bezeichnung der interfaces herauszufinden. der rest war dank dieses linux NAT-guides ein kinderspiel.

dieses script

wird in administration->commands eingegeben, dann "save startup" und fortan wird es bei jedem start ausgeführt und NATtet brav zwischen VPN-netz und LAN. :)

probiert und es funzt -> i gfrei mi! :D

vielen dank an alle helfer, ich hoffe dieser thread kann all jenen, die meinen, daß sowas nicht geht genauso helfen wie mir geholfen wurde.

WOL funzt über VPN nicht
 

eine lösung ist da, doch das nächste problem steht auch schon an:

sobald ich mich mit VPN verbunden habe möchte ich per WOL eine bestimmte maschine aufwecken. im lokalen LAN funzt das bestens, nur ein VPN-client kanns komischerweise nicht.

kanns sein daß mein NAT doch nicht alles (GRE) durchlässt?
das WOL funzt nicht einmal wenn ichs über DD-WRT im router auslöse. :(

sollte nicht ein simples
am ende ausreichen (obwohl eigentlich die regel davor schon reichen sollte, immerhin wurde da kein protokoll spezifiziert)?

>"...kann all jenen, die meinen, daß sowas nicht geht genauso helfen wie mir geholfen wurde. ..."
bei diesem trauerspiel kommen mir nur noch die tränen :heul: - nat, die krücke all jener, die von routing nix verstehen, sry für die harten worte.

lg
zid

das sei zur kenntnis genommen, doch was hilfts, wenn die, "die von routing was verstehen" auch keine lösung finden? dein einwand

war richtig, doch eine statische route, die von 172.28.254.0 nach 10.0.0.0 verweist hatte ich im WRT54GL bereits eingerichtet, das hat aber nichts gebracht. warum ist auch klar, weil eben das problem mit der nicht zum LAN zugehörigen source-IP verhindert hat, daß die pakete ans LAN gingen (statt dessen gingen sie ans default gateway und dann ins Inet, wo sie gedropped wurden), wo 172.28.254.x eben unbekannt war.

die implementierte lösung mag vllt. nicht die eleganteste sein, aber sie ist trotzdem einwandfrei und funktioniert. erklär mir bitte (ernstgemeinte frage, mich interessierts), wie das ohne NAT gegangen wäre. ich lerne gerne was dazu und wenn ichs verstanden habe, probiere ichs auch gerne aus.

es geht um 2 routen.
angenommen der ppp-link hat clientseitig die ip 172.28.254.2, serverseitig 172.28.254.1 und die lan-ip des pptp-servers ist 10.0.0.1.
dann setzt du am client:
route add 10.0.0.0 mask 255.255.255.0 172.28.254.1
und am ziel-pc im lan des gl (nicht am gl selbst, der hat schon alle notwendigen routen):
route add 172.28.254.2 mask 255.255.255.255 10.0.0.1
bei linux schaut das so aus:
ip r a 10.0.0.0/24 via 172.28.254.1
ip r a 172.28.254.2/32 via 10.0.0.1

lg
zid

ok, das ist alles schon klar, nur sehr dynamisch ist das nicht. dann müßte ich ja diese routen bei jedem potentiellen client und bei jedem potentiellen ziel-pc einrichten. letzteres wäre zwar möglich, wenn auch mühsam (immerhin ist die zahl der potentiellen ziel-pcs noch überschaubar klein), ersteres ist allerdings wirklich nicht vorhersehbar. kann sein daß ich mich grad bei irgendeinem freund befinde und draufkomme, daß ich schnell was von daheim brauche - was dann, einfach eine route bei dem hinzufügen? sicher geht das, aber mal ehrlich, der aufwand einer solchen lösung, ob sauber oder nicht, steht ggn. der derzeit implementierten NAT-lösung in keinem verhältnis. immerhin ist der umstand, daß bei der NAT-lösung einzig und allein der router konfiguriert werden muß und alle clients sich dynamisch und richtig verhalten in meinen augen ggn. einer einzelkonfiguration aller möglichen clients und ziel-pcs klar zu bevorzugen, auch wenn das rein technisch gesehen vllt. die sauberere lösung wäre. das macht sie nämlich noch lange nicht automatisch gleich zur besseren (weil praktikableren) lösung.

PS: sollte das nicht
heißen, damit der ziel-PC mit allen VPN-clients kommunizieren kann?
und wieso meinst du, daß der gl schon alle notwendigen routen hat? die bloße existenz eines zusätzlichen interfaces (das des VPN-servers nämlich auf 172.28.254.1) heißt doch noch nicht, daß zwischen dem und dem auf 10.0.0.1 (in deinem bsp, bei mir ists .35) geroutet wird? da wird doch auch eine eigene route definiert werden müssen, oder?

>"...ok, das ist alles schon klar,..."
na, wenns so klar ist, warum tust du dann so lange rum? ist normalerweise eine sache von 5 min (egal welche variante du nimmst).

>"...dann müßte ich ja diese routen bei jedem potentiellen client..."
nicht "müßte". man *muß* auf der clientseite *immer* eine entsprechende route legen, egal was du auf der serverseite machst. sonst hast geht nix über den tunnel. ok, man kann auch leere tunnels hinstellen... hm, scheint doch nicht so klar zu sein.

>"...letzteres wäre zwar möglich, wenn auch mühsam..."
ok, ich hab jetzt an ein durchschnittliches heimnetzwerk mit höchstnens 20 rechnern gedacht. wußte nicht, daß bei dir da bei ein paar hundert rechner am werken sind. ach ja, in diesem fall kannst den gl sowieso vergessen, eh klar oder?

>"...sollte das nicht
...
route add 172.28.254.0 mask 255.255.255.255 10.0.0.1..."
nein. ich hab 'ne host route gesetzt. wenn mehr ips hast, mußt halt ein entsprechendes netz nehmen.

>"...und wieso meinst du, daß der gl schon alle notwendigen routen hat?..."
ich "meine" nicht, ich schau einfach nach- kannst du übrigens auch tun.
root@DD-WRT:~# ip r
172.28.254.2 dev ppp0 proto kernel scope link src 172.28.254.1
10.0.0.0/24 dev br0 proto kernel scope link src 10.0.0.1
169.254.0.0/16 dev br0 proto kernel scope link src 169.254.255.1
127.0.0.0/8 dev lo scope link
default via 10.0.0.139 dev br0
damit sollte alles klar sein.

deine bemerkungen zu wol hab ich übersehen.
>"...sobald ich mich mit VPN verbunden habe möchte ich per WOL eine bestimmte maschine aufwecken..."
mit pptp wird das net so einfach gehen, zur abwechslung wieder ein routing prob.

>"...das WOL funzt nicht einmal wenn ichs über DD-WRT im router auslöse..."
hm, möglicherweise ein bug. bei der v24-sp1 mini funkt das zeugs. ich tunnle mich zum gl und nehm den wol-proxy des gls.
was machst du genau?
falls alle stricke leisten, mußt halt wol übers inet ohne tunnel machen. s. z.b. hier beim st/tg:
http://www.dieschmids.at/Speedtouch-...-Internet.html

lg
zid