Pulse Secure formerly SSL VPN
Showing results for 
Search instead for 
Do you mean 
Reply
Contributor
Posts: 18
Registered: ‎10-02-2008
0

pre-deployment question

quick question...

 

Are these devices meant to be deployed with one 1 interface in the DMZ and 1 interface on the inside network? 

 

cheers

Recognized Expert
Posts: 420
Registered: ‎03-24-2008
0

Re: pre-deployment question

Yes.  One interface is in the unprotected network (typically the Internet) and one in the protected network (typically your enterprise's internal network).

Contributor
Posts: 18
Registered: ‎10-02-2008
0

Re: pre-deployment question

thanks for the info.

 

I trust these devices are running a pretty secure OS with little/no chance of being exploited themself?

Distinguished Expert
Posts: 2,402
Registered: ‎01-29-2008
0

Re: pre-deployment question

Yes - the O/S is a hardened one. There is quite a bit of literature on this on the Juniper main web site.

Kevin Barker
JNCIP-SEC
JNCIS-ENT, FWV, SSL, WLAN
JNCIA-ER, EX, IDP, UAC, WX
Juniper Networks Certified Instructor
Juniper Networks Ambassador

Juniper Elite Reseller
J-Partner Service Specialist - Implementation

If this worked for you please flag my post as an "Accepted Solution" so others can benefit. A kudo would be cool if you think I earned it.
Ray
Contributor
Posts: 76
Registered: ‎11-12-2007
0

Re: pre-deployment question

We do ours using just the internal interface on a DMZ. That way we can monitor and control where the box can go on the internal network. Multi-homed stuff crossing security boundaries are always a concern to me.

 

Ray

ben
Contributor
Posts: 126
Registered: ‎12-06-2007
0

Re: pre-deployment question

Ray, but you can control for sure, if the outside interface is directly connected to a firewall (outbound) and the internal interface to a firewall inbound.

So you can also monitor where the machine can go in inside direction and how it is reachable from the outside / internet network.

 

 

Contributor
Posts: 18
Registered: ‎10-02-2008
0

Re: pre-deployment question

Ray - what you have described is ideally how I would like to deploy this kind of service.  Effectively single-armed and located in a dmz.

 

I have had as SA2500 on eval but was not sent any documentation or access to the support site.  As such, I deployed using both the internal and external interface - which isn't what I really want to do for production.

 

Is the method of deployment you have described outlined in the support documentation?  Could you point me to it?  Did you come across any gotcha's deploying it this way?

 

thanks

will

 

Contributor
Posts: 18
Registered: ‎10-02-2008
0

Re: pre-deployment question

Ben, if both your external and internal interfaces are screened by your firewalls, what is the point of having them both in use?
Ray
Contributor
Posts: 76
Registered: ‎11-12-2007
0

Re: pre-deployment question

No gotchas at all. Only the internal interface is in use and that is the management interface also. I don't know if it's documented anywhere but it's been in use for almost two years with zero issues.

 

Ray

Distinguished Expert
Posts: 2,402
Registered: ‎01-29-2008
0

Re: pre-deployment question

Hey Will - I will jump in, in support of Ray. I have implemented this configuration in several customers and it is also the same one that my company uses. We could probably argue the merits of either solution but they are both very acceptable. What is right? The one that works, is easy to implement and that fits in with your internal architecture.

 

If you have an eval unit you should have recieved documentation from Juniper or your reseller. You can contact them and they should give it to you.

 

However - there is really not much to bringing up the unit this way. You bring the unit up via a console cable - IP address, name, DNS, self cert....

 

Login build out the box (make a realm, a role and some resources...) and just hit it from inside your network with the assigned IP - create the necessary map to punch through the firewall with the outside IP mapped to inside and you are good to go.

 

If you can't seem to get hold of the documentation easily - go yell at the sales guy or just post the questions here.

 

 

Kevin Barker
JNCIP-SEC
JNCIS-ENT, FWV, SSL, WLAN
JNCIA-ER, EX, IDP, UAC, WX
Juniper Networks Certified Instructor
Juniper Networks Ambassador

Juniper Elite Reseller
J-Partner Service Specialist - Implementation

If this worked for you please flag my post as an "Accepted Solution" so others can benefit. A kudo would be cool if you think I earned it.
Contributor
Posts: 18
Registered: ‎10-02-2008
0

Re: pre-deployment question

 

Ray/Kevin - thanks for the info.  When I deploy into prod it will be with a single nic. Just wanted to be sure there were no issues - I've had issues doing this kind of deployment with other vendor appliances so wanted to know if there were any issues I should be aware of before rolling out.

 

thanks again

will

 

Highlighted
Contributor
Posts: 17
Registered: ‎10-28-2008
0

Re: pre-deployment question

'With my paranoid hat on'

 

Deploying this way is an issue - as only the encrypted traffic is processed by the firewall.  All other traffic, like netconnect traffic, goes 'unfiltered'  into the internal network.

 

How about sub-interfacing the firewall nic and have the both ports going back into the firewall, were at least

the exiting traffic can be checked.

 

 

 

 

Ray
Contributor
Posts: 76
Registered: ‎11-12-2007
0

Re: pre-deployment question

You may have inadvertently just argued against the deployment practive of having the internal port on the LAN when using both ports. :-)

 

If you use only the internal port, the traffic flow is this way:

 

Internet HTTPS -> firewall -> internal port -> decrypted HTTP (and the IVE does its thing)

 

decrypted HTTP/NC/Whatever -> Internal port -> firewall -> LAN

 

Routing on the firewall and IVE control the flow of traffic even though we're just using one port. I then use firewall rules to inspect and control the traffic between the IVE and the LAN, something that is impossible if you put the internal port on the LAN.

 

Ray

Contributor
Posts: 17
Registered: ‎10-28-2008
0

Re: pre-deployment question

To avoid confusion im arguing for:

 

firewall nic (sub interface) -> switch (vlan xxx) -> IVE external port + IVE internal port -> switch (vlan yyy) -> firewall nic (sub interface) -> internal net 

 

The use of the switches also lends itself to clustering.

 

 

 

 

Contributor
Posts: 18
Registered: ‎10-02-2008
0

Re: pre-deployment question

Ray / Mutt

 

I've tried doing the single-armed approach as its what I've used on several other devices.  However, Im experiencing a problem...

 

Ray - as you explained it is as I have it setup.  Only the internal interface is configured with an IP add (dmz address).  Logical Traffic flow is:

 

internet ---> FW ---> IVE ---> FW ---> internal lan server

 

Heres what I see.

 

Traffic comes into the FW, is natted and is forwarded onto the IVE -- This works.  I see inbound 443 traffic to the IVE from internet clients.

 

The IVE does nothing with this traffic at all...  No packets are initiated by the IVE whatsoever.  I would expect to see the IVE initiate LDAP traffic to the configured auth servers (tcp/389) in order to authenticate the inbound client connections it was receiving.  it doesnt.

 

I know the IVE can talk (for example) LDAP to the internal auth servers as if I click the "test connection" box in the Auth section I then see 2-way LDAP traffic as expected.  

 

It doesn't appear to be a routing thing and its not a firewall thing.  Whats getting me is the IVE doesnt seem to be doing anything with inbound client connections - its not trying to auth them. 

 

(I've observed all this with numerous tcpdumps).

 

any help on this would be much appreciated!

Contributor
Posts: 18
Registered: ‎10-02-2008
0

Re: pre-deployment question


ozmark wrote:

To avoid confusion im arguing for:

 

firewall nic (sub interface) -> switch (vlan xxx) -> IVE external port + IVE internal port -> switch (vlan yyy) -> firewall nic (sub interface) -> internal net 

 

The use of the switches also lends itself to clustering.

 


 

Mark - there is no need for the 2nd port / vlan connection, if you can config using a one-armed approach.  Inbound and outbound traffic would still be firewalled.  The benefit of the one-armed approach is that you can keep your dmz-based devices physically and logically seperate from your internal devices.  The only devices with interfaces on the clean and dirty/semi-dirty (ie dmz) segments of your network would be your firewalls.  This is beneficial in many ways.