|
PPTP VPN mit DD-WRT: Kein Routing zwischen lokalem IP-Range und VPN IP-Range
Ich habe auf meinem Linksys WRT54GL DD-WRT raufgespielt um mir damit einen PPTP VPN-Server aufzusetzen.
An und für sich keine große Sache, die Verbindung von Clients klappt auch (getestet mit Yesss), nur scheint kein Routing zwischen dem IP-Range, den ich für die VPN-Clients vergeben habe und dem meines lokalen Netzwerks stattzufinden. Dies sind meine Einstellungen in DD-WRT bei Services->VPN->PPTP Server: PPTP Server: Enable Broadcast support: Enable Force MPPE Encryption: Enable Server IP: 10.0.0.135, dies ist die IP, die der Linksys in meinem lokalen Netzwerk (10.0.0.0) hat. Client IP(s): 172.28.254.1-20 (halt irgendwas exotisches, damit es hoffentlich keine Probleme mit dem Fremdnetz gibt) CHAP-Secrets: Hier ist ein User angegeben, mit dem ich mich auch erfolgreich anmelden kann. Radius: Disable Der Client ist der von WinXP Pro, das Hakerl bei "Use default gateway on remote network" habe ich entfernt. Ich bin eigentlich davon ausgegangen daß bei der Angabe des VPN IP-Ranges ein Routing zwischen diesem und dem Heimnetzwerk stattfindet. Dies dürfte allerdings nicht der Fall sein. Ich habe mal testhalber für die VPN-Clients einen IP-Range aus dem lokalen Netzwerk angegeben (10.0.0.100-110), wenn ich mich dann verbinde klappt alles. Es dürfte also wie gesagt ein Routingproblem sein. Unter Setup-Advanced Routing gibt es den Punkt "Operating Mode", wo ich gerne auf "Router" umstellen würde (soll man auch in meinem Fall, da der Linksys ja nicht für die Internetverbindung nach draußen verantwortlich ist). Nur sobald ich irgendwas auf der Seite ändere öffnet sich eine komplett leere Seite im Browser namens apply.cgi - mehr tut sich nicht. Wenn ich dann zurück gehe sehe ich, daß keine Einstellungen übernommen wurden. Ist das ein Bug in der Firmware (DD-WRT v24-sp2)? Gibts eine Möglichkeit, wie ich den Operating Mode sonst wie umstellen kann? |
ich denke mich zu erinnern, dass schon so mancher probleme mit yesss-vpns hatte...
vlt liegst einfach an yesss? (reine vermutung) |
Zitat:
Trotzdem funzt das Routing noch nicht. :( Another: Glaube ich nicht. Wenn ich für die Clients einen IP-Range aus meinem lokalen Netzwerk angebe gehts ja wunderbar. Nur da findet eben kein Routing statt, was ich aber gerne hätte, da mein lokales Netz 10.0.0.0 verwendet - so wie viele andere eben auch (was dann ein Problem wäre, sobald ich mich in so einem Netz nach Hause verbinden will). Ein Problem ist halt auch noch, daß ich nicht weiß, was ich bei Server IP bei den VPN-Einstellungen eingeben soll. Die tatsächliche IP, die der Linksys in meinem Heimnetzwerk hat (also 10.0.0.135) oder eine aus dem VPN-Range? Ich habe dazu z.B. diese Anleitung gefunden, die sich nur leider in dem Punkt selbst widerspricht. Einerseits sagt sie, daß die VPN-Adressen einen eigenen Range verwenden sollen (was eh klar ist, damits keine Konflikte gibt), andererseits soll bei der Server-IP die IP-Adresse aus dem lokalen Netzwerk angegeben werden - welche aber laut Korrektur des eh schon falschen Screenshot aus demselben Range ist wie die der VPN-Clients! Ich vermute daß auch die Korrektur falsch ist und der Range tatsächlich 192.168.10.1-20 sein soll. Habe jetzt jedenfalls als Server IP 10.0.0.135 eingetragen. Interessanterweise lässt sich diese IP auch über einen VPN-Client mit einer 172er-Adresse pingen. Allerdings nur diese eine, keine andere aus 10.0.0.0. |
Weiß dein Client, dass er das Netzwerk 10.0.0.x auf der anderen Seite des VPN Netzwerkes findet?
Beispiel: local network: 10.0.0.n/24 Server: 10.0.0.135 Auf dem Server wird ein Netzwerkdevice angelegt, welches ebenfalls eine IP bekommen kann. Beispiel: Network: 10.0.0.135/24 VPN: 10.0.0.135/16 Durch das Setzen der Netmask 255.255.0.0 werden alle anderen 10.0.x.n Netzwerke über das VPN gesucht. Durch diese Einstellung würde der Client ebenfalls den Adressbereich 10.0.x.n für die VPN Verbindung bekommen und alle Adressen in diesen Bereich dort suchen. Wenn du allerdings eine Adresse aus dem Bereich: 172.16.0.0 – 172.31.255.255 für das VPN verwenden willst, muss der Client seine Routing table ebenfalls so anpassen, dass er weiß, dass ein 10.0.0.n Netzwerk auf dem anderen Ende der VPN zu finden ist. Einfach zu testen, ob dass wirklich das Problem ist, ist indem man beim VPN Client einstellt, dass der gesamte netzwerktraffic über die VPN Verbindung geschickt wird. However, wenn die Adressen im "VPN" Server Netzwerk gleich sind, wie die des "lokalen" Netzwerkes des Clients wirst du immer Probleme haben. Die Einstellung, welche ich empfehlen würde: Serverbereich festlegen ... z.B.: 10.0.0.1 - 10.0.0.16 Drüber den VPN Bereich ... z.B.: 10.0.0.17 - 10.0.0.32 Dann den DHCP beginnend bei ... 10.0.0.33 |
Zitat:
Zitat:
wenn ich diese einstellung aktiviert lasse bekomme ich als default gateway aber genau die IP zugewiesen, die ich dem VPN-server im VPN-range zugewiesen habe. und das sollte ja eigentlich auch passen, denn so wie ich das verstehe befindet sich ja an dieser adresse das VPN-interface des routers, der nun in das heimnetz 10.0.0.0 routen soll (und es offenbar nicht tut, sonst hätte ich ja das problem nicht). oder hab ich da was nicht verstanden? als subnet mask bekomme ich dabei komischerweise 255.255.255.255, wieso ist das so? damit wird ja nur der eine client angesprochen, ist aber dann nicht teil eines netzwerks, oder? Zitat:
|
Der Router kann nur Verbindungen Routen, die er auch erhält.
In Wirklichkeit hat jeder Computer eine Routing-Table in welcher drinnen steht, welches Netzwerk er über welches Gerät (WLAN, LAN, VPN, etc.) erreicht. Alle nicht "direkt" erreichbaren Adressen werden über den default Gateway geschickt, welcher dann wissen muss wohin er das Packet routet. Soweit ich pptp vpns beobachten konnte, nimmt der Computer an, dass es sich um ein 255.255.255.0 Netzwerk handelt, obwohl er 255.255.255.255 hinschreibt ... warum weiß ich nicht. Als Gateway muss er die Adresse des PPTP Interfaces hinschreiben. Wie siehts mit der iptalbes Konfiguration aus? Kann es sein, dass dort die aufgebauten pptp Verbindungen noch blockiert werden. Habe bei meinen folgende Seite verwendet (war aber white russian) http://nuwiki.openwrt.org/oldwiki/PPTPDHowto Such dir einen Adressbereich aus ... das Problem, dass ein Hotel den gleichen Adressbereich verwenden könnte hast du in jeden Bereich. Ich gebe zu, dass die gebräuchlichsten meines Wissens: 10.0.0.n, 10.127.n.n, 192.168.0.n, 192.168.1.n sind. |
Zitat:
ich will mal schildern, was ich vor hatte: bei mir daheim und bei meinen eltern läuft jeweils derselbe telekom-router mit einer IP 10.0.0.138. diese ist unabänderlich (ich habs mal probiert, daraufhin mußte ich den router resetten), ein manko der firmware und aktuellere gibts leider keine, daher muß man damit wohl leben. nun möchte ich beizeiten von meinen eltern per VPN auf mein heimnetzwerk zugreifen. problem ist, daß sobald die verbindung steht, ich zwar von daheim eine 10.0.0.x-adresse bekomme, diese aber gleichzeitig aus dem bereich des netzwerks meiner eltern ist. um dieser bekannten problematik zu entkommen dachte ich mir, daß ich für die VPN-verbindung einfach ein anderes netz wähle (möglichst exotisch), damit eben sowas nicht passiert. der router sollte, so wie ich die arbeitsweise eines routers verstanden habe, in der lage sein, zwischen 2 interfaces in unterschiedlichen netzen routen können, immerhin macht das ja die aufgabe eines routers aus. und genau das hat eben nicht funktioniert. du meinst also daß ich da grundsätzlich falsch gedacht habe und der VPN-adressbereich sowieso aus demselben netz wie das heimnetzwerk sein MUSS? aber was, wenn ich im router eine entsprechende regel hätte, die besagt, das traffic vom einen netz ins andere netz durchgelassen werden soll? |
Hallo
könntest ja mal posten was bei offenem vpn route print so ausspuckt lg |
Zitat:
|
Hallo,
yep vom clien bidde vor und nach öffnen des vpn route print lg |
vor verbindung zu VPN-server:
ipconfig: Code:
PPP-Adapter Yesss:Code:
===========================================================================als server-IP wurde beim VPN-server in DD-WRT 172.28.254.1 angegeben, die clients bekommen 172.28.254.2-10 ipconfig: Code:
PPP-Adapter Yesss:Code:
=========================================================================== |
Hallo
nana so is es ja nicht der client muß mal wissen wenn er in ein anders netz will ob er über den standardgateway fahren soll oder ob er ne andere route nehmen soll mehr sagt dir dann route add, mit -p wirds ne permanente route ohne -p is die route nach neustart wieder weg. wenn man dem client net sagt das er, wenn man ins 10.0.0.x netz will, über die 172.... fahren soll macht er alles über den standardgateway dein client kennt nur das 172 iger netz und das 10.116 irgendwas netz, alles andere versucht er über den standardgateway zu erreichen, d.h wenn du ins 10.0.0. er netz wills versucht er natürlich über den standardgateway zu fahren und damit ists sense, er weiß ja net das sich dass 10.0.0 er netz hinter dem 172..... netz befindet. Bei openvpn und ipcop (zerina) werden die routen eben beim start des vpn-clients angepasst. lg |
Zitat:
in diesem zusammenhang verstehe ich auch nicht, warum für den VPN-adapter dann kein standardgateway angegeben ist (siehe voriger post mit ausgabe von ipconfig nach verbindung mit VPN-server). weil wenn klar ist, daß der VPN-server das standardgateway ist, dann sollte auch die angabe einer eigenen route hinfällig sein, weil dort eben geroutet werden sollte. richtig? |
hallo,
zum letzen Punkt: richtig dein route print sagt was anderes also: er kennt 172 er netz er kennt 10.irgendwas netz. all das das er net kennt schickt er über 10.116.22.40 raus und d.h direkt ins inet versuch mal mit route add von deiner 172 iger ipadresse und als getaway die ip des routers der die pptp einwahlt macht ins 10. er netz also route add 10. irgendwas MSK 255 irgendwas Gateway (ip des einwahlrouters also 172 irgendwas nehm ich an) Schnitstelle (172 irgendwas also über die er rausfahren soll route add 10.0.0..X MASK 255.255.255.0 172.28.254.X 172.28.254.2 wennst links und rechts die identen netze hast brennt der hut lg |
Ich
mach für dich mal nen ausdruck von route print vor und nach öffnen des openvpn vorher IPv4-Routentabelle ================================================== ========================= Schnittstellenliste 0x1 ........................... MS TCP Loopback interface 0x2 ...00 0c 29 0c 30 41 ...... Ethernet-Adapter der AMD-PCNET-Familie - Determi nistic Network Enhancer Miniport 0x20003 ...00 ff 1e e2 e6 2d ...... TAP-Win32 Adapter V8 - Deterministic Network Enhancer Miniport ================================================== ========================= ================================================== ========================= Aktive Routen: Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik 0.0.0.0 0.0.0.0 192.168.11.1 192.168.11.3 10 10.58.60.4 255.255.255.252 10.58.60.6 10.58.60.6 30 10.58.60.6 255.255.255.255 127.0.0.1 127.0.0.1 30 10.255.255.255 255.255.255.255 10.58.60.6 10.58.60.6 30 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 169.254.0.0 255.255.0.0 192.168.11.3 192.168.11.3 20 192.168.11.0 255.255.255.0 192.168.11.3 192.168.11.3 10 192.168.11.3 255.255.255.255 127.0.0.1 127.0.0.1 10 192.168.11.255 255.255.255.255 192.168.11.3 192.168.11.3 10 224.0.0.0 240.0.0.0 10.58.60.6 10.58.60.6 30 224.0.0.0 240.0.0.0 192.168.11.3 192.168.11.3 10 255.255.255.255 255.255.255.255 10.58.60.6 10.58.60.6 1 255.255.255.255 255.255.255.255 192.168.11.3 192.168.11.3 1 Standardgateway: 192.168.11.1 ================================================== ========================= Ständige Routen: Keine nach öffnen des vpn IPv4-Routentabelle ================================================== ========================= Schnittstellenliste 0x1 ........................... MS TCP Loopback interface 0x2 ...00 0c 29 0c 30 41 ...... Ethernet-Adapter der AMD-PCNET-Familie - Determi nistic Network Enhancer Miniport 0x20003 ...00 ff 1e e2 e6 2d ...... TAP-Win32 Adapter V8 - Deterministic Network Enhancer Miniport ================================================== ========================= ================================================== ========================= Aktive Routen: Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik 0.0.0.0 128.0.0.0 10.58.60.5 10.58.60.6 1 0.0.0.0 0.0.0.0 192.168.11.1 192.168.11.3 10 10.58.60.1 255.255.255.255 10.58.60.5 10.58.60.6 1 10.58.60.4 255.255.255.252 10.58.60.6 10.58.60.6 30 10.58.60.6 255.255.255.255 127.0.0.1 127.0.0.1 30 10.255.255.255 255.255.255.255 10.58.60.6 10.58.60.6 30 86.x.x.x 255.x.x.x 192.168.11.1 192.168.11.3 1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 128.0.0.0 128.0.0.0 10.58.60.5 10.58.60.6 1 132.147.160.0 255.255.255.0 10.58.60.5 10.58.60.6 1 169.254.0.0 255.255.0.0 192.168.11.3 192.168.11.3 20 192.168.1.0 255.255.255.0 10.58.60.5 10.58.60.6 1 192.168.11.0 255.255.255.0 192.168.11.3 192.168.11.3 10 192.168.11.3 255.255.255.255 127.0.0.1 127.0.0.1 10 192.168.11.255 255.255.255.255 192.168.11.3 192.168.11.3 10 224.0.0.0 240.0.0.0 10.58.60.6 10.58.60.6 30 224.0.0.0 240.0.0.0 192.168.11.3 192.168.11.3 10 255.255.255.255 255.255.255.255 10.58.60.6 10.58.60.6 1 255.255.255.255 255.255.255.255 192.168.11.3 192.168.11.3 1 Standardgateway: 10.58.60.5 ================================================== ========================= Ständige Routen: Keine |
ok, ich hab jetzt mal dem client adresse des VPN serverinterfaces als default gateway gegeben. das funktionierte über den befehl
Code:
route add 0.0.0.0 mask 0.0.0.0 172.28.254.1 if <ka mehr wie die interfacebezeichnung war>nun mußte ich eigentlich nur mehr im router selbst eine route erstellen, die von 172.28.254.0 auf 10.0.0.0 routete. dazu kam ich aber gar nicht erst, denn komischerweise ließ sich vom VPN-client aus die IP des neuen default gateway nicht einmal pingen (davor ging das schon, damals war als default gateway dieselbe IP angegeben wie der VPN-client selbst hatte). wie gibts das? hängt das mit der subnet mask (255.255.255.255) zusammen? kann es sein, daß die bei VPN-verbindungen immer so ist (man kann nämlich, wenn man eine statische IP für das interface vergeben will, nur eine IP angeben, keine subnet mask)? |
Frage, wie sieht bei dir die verbindung zw. adsl modem und Linksys aus?
wo ist das adsl modem am router angesteckt weiters vermute ich, nachdem ich mir die Anleitung in deinem Link durchgelesn hab das das so net funktioniert wie du dir das vorstellst. Ach ja wenn du als netmask 255.255.255.255 hast steht dir nur 1 IP zur Verfügung. du hast ja als server 172.28.254.1 angegeben. Konntest du den vorher pingen? lg |
Zitat:
Zitat:
Zitat:
Zitat:
|
Also wenns vorher funktioniert hat und du die 172.28.254.1 pingen konntest stell diesen zustand wieder her, du hatest da die IP 172.28.254.2
dann route add 10.0.0.0 Mask 255.255.255.0 172.28.254.1 172.28.254.2 ich vermute wenn du das adsl modem im sigeluserbetrieb betreiben würdest den linksys die einwahl und dann dahinter ne 192 irgenwas und anschließend alles laut der Anleitung wärs wesentlich einfacher. Du wirst meiner meinug sowieso ein problem haben wenn du links und rechts quasi ein adsl netz mit ner 10.x.x.x ip hast. lg |
Zitat:
Zitat:
danke jedenfalls für die hilfe! |
>"...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 Code:
echo 1 > /proc/sys/net/ipv4/ip_forwardprobiert 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 Code:
iptables -p 47 -A FORWARD -i ppp0 -o br0 -j ACCEPT |
>"...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 |
Zitat:
Zitat:
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 |
Zitat:
PS: sollte das nicht Zitat:
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 |
| Alle Zeitangaben in WEZ +2. Es ist jetzt 21:13 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
© 2009 FSL Verlag