Best scenario for remote support personnel.

Thanks, nethole.  I hope he tries your suggestion because I would like to have confirmation that 'Username (Network)' is resolved when 'Username' logs into the SSL VPN.

Another option with SSL, IPsec or Cisco Remote Access is the ability to limit access to a single host by including only that in the 'Local networks' box when defining the VPN.

Cheers - Bob

Hi BAlfson, i can tell you that I'm sure it works, i used lot of this rule in my installation and work always fine.

The solution to include only a specified host in "local networks" is suitable only if all the users that use SSL must achieve to the specified host, but if another user need to connect to another host became a problem, i think the packet filter is the best way to filter traffic.

Best Regards

Thanks, nethole.  Since we always use L2TP whenever possible, I'm glad to know there's a way to do this with the SSL VPN also.

Cheers - Bob

Thanks for the info -

So to clarify - an external user can connect via SSL to a specific internal IP Host using their SSL name. Setup in just the packet filter alone - not in Dnat.
I would appeciate an example.

Thanks

David

Dear BAlfson I've read that now he is not using SSL, but I've answered to the first question:

-yes is possible to use SSL connection and filter the traffic of a user

He chose the L2TP because, i think, no one tell him how to do with SSL

example.JPG

In the example above you can see that:

sources: the user you want to be filtered *
services: the services type you want the user can use **
destination: the host you want that the user should achieve***


* you can create also users group, for example if a group of people have the same permission
** you can also create a group of services, for example terminal server+vnc+ping+trace route+.....
*** you can also create a group of hosts, for example if you want the selected user/s to achieve with the same service/s a group of hosts 

Just remember to disable the automatic packet filter of the SSL

TIPS: If you pass the mouse over the user object, in the yellow flag appear unresolved if the user is unconnected and the real assigned ip if he is connected

####################################################
You need to use DNAT only if you want to recognize the user connected (example assistance) without know the ip of the user, this is a trick I use if the EDP of our customers want to give assistance to the the remote users of his company.
As you know you can't give a static ip to a user, but you can create a DNAT rule that can really help you, like this one:

DANAT.JPG

this DNAT say that:

anyone is searching whit any services the false ip 1.1.1.1 must be redirect to the user a.chessa, this work always without know the real ip assigned by the dhcp pool, all you have to do to reach the user is to use the false ip you chose instead of the ip assigned by the dhcp pool

just remember do not use "Allow multiple concurrent connections per user"  in SSL

That's a very creative approach, and should work as advertised!  However, it seems more complicated than what Touchwood was asking for in his original post.  To take your original idea and Suzzyx's, it seems like just creating the following packet filter rule would work if indeed 'Username (Network)' resolves when 'Username' is connected via SSL VPN:

Source: 'Username (Network)'
Service: RDP (or other desired service(s))
Destination: [host(s) you want to make available]
Allow

In L2TP over IPsec, I would create 'Username' with a fixed, Remote Access IP, say 10.20.30.40, then create two PF rules, in order as follows:

Source: [10.20.30.40]
Service: RDP (or other desired service(s))
Destination: [host(s) you want to make available]
Allow

Source: [10.20.30.40]
Service: Any
Destination: Any
Drop

Cheers - Bob
PS Touchwood, please report back on what you tried and what worked and didn't. Thanks!

Hi BAlfson, as i wrote form the beginning, the packet filtering is the solution, in my previous post I have added only another TIP to make the remote user reachable.

Best Regards

Perfect, thanks for the clarification!

CHeers - Bob

To - Bob, Nethole and Suzzyx

Your efforts are much appreciated -

I used the scenarios suggested and it works perfectly.

Source -> User Name 
Service -> RDC
Destination -> Internal IP

Point to Note -

You still have to put in a valid network in "Local Networks" in the SSL section.
As mentioned do not select "Automatic Packet Filter Rules".

Regards and thanks again.