How to Stop one service from going through a policy based vpn on a Juniper ssg 140

Greetings Experts,

I use a Policy based VPN from a Juniper SSG 140 to another Juniper.  When I create the policy I allow all traffic through it.

I would like to stop one service from going through it, 3389.   We have a remote server in the main office and I want to make sure none of the sessions are going through the VPN.  

Is there a simple way to do this?  Normally I would just setup a policy, but not sure how in this case.

Thank you,
Kacey
Kacey FernSystem EngineerAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Sanga CollinsSystems AdminCommented:
There a a  couple of ways you can do this.

a) Create a new policy from trust zone to untrust with service = RDP and action = deny. Move this policy to the top of the policy list (this can be done during policy creation) The ssg processes policies from top to bottom so the RDP service will be denied before the policy to allow traffic through the VPN.

b) you can also restrict the VPN policy to only the services you wish to allow through the VPN ensuring only what you want goes through and RDP is denied.

Hope that helps
Kacey FernSystem EngineerAuthor Commented:
Won't Solution A stop all RDP traffic from going out?  We still need to use RDP to the web.

Was trying to avoid solution B, want to leave the vpn wide open, except for rdp.. Thats a lot of services.
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
You can also use a negative service list in the policy, allowing anything but RDP. But implementation was often failing (I followed up a lot of ScreenOS releases), and might not work as expected.

Yes, Solution A will stop all RDP traffic to the public. Instead of deny, set permit, and all RDP traffic will use that policy, if the policy is located above the VPN policy.
Defend Against the Q2 Top Security Threats

Were you aware that overall malware worldwide was down a surprising 42% from Q1'18? Every quarter, the WatchGuard Threat Lab releases an Internet Security Report that analyzes the top threat trends impacting companies worldwide. Learn more by viewing our on-demand webinar today!

Kacey FernSystem EngineerAuthor Commented:
Hi Qlemo,

so your saying setup a new rule, trust to untrust, allow RDP.  Then all RDP traffic will go to the web instead of through the vpn?  What if the computer is picking up the rd server through the vpn, you don't think it will sneak through?

I don't think traffic is going through the vpn, but I want to make sure.  The only reason we have the vpn is so people can print from the remote server in the main office to the network printer in their satellite office.  The satellite offices do not have our internal DNS.

**and yes I know you can print directly from remote desktop, but it is much easier to have them print to a network printer via their session.  We do not install the printers locally.  They are not on our domain so I can't control it from the server.  We have 4 satellite office with about 120 users accessing our rdp farm.
Sanga CollinsSystems AdminCommented:
If you have destination IP addresses configured as part of the VPN then you can use the following

1. trust to untrust
source = LAN IP or subnet
dest = IP or subnet at other end of VPN
service RDP deny

Leave all other rules the same.

This will only block RDP traffic that matches the source  IP (your LAN) and the destination IP (through VPN). If a user RDP to a server on the web, that traffic will not match the above policy and therefore will not be applied.
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
This will block RDP only if it is positioned above the VPN policy. And I would not do it. The way I suggested (important: RDP allow rule positioned prior to the VPN rule again!) is much more straight-forward.
And no, RDP will never hit the VPN policy. Once ScreenOS has processed a matching policy, no further policy is checked for. First matching policy wins.
Kacey FernSystem EngineerAuthor Commented:
Sanga,

Put the new policy above the vpn policy?
Sanga CollinsSystems AdminCommented:
Hi Kacey

The new policy needs to be above the VPN policy. The only traffic that will match will be when your source is the LAN and your destination is the subnet on the other side of the VPN.

A subsequent policy allowing all traffic to the internet for example would allow someone to RDP to an external server with no problems.

Even though I have route based VPNs I use a simillar setup to allow remote sites to RDP and VNC in between each other, but deny them RDP/VNC access to my central office.
Kacey FernSystem EngineerAuthor Commented:
On the firewall at the satellite office:

after I setup the policy to block RDP to the main server internal subnet, some users were unable to connect to the remote server.  They use a public name, and none of them are on the main office's domain.  I checked the policy log and it is indeed blocking traffic, so some of these computers are trying to sneak though the vpn.  It doesn't make sense, since all the computers are using a public DNS so it should route them through the web.  

I asked the desktop guys and they confirmed that some of the computers have been moved from the main office to the satellite.  Not sure if they are the computers in question yet.  I'm guessing that the computers are remembering the internal IP address of the remote server from our internal DNS server.  Not sure how, these computers have been there for months and rebooted countless times.

I unchecked the bloc rdp policy and they were able to connect.

Only thing I can think of is to put an entry in their host file.  Remote sever = public ip.

Any thoughts?  

also, before I started this thread, on each satellite firewall I have a policy that sends all rdp traffic to the public IP of the remote server.  I created an untrust address with the remote IP and then created the policy.  I left this policy up the entire time, and it's still there.  It is in first position.
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
Sorry, but I'm totally confused. Time to show some more details about the (IP) config. I also don't know why you are blocking RDP instead of allowing it - unless you do that for testing only.
Is the VPN policy also Trust to Untrust?
Kacey FernSystem EngineerAuthor Commented:
The reason for blocking rpd is because I don't want the rdp connection to go through the vpn, I want it to go through the Internet.  

yes the policy is trust to untrust to block rpd from the local subnet to the untrust subnet of the main office.
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
That logic is wrong, as I said already. If you block RDP,  you are exactly doing that,  and need to be very specific (means : Source and Destination being as restrictive as possible.  And you still need a policy allowing the traffic to flow to internet. The default config is a deny-all, so no policy = no traffic.
Kacey FernSystem EngineerAuthor Commented:
I have multiple trust to untrust policies on the satellite office firewall.  I'll list them in order from top to bottom

1. rdp from trust to a specific external IP address, which is my remote server in another office.  (logic says all RDP traffic should route there, right?)
2. (which is disabled now) block RDP traffic to the local subnet of my main office, which is on the other side of the vpn.  The vpn is set to let all traffic through.  So what I thought was if I just block the rdp traffic from going to the subnet on the other side of the VPN, the firewall would force the traffic through the web to the external IP, where it should be routed do.
3. vpn policy
4. allow all from trust to untrust
Qlemo"Batchelor", Developer and EE Topic AdvisorCommented:
That sequence is correct.
1. You first allow RDP to a specific external address (or all, if you like). RDP traffic will always hit this policy, and no other one will get checked. For Trust => Untrust, NAT works as expected.
2. You block all RDP traffic. Since the "permit" policy is checked prior, you should see RDP traffic to any other location than the allowed one be blocked by this policy.
3. The VPN policy allows specific addresses, and should never see RDP traffic.
4. "Allow all" will pass all traffic not matching anything of the prior policies.

Setting the logging features ("at session begin") of each or single policies should be the first action in troubleshooting.
The more advanced user will use the CLI to debug the packet flow (keywords: set ffilter, debug flow) with a very narrow filter definition to know exactly what happens.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Kacey FernSystem EngineerAuthor Commented:
Thanks for your help.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Hardware Firewalls

From novice to tech pro — start learning today.