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

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

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.

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.

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.

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.

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.

Sanga,

Put the new policy above the vpn policy?

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.

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?

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.

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.

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

Thanks for your help.