Veeam is happy to provide a free NFR license (1 year, 2 sockets) to all certified IT Pros. The license allows for the non-production use of Veeam Availability Suite v9.5 in your home lab, without any feature limitations. It works for both VMware and Hyper-V environments
Course Of The Month
11 days, 2 hours left to enrollBecome a Premium Member and unlock a new, free course in leading technologies each month.
Solved
Configuring Netscreen/Juniper Firewall to allow remote desktop access to server
Posted on 2006-11-15
Hi,
I need help configuring a netscreen/Juniper NS5GT firewall so that someone from outside can connect to a server on our LAN (IP address is 10.10.10.3) through Windows Remote Desktop.
Here is what I have tried and is NOT working.
I created a new custom service object named "MSTSC (desktop sharing)" with parameters of:
TCP src port: 0-65535, dst port: 3389-3389
UDP src port: 0-65535, dst port: 3389-3389
Then I created a new policy from Untrust to Trust with the following parameters:
Source Address: any
Destination address: any
Service: MSTSC (desktop sharing)
Application: (ignore)
Action: permit
Antivirus profile: none
Tunnel-VPN: none
Tunnel-L2TP: none
And under "Advanced"
NAT-Destination Translation is checked with Translate to IP set to 10.10.10.3 (map to port is unchecked)
Authetication is unchecked
Traffic shaping is unchecked
I have two other policies from Untrust to Trust: One is to allow pinging (not sure it is doing anything) and one that was used to set up our VPN (which is working). Both of those policies come before this new one I created for desktop sharing.
I only have one policy from Trust to Untrust which permits anything from any address to any address.
From outside the company LAN (e.g., at home), I try to connect through Remote Desktop sharing (from Win XP Pro) to the public IP address we all have when we are on the LAN (i.e., what www.showmyIP.com reports when I'm at the office), but the Remote Desktop App on my computer doesn't seem to be able to get a response from the server (don't remember the exact message, but it seems to time out)
Any suggestions?
I'm also planning to modify the policy to specify the From IP address for better security once I get it working, but let me know if you have any suggestions related to that or other issues of security.
Thanks!
Tim
I need help configuring a netscreen/Juniper NS5GT firewall so that someone from outside can connect to a server on our LAN (IP address is 10.10.10.3) through Windows Remote Desktop.
Here is what I have tried and is NOT working.
I created a new custom service object named "MSTSC (desktop sharing)" with parameters of:
TCP src port: 0-65535, dst port: 3389-3389
UDP src port: 0-65535, dst port: 3389-3389
Then I created a new policy from Untrust to Trust with the following parameters:
Source Address: any
Destination address: any
Service: MSTSC (desktop sharing)
Application: (ignore)
Action: permit
Antivirus profile: none
Tunnel-VPN: none
Tunnel-L2TP: none
And under "Advanced"
NAT-Destination Translation is checked with Translate to IP set to 10.10.10.3 (map to port is unchecked)
Authetication is unchecked
Traffic shaping is unchecked
I have two other policies from Untrust to Trust: One is to allow pinging (not sure it is doing anything) and one that was used to set up our VPN (which is working). Both of those policies come before this new one I created for desktop sharing.
I only have one policy from Trust to Untrust which permits anything from any address to any address.
From outside the company LAN (e.g., at home), I try to connect through Remote Desktop sharing (from Win XP Pro) to the public IP address we all have when we are on the LAN (i.e., what www.showmyIP.com reports when I'm at the office), but the Remote Desktop App on my computer doesn't seem to be able to get a response from the server (don't remember the exact message, but it seems to time out)
Any suggestions?
I'm also planning to modify the policy to specify the From IP address for better security once I get it working, but let me know if you have any suggestions related to that or other issues of security.
Thanks!
Tim
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
2-
2
- +2
7 Comments
1. i wouldn't open this up since it is a rather large security hole. I would setup a VPN and have external users VPN in and THEN access remote desktop
2. but if you want to use remote desktop and have external users directly remote in, then you will need to do one of two things
a) setup port forwarding so any request for port 3389 gets redirected to the LAN ip of 10.10.10.3
b. setup a static mapping of another external public IP (if you have one) that is mapped to 10.10.10.3
2. but if you want to use remote desktop and have external users directly remote in, then you will need to do one of two things
a) setup port forwarding so any request for port 3389 gets redirected to the LAN ip of 10.10.10.3
b. setup a static mapping of another external public IP (if you have one) that is mapped to 10.10.10.3
Thanks for the quick comments. For employees we have VPN set up, but this is our phone PBX vendor who wants to remotely tweak configs just on our dedicated computer for the phone system. It doesn't sound like they have the same VPN client, but it is very possible I could give them the parameters that they could use with their client. But I thought this would be easier to set up (less/no configuration on their side) and I would think restricting this to their IP address would make it pretty secure.
I thought the configuration I described above would do what you call 2a, but please explain if and how it is different.
Thanks again,
Tim
I thought the configuration I described above would do what you call 2a, but please explain if and how it is different.
Thanks again,
Tim
set up a VIP in your interfaces for that particular client machine
it should be a CLI command like
set interface untrust vip untrust 3389 "RDP" 10.10.10.1
and then change the policy -- it should be from untrust to untrust (from outside your network to the untrust interface of your netscreen) and should look something like
set pol id 5 from "Untrust" to "Untrust" "Any" "VIP(untrust)" "3389" permit log
(the policy id "5" is just whatever policy # you have already...I used 5 as an example because I'm guessing you have 5 policies already)
Once that is done, have the vendor (or whoever) RDP to the FIREWALL's untrust address; it will do the PAT magic for you and then it'll work.
it should be a CLI command like
set interface untrust vip untrust 3389 "RDP" 10.10.10.1
and then change the policy -- it should be from untrust to untrust (from outside your network to the untrust interface of your netscreen) and should look something like
set pol id 5 from "Untrust" to "Untrust" "Any" "VIP(untrust)" "3389" permit log
(the policy id "5" is just whatever policy # you have already...I used 5 as an example because I'm guessing you have 5 policies already)
Once that is done, have the vendor (or whoever) RDP to the FIREWALL's untrust address; it will do the PAT magic for you and then it'll work.
If you have another public ip address your not using, Creating a MIP would work and just allow destination 3389 tcp/udp through. Also make sure that you can RDP to the server from inside your network so that you know that Windows firewall or allow RDP is not interfering. Making a MIP is found on http://kb.juniper.net/CUSTOMERSERVICE/index?page=kbdetail&record_id=0244022611e8310108012c3c1906630
the way you describe it being setup, the NAT is only outbound, not inbound. For the inbound translation to be set (so that it works as you seem to expect it in situation 2a above -- this is better known as inbound PAT, not NAT btw), you have to setup a VIP or MIP as detailed above by mikeleebrla, myself or ccreamer_22.
Featured Post
Drastically shorten your training time with WalkMe's advanced online training solution that Guides your trainees to action. Forget about retraining and skyrocket knowledge retention rates.
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
ADCs have gained traction within the last decade, largely due to increased demand for legacy load balancing appliances to handle more advanced application delivery requirements and improve application performance.
Make the most of your online learning experience.
NetCrunch network monitor is a highly extensive platform for network monitoring and alert generation. In this video you'll see a live demo of NetCrunch with most notable features explained in a walk-through manner. You'll also get to know the philos…
Monitoring a network: why having a policy is the best policy? Michael Kulchisky, MCSE, MCSA, MCP, VTSP, VSP, CCSP outlines the enormous benefits of having a policy-based approach when monitoring medium and large networks. Software utilized in this v…
Suggested Courses
Earn Certification
HTML5 Specialist - Certification
Free withPremium
Course of the Month11 days, 2 hours left to enroll
628 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.