Juniper (ScreenOS) concepts

Juniper (ScreenOS) concepts

Basic concepts

• Zone. Juniper controls traffic between "zones" using policies. Each interface of the Juniper firewall device belongs to a certain zone. For example, the interface to the internal network is marked as connecting to a zone named "trust", the interface to the Internet is marked as connecting to a zone named "untrust". The idea is that you can multiple interfaces connecting to the same zone (e.g., to the "trust" zone), they can be grouped together so that you don't need to configure policies for each interface. Instead, you only configure policies for traffic between the "trust" and "untrust" zones.
• Obviously, the interfaces in the same zone should have the same security protection. Therefore, traffic between different zones must be checked and traffic between different interfaces in the same zone is NOT checked (by default).
• Virtual router. There are multiple "virtual routers" in a Juniper device. Each virtual router contains its own routes so that, for example, routes for internal network are separate from other routes. The idea is to avoid exposing the routes to the outside, e.g., through RIP or OSPF. Virtual routers are just like physical routers: if you need to forward a packet from one virtual router (VR) to another, just define a route and use the latter as the gateway.
• Each zone is associated with a virtual router (also called a "routing domain"). As each interface belongs to a certain zone, it also belongs to a certain virtual router, so packets arrived at it are processed by that virtual router.
• There are two pre-defined virtual routers: trust-vr (for all routes) and untrust-vr (for routes to be exposed to the Internet).
• Policy. Stateful TCP and UDP inspection is performed by a policy so that reply packets are automatically included. That is, to allow HTTP access from untrust zone to a host in the DMZ zone, it is enough for the policy to allow the first packet (untrust => DMZ) and there is no need to explicitly allow the reply packet (DMZ => untrust).
• For NAT and VPN, policy checking is done before translation or encapsulation (initiating from internal to the Internet) and after translation or decapsulation (reply from Internet to internal), so you will use the "original" addresses in the policy. For example, to allow public access to a web server (using a private IP) in the DMZ through a public IP, the destination address in the policy should be the private IP instead of the public IP.

NAT

• Source NAT. To access the Internet with source NAT, just put the internal interface (usually in the "trust" or DMZ zone) into "NAT mode". When a packet is passing through it to the "untrust" zone, the device will perform source NAT on the packet. The reply packet is also handled automatically.
• The external interface (usually in the "untrust" zone and connecting to the Internet) should be in the "routing mode".
• If a packet is passing between two internal interfaces in NAT mode, no NAT is performed. The idea is that NAT is only used for accessing the Internet, not between different departments in the company.
• Source NAT can also be done with a policy (instead of in the incoming interface). In that case ("policy-based source NAT"), the mode of the incoming interface isn't important anymore and the NAT policy will take priority. Policy-based source NAT can perform NAT more selectively, but then you can not apply further policies to restrict the traffic (but it is not required really because if NAT is not done, the packet can't go out).
• Destination NAT. This can be done with MIP (mapping a public IP to a private IP), VIP (mapping a public IP+port to a private IP+port) or a policy.
• MIP is usually defined in the public interface (more precisely, the "hosting" interface should have be on the same subnet as that MIP). It will accept incoming packets and the reply packets automatically. In fact, it will perform source NAT when the internal host initiates traffic to the Internet.
• VIP is similar to MIP except that you can map different ports of the same public IP to different internal hosts. Also, NAT will not be performed if the internal host tries to initiate traffic to the Internet. To allow that, normal source NAT is needed. A VIP can be the same IP as that of the public interface, while this is not allowed with MIP.
• All MIP and VIP "interfaces" belong to the "global zone". They are special because they are just "proxies" for the private IPs. 

VPN

• There are two ways to implement a VPN in Juniper: policy-based (encapsulate the packet when it matches a policy) or route-based (encapsulate the packet when it matches a route and is processed by a tunnel interface).
• Route-based VPN. It is implemented using a tunnel interface on the two sides. The tunnel interface in the Juniper device is configured to be in a certain zone. It can be different from the ultimate outgoing physical interface (e.g., the tunnel interface may be in "branch-office" zone while the physical interface in "untrust" zone).
• Route-based VPN works by routing packets to the tunnel interface, which is bound to a VPN tunnel (or called the "VPN gateway"). All the VPN information such as pre-shared key,  algorithms to use and the peer IP is stored in the VPN gateway. The tunnel interface doesn't need an IP.
• Dial up peer. If the peer is using a dynamic IP, there is no way to set the peer IP in the VPN gateway object. In that case, just choose "dynamic" so that it will just wait for connections from the clients and use their IPs. To compensate the security (to authenticate user instead of device), you should specify a user or user group in the VPN gateway object and bind that user to an "IKE user" who can be authenticated with PKI or a pre-shared key.
• Proxy ID. In ISAKMP in phase 2 (establishing phase 2 SA), it is possible for the gateways to establish different tunnels (SA's) for different "entities" (e.g., different internal servers, different internal networks). Each such entity is identified by an ID. Juniper calls it the "proxy ID". Usually, it can be just a string representing the internal network such as 192.168.1.0/24. The local Juniper gateway will send its local proxy ID (specified in the VPN gateway object) to the Juniper gateway at the other side, which will try to match it against the remote proxy ID (specified in the VPN gateway object). So, make sure that they match.
• Why not merge the concept of VPN gateway and the tunnel interface into one? Two reasons:
• A VPN gateway can be referred to by a policy to set up a policy-based VPN.
• A tunnel interface can be bound to multiple VPN gateways (but why is this needed? It seems to be an "artificial" feature).
• Null route. Juniper can monitor a VPN tunnel (SA) to see if it is still working by pinging it from time to time ("VPN monitoring").  If using a route-based VPN and the tunnel is detected as down, the interface will be marked as down and then the route will be skipped. Then the traffic may be sent to the default route (the Internet)! Either don't use VPN monitoring or add a route that sends the traffic to the Null interface (which just drops the packet). The route should be similar to the route performing encapsulation but with a higher metric so that it is normally not used.
• Policy-based VPN. The source IP used in the policy is the IP assigned to the tunnel interface on the client.
• Route-based VPN is more versatile than a policy-based VPN as:
• You can apply multiple policies for a single SA. This is because filtering (policy) and encapsulation are done independently.
• You can use a routing protocol to propagate the route to the remote site throughout the headquarter internal networks. A policy is not a route and can't be propagated.
• The tunnel interface can be put into a desired zone (e.g., "branch") instead of the "untrust" zone.
• L2TP VPN. It is possible to use IPSec tunnel mode to build a VPN, but IPSec can't assign IP to the client. To do that, you should use an L2TP VPN. L2TP can be considered just like PPP (IP assignment and encapsulation) except that PPP requires a point-to-point. So, by configuring the peer IP, the L2TP protocol software can emulate a point-to-point link to PPP, then it can use the peer IP to deliver the PPP packet (PPP inside a UDP inside an IP). L2TP doesn't provide encryption, so it is used with IPSec to build VPN. L2TP, just like PPP, can use PAP and CHAP for user authentication.
• To configure for establishment of L2TP tunnel:
• Set the L2TP configuration (e.g., IP pool to use, authentication method) as global default or in the user object.
• Create an L2TP tunnel object,  specify the user group that is allowed to connect and create a policy to send the packets to be encapsulated to that tunnel. The source address can be set to the "Dial-Up VPN" address book entry (What does it mean? All the IPs connected with L2TP and IPSec?).
• L2TP over IPSec. To apply IPSec to protect the L2TP packets, in the same policy enabling the L2TP tunnel, enable the IPSec tunnel by setting the IPSec VPN gateway. Each user are both an IKE user (for IPSec authentication) and L2TP user (for L2TP authentication).