how to configure external and internal interrface On SA SSL VPN 4500

[irfanhussain_]

Hi

I am using SSL VPN ( SA4500 ) i want to configure external interface for user who will get the access to my Internal Network

can any one help me

[muttbarker_]

That is a pretty broad topic to cover

Have you looked in the admin guide -I would read the "getting started" chapter and take a look at the section on creating a test scenario.

[irfanhussain_]

Yes i have read the admin guide and created a test senario but when i test the user to directly connected with my Internal or External interface its fine .. when i add ed live IP on external interface and trying to get the web server connected to my internal interface i will not be able to even ping the server after getting session from outside ... should i configure network connect ? to binding the external and internal interface ?

thanks for your reply

[mnarine_]

What are you trying to accomplish? Which features are you enabling for the user after they signon (roles) and what does the user needs to do? Based on the requirements, you may or may not need Network Connect. If you're not running Network Connect, users will not be able to ping internal resources.

-Mike

[muttbarker_]

As Mike said - what are you trying to accomplish? If you are trying to push a ping through from an outside session to a device IP inside the network you will have to go and configue Network Connect. But if you are trying to serve up a web page from an internal server to an outside session then you will need to configure the approriate recourse profile, map to role, role to realm....

To punch a hole into your network like a classic IPSec VPN solution you will use Network Connect.

[irfanhussain_]

what i want to accompalished is that .. any one who wil connect SSL vpm from outside the network will get the OWA 2003 page from internal network ...

My External IP : 100.100.100.1

My Internal IP: 10.1.10.1

User Rule has been created, Resource pocliies has been created .user realm has also been created.

I just wnt to know how external user will get the same IP pool when he connects through internet.

[mnarine_]

irfanhussain

Since you want the user to get a OWA 2003 link, this is all web based. The user does not need to get an IP address or built an actual IPSec tunnel from the end-point to the SSL VPN. What you need to do is create a Web Resource Policy, which is basically a web link/bookmark to the OWA URL. Associate that web link/bookmark with the role created for the user.

The user will go to https://100.100.100.1, login and providing authentication is successful and user is mapped to the correct role, they will get a portal page on the SSL VPN with at least 1 web link to OWA. The user clicks on OWA and the SSL device acts as a proxy between the OWA server and the user.

FYI ... the SA can be configured to provide a number of different type of access -- Terminal Services, Web Resources, Telnet/SSH, Network Connect, SAM. Only Network Connect would provide a full IPSec tunnel and at that point the user will get an IP address that from a configured IP Pool on the SSL VPN. You should take a look at the admin guide for detail info on all these features.

In general, I do not enable Network Connect unless it's absolutely necessary. If I can provide the same access using one of the other features, I do that. Network Connect makes the end-point communicate with the internal networks directly (of course youc an setup ACLs on the SA to limit access).

Hope that helps.

-Mike

[muttbarker_]

Just to add to the great posting from Mike - the user will not get an IP Pool address. The traffic flow will be from the users external IP to the SSL-VPN external IP. Then on the inside the flow will be from the SSL-VPN internal IP address only to the internal resource (OWA server).

[irfanhussain_]

Thanks Mike and Kavin for your support... Now cleared .. i will test it and flag it when resolved

[irfanhussain_]

yes its worked fine . i have checked and tested it .. there is no need to define the IP pool for external users.

thanks Mike and Kevin for your support