Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 12 replies
  • Subscribers 1 subscriber
  • Views 8006 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Remote desktop over VPN

ramanujan
Hello  [:)]

I've got some really strange effects with my remote desktop connections. I created a net to net VPN (astaro on both sides, preshared keys, masquerading on both astaros) The connection works (telnet, ping, ...) When i try to open a remote connection (Win XP) from my home location to my office (XP too) i only get a black screen and a timeout. The event log on my office computer tells me "The RDP protocol component X.224 detected an error in the protocol stream and has disconnected the client."
When i try to connect from my office to my laptop at home, I get the login screen, i can log in, i can see the desktop of my laptop, but mouse and keyboard are not functioning.
Ports are open (especially port 3389 for RDP) names can be resolved. So, any idea what i can do?

Greetings Jens    


This thread was automatically locked due to age.
Parents
  • 0
    Packet filter is no Problem. I have all necessary rules. Telnet access to the RDP port is possible in both directions. The problem must be somwhere else. 
    For me it seems that my Office network doesn't see my private net 192.168.9.0 as source of traffic but my dynamic firewall ip instead. That would explain the protocol error in the RDP and the fact that i can't log into my office astaro from home.
    Is it possible to check the source address somehow? Ping only tests for destination, so where can i see source addresses?

    Greetings Jens  
  • 0 in reply to ramanujan
    Since you are using WinXP, have you been using tools such as
    ROUTE PRINT
    TRACERT
    PATHPING
    in a DOS box to help debug the connectivity issues?

    The bottom of a ROUTE PRINT output shows you where your default route is pointing.

    On a machine (WinXP or Win2K3) with a dynamic, DHCP issued address, the default path should switch into the tunnel when it connects. On machines with statically assigned addresses, the default path will stay with the static address, and you then need a ROUTE ADD statement to define a route into the VPN tunnel.     
Reply
  • 0 in reply to ramanujan
    Since you are using WinXP, have you been using tools such as
    ROUTE PRINT
    TRACERT
    PATHPING
    in a DOS box to help debug the connectivity issues?

    The bottom of a ROUTE PRINT output shows you where your default route is pointing.

    On a machine (WinXP or Win2K3) with a dynamic, DHCP issued address, the default path should switch into the tunnel when it connects. On machines with statically assigned addresses, the default path will stay with the static address, and you then need a ROUTE ADD statement to define a route into the VPN tunnel.     
Children
  • 0 in reply to VelvetFog
    Perhaps are not the rules itself the problem but rather their sequence ? I think you have more than these two rules configured in your packet filter, perhaps you should reorganize their sequence...sometimes some packets (services) will be already  processed in a earlier rule from the packet filter.
         
  • 0 in reply to Sascha_Paris
    Ah, i forgot...if you cannot connect through a IPSEC VPN to your remote ASL, then you maybe restricted in the affected ASL's "web admin settings" the allowed networks from "any" to the ASL's local subnet....  
Cookie Information Banner