10-23-2008 10:01 AM
Yes - the O/S is a hardened one. There is quite a bit of literature on this on the Juniper main web site.
10-23-2008 05:04 PM
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.
10-24-2008 02:40 AM
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.
10-24-2008 04:31 AM
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?
10-24-2008 05:17 AM
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.
10-24-2008 05:52 AM
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.
10-24-2008 06:01 AM
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.
10-28-2008 07:55 PM
'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.
10-29-2008 05:32 AM
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.
10-29-2008 06:09 PM
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.
12-05-2008 04:22 PM
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!