Ankündigung

Einklappen
Keine Ankündigung bisher.

Wiregate und VPN

Einklappen
Dieses Thema ist geschlossen.
X
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    #16
    Da nun zum Ziel zu kommen bedarf entweder ein bisschen Eigeninitiave oder ansonsten sind wir für Sonderlocken auch käuflich
    Früher wäre das für mich keine Frage gewesen, da hätte ich das auf meinem Linux Server selbst eingerichtet. Inzwischen hab ich zwar immer noch Spaß an solchen Sachen, leider fehlt mir aber die Zeit. Genau deswegen hab ich ja auch ein Wiregate gekauft und mich nicht selbst damit beschäftigt ;-) - war die richtige Entscheidung.

    Gerade IPSec ist ja nicht wirklich trivial, hab mir das vor ein paar Jahren mal angeschaut. Daher wäre mir die Variante "Kiste kaufen und glücklich sein", selbst wenn es ein paar EUR werden, eigentlich am liebsten. OK, vierstellig sollte es dann auch nicht unbedingt werden.

    Wenn ich da nichts finden sollte, komme ich aber ggf. auf das Angebot zurück! Selbst möchte ich mich an einen sicherheitsrelevanten Bereich nicht mal so eben nebenher heranbegeben...

    Kommentar


      #17
      Zitat von Jockel Beitrag anzeigen
      Selbst möchte ich mich an einen sicherheitsrelevanten Bereich nicht mal so eben nebenher heranbegeben...
      Das ist sicherlich eine sehr weise Einsicht, die ich allerdings keinem aufzwängen möchte Jeder könnte und soll dürfen..

      Mit Verlaub, VPNs, insb. IPSec sind halt seit rund 11J unser Kerngeschäft, verglichen damit habe ich von GA/HA bis heute "garkeine Ahnung".
      Das miit dem lieben IPSec ist sicher nicht trivial, es kann sich jeder mit einem WireGate oder einem beliebigen Linux aber "machen". Risiken und Nebenwirkungen gibts natürlich, diese oder die Anleitung dazu lassen sich aber nicht mit 50 Zeilen beschreiben.

      Daher ist OpenVPN (prinzipiell sehr viel einfacher im Handling als IPSec) in "schön" drin und der Rest, naja, IPSec ist bestimmt das "richtigste" aber eben auch der worst-case was die Komplexität angeht (zumindest wenn man es richtig macht, so mit CA usw.)

      Makki
      EIB/KNX & WireGate & HS3, Russound,mpd,vdr,DM8000, DALI, DMX
      -> Bitte KEINE PNs!

      Kommentar


        #18
        VPN server not reachable

        Hi,

        I'm re-using this thread to report a Wiregate VPN issue.

        After configuring the VPN server I managed to get the VPN connection established however the client is not able to ping VPN server nor any other device connected in the LAN.

        All configurations are left default, except following changes:
        - VPN connection over TCP iso UDP
        - added following optional line to server cfg push "route 192.168.1.0 255.255.255.0"

        In the client log I see that server reports successful tunnel establishment, however in the last part it seems to go wrong:
        Thu Sep 09 21:21:23 2010 [server] Peer Connection Initiated with 91.182.109.120:1194
        Thu Sep 09 21:21:24 2010 Options error: Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:2: topology (2.0.9)
        Thu Sep 09 21:21:24 2010 TAP-WIN32 device [Local Area Connection 7] opened: \\.\Global\{23EB17D4-2F7B-4727-8616-01B8656838F3}.tap
        Thu Sep 09 21:21:24 2010 TAP-Win32 MTU=1500
        Thu Sep 09 21:21:24 2010 Notified TAP-Win32 driver to set a DHCP IP/netmask of 172.24.254.6/255.255.255.252 on interface {23EB17D4-2F7B-4727-8616-01B8656838F3} [DHCP-serv: 172.24.254.5, lease-time: 31536000]
        Thu Sep 09 21:21:24 2010 Successful ARP Flush on interface [4] {23EB17D4-2F7B-4727-8616-01B8656838F3}
        Thu Sep 09 21:21:24 2010 Initialization Sequence Completed
        Thu Sep 09 21:50:01 2010 TCP/UDP: Closing socket
        Thu Sep 09 21:50:01 2010 ROUTE: route deletion failed using DeleteIpForwardEntry: The parameter is incorrect.
        Thu Sep 09 21:50:01 2010 Closing TUN/TAP interface
        Thu Sep 09 21:50:01 2010 SIGTERM[hard,] received, process exiting

        -> could there be something wrong with the push command and consequently the route creation at client side?
        Or is the route on the LAN router insufficient/wrong?

        Note that the OpenVPN FAQ refers to a possible old client version incompatibility with newer servers supporting the --topology option -> could this be the case here?
        The client has been installed right from the Wiregate VPN configuration page, I've consequently got an old v1.0.3.

        Some more background:
        - LAN router: 192.168.1.1
        - VPN server LAN IP@: 192.168.1.6
        - client IP@ range: 172.24.254.0
        - VPN client IP@: 172.24.254.6
        - static route added on LAN router with destination 172.24.254.0 mask 255.255.255.0 gtw 192.168.1.6

        Any idea what could be wrong?

        Thanks for your help, Sammy

        Kommentar


          #19
          Hmm, honestly, I never tried with TCP (usually you really want to use UDP here, theres no benefit from TCP here as openvpn handles everything on upper layers!)

          Remainder looks fine, I attached a screenshot on how the push route should look like. Otherwise it might really make sense to give the client from openvpn.net a try.

          Makki
          Angehängte Dateien
          EIB/KNX & WireGate & HS3, Russound,mpd,vdr,DM8000, DALI, DMX
          -> Bitte KEINE PNs!

          Kommentar


            #20
            Any news on this?
            If it still doesn't work yet please post the complete config and I'll try to reproduce..

            Makki
            EIB/KNX & WireGate & HS3, Russound,mpd,vdr,DM8000, DALI, DMX
            -> Bitte KEINE PNs!

            Kommentar


              #21
              Quick status update as I got some progress in the mean time:
              - tunnel over TCP functioning well
              - pushing routes towards client works however after 10 seconds they disappear from the Windows routing table. This caused the ping to both server IP pool as well as local LAN to fail.
              - for the moment I implemented a workaround: added a batch file configuring these routes again 20s later.
              - still need to look for the actual trigger such that workaround can be removed.

              In fact I do suspect the Firewall agent on my portable as this also blocked the UDP port, which made me decide to move to TCP (not being able to tune the firewall config).

              Best regards, Sammy

              Kommentar

              Lädt...
              X