Verify Secured LAN Connectivity

Verify that the SRX has assigned IP addresses to the LAN clients.

Notice that the devices have the same MAC addresses as before (see Branch SRX Default Connectivity), but now, they’re associated with different IP subnets and IRB units, based on their respective VLAN assignment. The display confirms at least one device is in the vlan-trust, the guests, and the contractors VLANs. This output confirms that your DHCP servers function properly within each VLAN.

Verify your VLAN configuration.

The output confirms that you have correctly configured the guests and contractors VLANs.

Verify that devices in the guests VLAN and zone can access the Internet. You confirm Internet access with a successful ping to www.juniper.net. Recall that your branch office design states guests are only allowed to send HTTP/HTTPS and ping traffic to the Internet.

If your guests zone device supports a command line HTTP client, like CURL, use it to verify HTTP access to the Internet. You can always use a web browser if the device has a GUI interface to test web connectivity.

We won't bother trying to find an Internet connected machine to confirm that all other services, that is, SSH, Telnet, FTP, and so on won't work. One option here is to temporarily remove the policy rule that allows ICMP from the guests to the untrust zone. Once the change takes effect the ping to www.juniper.net should time-out.

We'll finish validating the guests VLAN by confirming that guest devices are unable to ping the IRB interface in either the trust or contractors zones.

The pings to the IRB interfaces in the trust and contractors zones fail, as expected. Although not shown, pings initiated from guests to end stations in the trust or contractors zones also fail. Again, you need an explicit policy to permit traffic to flow between zones. For guest users, the only security policy in effect is to allow HTTP and ping traffic to the untrust zone.

Verify that the employees in the trust zone can access the Internet.

Verify that the employees can ping the contractors.

The output shows that the ping is not successful. See Debug Connectivity Issues for information about how to debug this issue.

Let's try to debug the issue of the employees being unable to ping the contractors. We'll use traceoptions to debug the packet flow as the packets traverse from the trust zone to the contractors zone. At a minimum, the traceoptions configuration must include a target file and a flag. The argument to the file command specifies the file name that stores the trace output. The argument(s) to the flag command defines the type of events to be traced.

With the tracing activated, generate pings from the trust zone to the contractors zone. While the pings are failing, use the show log <log_name> CLI command along with the find switch to quickly locate areas of interest in the trace log file.

The highlighted entries confirm that the test traffic sent from the trust zone to the contractors zone is being dropped. The message says denied by policy default-policy-logical-system which indicates there isn't a policy to allow this traffic.

You must have a policy to allow traffic to flow between zones. Add the below configuration to configure a security policy that allows the desired traffic types between the trust zone and the contractors zone. The configuration is in Quick Configuration set format, so you can simply paste it into the branch SRX at the [edit] hierarchy:

Be sure to commit your changes. Now, the ping from the trust zone to the contractors zone should succeed. Now that your debugging is complete, remove the security flow traceoptions configuration .

Verify that the contractors cannot communicate with the clients in the trust or guests zones.

Only the ping to the IRB interface (irb.30) should succeed. Because the client IP addresses can change with updated DHCP assignments, we opt to test inter-zone connectivity by pinging the IRB interface for a given zone. In this example, the IP addresses assigned to the IRB interfaces are static and therefore won't change over time.

As expected, the ping from a contractor zone device to the IRB interface for the contractors zone succeeds. Now, you verify the lack of connectivity to the trust and guests zones. Refer to Secure Local Branch Connectivity for details on the addresses assigned to the IRB interfaces in this example.

The output shows that only the ping to 192.168.30.1 (assigned to irb.30) is successful. This confirms that contractors are unable to access the trust and guests zones.

Confirm that the contractors cannot access the Internet.

Notice that the attempt to ping www.juniper.net returns a hostname lookup failure message. This branch office doesn't have a local DNS server and relies on a public DNS service that is reachable only over the Internet. The failure to resolve the host name is a good indication that contractors are correctly blocked from Internet access. As a final confirmation, ping the public DNS server by its IP address. Again, the ping fails as expected.

These results complete validation of the branch office's secure local connectivity. Good job! In the next step, we'll show you how to establish secure connectivity over the Internet.