Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 12 replies
  • Subscribers 1 subscriber
  • Views 8005 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.
  • 0
    You say you are masquerading on both Astaros. Are you masquerading the regular connections, or the VPN circuits? Two NATs against each other will cause problems.

    You describe a two Astaro VPN setup that I would want to duplicate at some point. I also use Remote Desktop into my WinXPpro machine, but so far it has just been over PPTP tunnels going client to ASL, and then running the remote desktop inside the tunnel. I have not had any problems with it. I'm on such a connection right now.  
  • 0
    My Home-Astaro is connected to the internet via DSL (dynamic ip) Masquerading is activated.
    I have the feeling that my office can't see my internal ip's but sees my dynamic firewall ip. Is that possible? Can i check that somehow?  
  • 0 in reply to ramanujan
    Your External dynamic IP address can be seen by anyone, having a VPN connection doesn't matter one way or the other.

    The simplest tool to use to see what machines are available, is to use ping from a DOS box on your PC.

    I take it you are masquerading your Internal network behind your External interface. Something like this:

    Local-NAT Internal_Network__ -> All / All  MASQ__External None

    All that does, is allowing machines on your Internal network to share an Internet connection. It does not address your VPN routing issues.

    How are you routing your VPN traffic at each end?
    What packet filtering rules do you have? 

    If you want the folks on this BBS to help you solve your connectivity problem, you will have to document your settings, so that any errors can be found.  
  • 0
    Ok, let's start
    home network 192.168.9.x
    office network 192.168.0.x
    192.168.9.0  192.168.0.0 Allow on both sides
    NAT-T not activated
    no additional routes
    No NAT rules (except dslmasq   Internal_Network__ -> All / All   MASQ__dsl   None )
    VPN Configuration:
    preshared keys, connection seems to be ok...
    auto packet filter for the key is off
    Home net:
    local endpoint: DSL
    remote Endpoint: office firewall
    local net:192.168.9.0
    remote net:192.168.0.0

    office net:
    local endpoint: external firewall ip
    remote Endpoint: dynamic ip
    local net:192.168.0.0
    remote net:192.168.9.0

    I can ping all hosts from both nets
    I can log into my home astaro from my office
    I can't log into my office astaro from home (allowed for my home subnet)

    Any additional info needed?

    Greetings Jens
      
  • 0 in reply to ramanujan
    Hi ramanujan,

    I have an allow rule for both directions on both firewalls.
    For you that would mean:

    192.168.9.0   192.168.0.0 Allow
    192.168.0.0   192.168.9.0 Allow

    Perhaps this helps

    cu
    Walter  
  • 0 in reply to ramanujan
    [ QUOTE ]
    192.168.9.0  192.168.0.0 Allow on both sides

    [/ QUOTE ] That seems a bit simplistic. You should have a matched, complementary set of rules, covering packet traffic in both directions, on each ASL box.

    Ping works, that indicates that you have a properly routed path.  That's a start, but you still need an open path both ways through the packet filters on each end for the Microsoft RDP protocol.  
  • 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
    Morning,

    try to ping with larger packets. Like 1500. If this is'nt working ping with lower sizes 1450, 1420, 1400. 
    1400 should work at least.
    I think its a problem of the MTU-Size.
    If a lower MTU is working (the Ping) allow ICMP-Source-Quench in your Filter-Rules.

    Greetings
    Thomas  
  • 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.     
  • 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.
         
Cookie Information Banner