Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 18 replies
  • Subscribers 2 subscribers
  • Views 12784 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

Terminal Service DNAT

Skodras
Hi all, i have the following configuration on my astaro 6.201:
eth0: External address (gets the ip address from my isp
eth1: 192.168.0.1(internal network)
eth2: 192.168.1.1(dmz)

In dmz zone i have a server where i need to connect through terminal service.
I defined that service with TCP 3389 port and allowed it also through packet filtering. When i try to connect to that server i get the login screen and when i enter the password i get disconnected.
2 of 10 retries i get connected without a problem!
No software firewall is running on both sides..

Any ideas?
Thanks


This thread was automatically locked due to age.
Parents
  • 0
    Hmm, what protocol do you use for the remote access? Maybe this protocol uses more than one port (like FTP one control connection and one for the payload data)?
  • 0 in reply to Skodras
    I assume you connect from the Internal network. Did you configure a masquerading NAT from Internal network to DMZ network?
    But probably you did, cause otherwise you wouldn't even get to the login...

    Did you examine the packet filter logs? You could also make a tcpdump on the DMZ and/or Internal interface and look whats happening to the packages.
  • 0 in reply to mority
    Yes, that's right.. It's really strange that some times i connect and most of times not. This is happening also if i connect through pptp!

    I have the live packet filter log open and no packet is being dropped. I tried also monitoring the /var/log/packetfilter.log but with the same results...
    Can i make tcpdump with astaro?
  • 0 in reply to Skodras
    Yes, tcpdump is installed by default in ASG software, but you can use it only in the shell, not through WebAdmin.
  • 0 in reply to mority
    Lets take the firewall out of play by connecting another computer on the dmz and see if you can connect to the terminal server. This way we know if it is working.
  • 0 in reply to Keith_M
    Lets take the firewall out of play by connecting another computer on the dmz and see if you can connect to the terminal server. This way we know if it is working.


    That's true. You should make sure that the problem is not caused by the Windows server itself or some other component outside the ASG.
  • 0 in reply to mority
    Yes you are right, i have the same problem: i get disconnected after i enter the admin password. I installed ultravnc and everything is working great (behind firewall too). I guess it's something with the configuration of the terminal server but no time to investigate it further.

    Thank you guys..
  • 0 in reply to Skodras
    Not astaro issue ... You are running REMOTE Desktop or Terminal Services ?

    Remote DESKTOP is the Server / Workstation mode, Terminal Services is a 120 licence on Servers after which you can't connect.

    The Astaro is straight forward.
    Assume you have NAT/MASQ in the Internel Network to External interface.

    Create A service Definition Service for RDP with source port address of  1024:65535 to Destination port of 3389

    Allow an OUTBOUND Packet filter of INTERNAL Network to ANY on RDP Service (3389)

    Set a Network Definition up as a HOST object with thre IP address of your Target Server for RDP

    Allow an INBOUND Packet filter of EXTERNAL address to INTERNAL HOST Object Network to ANY on RDP Service (3389)

    Creat a SNAT/DNAT rule of:
    Source Address = ANY
    Destination Address = External Address
    Service = RDP
    Change Source to = NO CHANGE
    Change Destination to = HOST Server of RDP - Host Definition
    Service Destination = NO CHANGE
  • 0 in reply to RufusToofus
    I'd bet my bottom dollar it's the IPS... there are several rules that block logins to Terminal Servers (yes, sometimes you can get in regardless)... in the IPS rule config screen, do a search for RDP, and then Do a search for Terminal ... you'll find that you'll have several hits on those rules, just turn them off.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

Reply
  • 0 in reply to RufusToofus
    I'd bet my bottom dollar it's the IPS... there are several rules that block logins to Terminal Servers (yes, sometimes you can get in regardless)... in the IPS rule config screen, do a search for RDP, and then Do a search for Terminal ... you'll find that you'll have several hits on those rules, just turn them off.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

Children
  • 0 in reply to BrucekConvergent
    I'd bet my bottom dollar it's the IPS... there are several rules that block logins to Terminal Servers (yes, sometimes you can get in regardless)... in the IPS rule config screen, do a search for RDP, and then Do a search for Terminal ... you'll find that you'll have several hits on those rules, just turn them off.


    That's not a very smart bet since the original author already said that the issue was not originated by the ASG:

    "Yes you are right, i have the same problem: i get disconnected after i enter the admin password. I installed ultravnc and everything is working great (behind firewall too). I guess it's something with the configuration of the terminal server but no time to investigate it further."
  • 0 in reply to mority
    The rules that I speak of have no effect on UltraVNC... It's just a very similar issue to what I've resolved for several of my customers... for instance, there is an IPS rule that specifically blocks administrative logons to a Windows Terminal Server... with it enabled, one would experience trouble connecting most of the time (the rule isn't foolproof).  I myself often forget to disable this rule the first time I set an Astaro up, I remeber pretty quick when I can't connect!

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • 0 in reply to BrucekConvergent
    The IPS rule ID's you want to check (and disable) are:
    1447, 4060, and 1448.  There is one other (ID 2418) pertaining to preventing a RDP session from being established with no encryption; I generally leave it turned on and set to Drop..

    and Mority, I wasn't (and still am not) clear on whether he actually tested the RDP session internally or not... but these IPS rules will definitely ruin your day when you try to run RDP through an Astaro (or any other Snort box)..

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • 0 in reply to BrucekConvergent

    and Mority, I wasn't (and still am not) clear on whether he actually tested the RDP session internally or not... but these IPS rules will definitely ruin your day when you try to run RDP through an Astaro (or any other Snort box)..


    Okay, I'll try to keep that in mind if I ever have to do something like that.
  • 0 in reply to mority
    I was having a similar problem trying to get out from my internal network to an rdp server elsewhere.  I had create the Packet filter rule to allow RDP from internal to Any.  I had a nat-masquarade rule for the internal network.  

    What I found:
    After reading these posts in detail I found that the DEFAULT service definition for RDP on our asg220 (6.303) was  "RDP source port 3389 dest port 3389".  I changed it to the recomended source port of 1024:65535 and its working now.

    I wasn't aware that RDP appears to use random source ports.  I did notice that in the packet filter logs but can't explain it.

    Should this be reported to Astaro support as a bug?  Is set correctly by default in V7.
  • 0 in reply to lantech
    I suspect someone changed that service definition... the RDP Client will use a dynamic port on it's side (1024-65536), and the RDP server listens on only 3389 (this can be changed, but it is the default).  I believe all the ASG units I've seen come with this service definition set the way it supposed to be.  You should be fine from here on out.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • 0 in reply to BrucekConvergent
    [QUOTE=BrucekConvergent;64782]The IPS rule ID's you want to check (and disable) are:
    1447, 4060, and 1448.  There is one other (ID 2418) pertaining to preventing a RDP session from being established with no encryption; I generally leave it turned on and set to Drop..QUOTE]

    A correction is in order here.. .if you're using the new RDP Client (as distributed by Microsoft via Microsoft / Windows Update), you will need to also disable rule 2418 --- somehow using that client triggers that IPS rule, falsely, as the connections I've tested it with all force high encryption.  This wasn't a problem with the older RDP client.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

Cookie Information Banner