Skip to main content
AS
~6 min read|2021-2022|Networking & Infrastructure
Networking & InfrastructureCompleted Juniper network services lab2021-2022

Juniper vSRX Network Services Lab

Juniper vSRX lab covering routing, DHCP, DNS, NAT, OSPF, security zones, and SSH across multiple subnets.

Juniper vSRXJunos OSVMware WorkstationDHCP and DHCP RelayNATOSPFDNSMasqWiresharkSSH and SCP

I used a VMware-based Juniper lab to work through segmentation, core services, routing behavior, and SSH operations.

Built

Multi-subnet Juniper vSRX lab covering routing, network services, and zone policies.

My Role

Designed the topology, configured the services, tested traffic flows, and documented the results.

Visuals

1 diagram + 9 supporting visuals

Lab screenshots and configs

Lab screenshots and configs

The page uses selected screenshots and config excerpts. Full exports, credentials, and class material are left out.

Project Scope

Segmentation Model

Dual Juniper vSRX topology split into sensor, server, actuator, and transit segments with explicit zone and interface boundaries.

Network Services

Configured DHCP local-server and relay behavior, static routes, source NAT, and DNSMasq-backed name resolution inside the virtual lab.

Routing Validation

Proved reachability and path handling with ping, traceroute, routing tables, and Wireshark across up to five interconnected subnets.

Operations Workflow

Validated encrypted SSH sessions, password-free client and router access, SCP-driven key transfer, PuTTY login handling, and repeatable configuration archival on Junos.

Project Overview

This project brings several Juniper networking labs into one page focused on services, segmentation, routing, and operations.

The project page shows how the same VMware-based environment was extended from basic inter-subnet routing into DHCP, DNS, NAT, zone policies, OSPF, and secure administration workflows.

The visuals on this page come from the original lab work, so the implementation steps stay visible without rebuilding the whole setup from scratch.

Lab Scope

The lab environment centered on virtual Juniper vSRX routers, Linux clients, and carefully mapped VMware virtual networks.

Different assignments expanded the same core skill set from basic routed connectivity into service integration, policy control, and day-two operational handling.

Routing and Topology

  • Built dual-router and three-router VMware topologies with dedicated LAN segments and transit links.
  • Mapped Junos interfaces to VMware virtual adapters and aligned each router port with a specific subnet role.
  • Configured interface addressing, client gateways, and inter-subnet routing across multi-LAN layouts.

Service Plane

  • Configured DHCP local-server and relay behavior for different subnets and verified address delivery from client machines.
  • Added DNSMasq on a Linux VM to provide internal DNS records for service resolution inside the lab.
  • Configured source NAT and validated internet-bound traffic using packet capture and terminal testing.

Security and Operations

  • Separated interfaces into security zones and applied traffic rules between sensor, server, actuator, and transit networks.
  • Tested OSPF convergence and rerouting between three routers after link changes.
  • Used SSH, SCP, PuTTY, and commit-triggered archival workflows for password-based and key-based administration tasks across Linux hosts and Junos routers.

What I Implemented

  • Built dual-vSRX topologies with up to five connected subnets and checked end-to-end inter-LAN reachability.
  • Configured DHCP service and DHCP relay workflows and verified address assignment with client-side IPv4 settings and Wireshark DORA captures.
  • Applied static routes, NAT behavior, and external reachability tests to move beyond isolated lab-only communication.
  • Created and tested security zones and policy rules to control which hosts could ping or fetch web content across segments.
  • Configured OSPF on a three-router topology and validated rerouting behavior after changing an active path.
  • Set up DNSMasq on a Linux VM and connected router and client configuration to internal name-resolution testing.
  • Worked through SSH, SCP, and Junos administration tasks to make router access and configuration handling more repeatable.
  • Validated encrypted SSH packet flow in Wireshark, configured password-free login from Linux and PuTTY clients, and prepared commit-based config archival toward an SSH server.

Segmentation and Policy Control

The strongest part of the archive was not any single routing command, but the progression from flat connectivity into segmented policy thinking.

The security-zones lab split interfaces into named trust boundaries and then validated which hosts could communicate, which hosts were blocked, and where web access remained intentionally available.

That turns the project from a basic addressing exercise into a stronger networking story about traffic intention, enforcement, and observable verification.

Routing, Services, and Validation

  • Validated inter-subnet routing with direct ping and traceroute tests between remote LANs connected through different vSRX interfaces.
  • Captured DHCP traffic in Wireshark to show Discover, Offer, Request, and Acknowledge behavior while clients obtained leases.
  • Reviewed router routing tables and interface states to confirm expected reachability after addressing and route changes.
  • Used DNSMasq setup and packet observation to verify that internal DNS requests resolved toward the intended VM-hosted service.
  • Checked NAT and internet-bound ICMP behavior to confirm that lab clients could move beyond private-only communication where required.
  • Verified OSPF rerouting behavior after disconnecting an active path so the remaining route could carry traffic automatically.

Operations Workflow

The later labs moved beyond pure connectivity and into repeatable administration. SSH user handling, password-free access patterns, SCP transfer, packet inspection, PuTTY-based login from Windows, and config archival tasks made the environment feel more like infrastructure administration than classroom-only routing practice.

That matters because the operational layer is where a lot of networking work becomes real: not just building reachability once, but accessing devices safely, moving keys and files predictably, and keeping configurations manageable after changes.

For portfolio purposes, this gives the project a better balance between topology design, service delivery, validation, secure access, and day-two operations.

Secure Access and Configuration Handling

  • Inspected SSHv2 traffic in Wireshark to confirm the negotiated session path and show that payload data remained encrypted in transit.
  • Configured password-free login between Linux hosts and validated cross-platform access by using PuTTY with a converted private key from the Windows side.
  • Created a dedicated Junos super-user with SSH public-key authentication so router access could move away from password-only administration.
  • Used SCP to move key material and test files between hosts and routers as part of the administration workflow.
  • Configured Junos transfer-on-commit archival to send active configurations to an SSH server, turning routine changes into a repeatable backup step.

Key Learnings

  • A network project is stronger when it shows not only the topology, but also the checks that prove addressing, policies, and services behave as expected.
  • VMware-based labs become much more useful when the interface-to-subnet mapping is documented cleanly; otherwise router configs are harder to reason about and troubleshoot.
  • Zone-based policy work is a strong bridge between classic routing exercises and infrastructure security thinking.
  • Networking skill is easier to trust when routing and service configuration are backed by secure-access and configuration-management workflows, not just ping success.
  • Separate lab exercises become much stronger portfolio material when they are organised into one systems-level project.

Lab Topology and Segmentation

Overview of the two vSRX routers, segmented LANs, inter-router transit link, and service layers in the lab.

The diagram brings the Juniper work into one topology view: segmented LANs, inter-router transit, DHCP and DNS, NAT, zone policies, OSPF, and SSH operations.

Virtual Routing Core

Juniper vSRX appliances in VMware Workstation acted as the routed core for multi-subnet labs, with interface-to-VMnet mapping documented and validated.

Segmented LANs

Separate LANs were assigned to user, server, sensor, and actuator networks, with explicit addressing and gateway roles on each router interface.

Network Services

The lab stack covered DHCP local-server and relay workflows, DNSMasq-based name resolution, and source NAT for internet-bound testing.

Security Policy Boundaries

Zone-based controls were applied to restrict or allow traffic flows between specific segments, including web access and ICMP validation paths.

Dynamic and Static Routing

Static routes handled dual-router labs, while OSPF introduced dynamic path selection and rerouting across a three-router topology.

Operational Tooling

SSH, SCP, PuTTY, ping, traceroute, and Wireshark were used to verify connectivity, inspect encrypted traffic, and support repeatable router administration and config handling.

Visuals

Includes one topology image, nine screenshots, and five Junos configuration excerpts covering DHCP, zone policy, OSPF, SSH access, and config handling.

Step 01

Original topology diagram from the five-subnet routing lab showing dual vSRX routers bridging four user LANs across a routed transit network.

Step 02

Wireshark capture from the DHCP lab showing Discover, Offer, Request, and Acknowledge exchange while a client receives a leased address from the vSRX-backed service.

Step 03

OSPF lab view combining the routed triangle HLD with VMware adapter mapping used to check adjacency and rerouting between three routers.

Step 04

Terminal validation showing successful reachability across the inter-router link and remote LAN after routing tables and interface addressing were applied.

Step 05

DNS lab capture documenting DNSMasq service preparation on a Linux VM, including port inspection and resolver handover before domain testing.

Step 06

NAT troubleshooting capture using Wireshark to confirm local traffic, cross-subnet reachability, and internet-bound ICMP testing.

Step 07

Wireshark capture from the SSH lab showing encrypted SSHv2 traffic between Linux hosts.

Step 08

Operational administration workflow showing router SSH access, account update, and staged move toward password-free key-based management and file transfer.

Step 09

Windows-side password-free login workflow from my SSH key lab, showing PuTTY configured with a converted private key and a successful public-key-authenticated session into the Linux host.

Configuration Excerpts

junos

DHCP service and address pools

Source: ass_18_router1.json

system {
    services {
        ssh;
        dhcp-local-server {
            group Net3 {
                interface ge-0/0/1.0;
            }
            group Net4 {
                interface ge-0/0/2.0;
            }
        }
    }
}

access {
    address-assignment {
        pool Net3 {
            family inet {
                network 192.168.10.0/24;
                range USERS {
                    low 192.168.10.15;
                    high 192.168.10.20;
                }
                dhcp-attributes {
                    maximum-lease-time 60;
                    name-server {
                        8.8.8.8;
                    }
                    router {
                        192.168.10.1;
                    }
                }
            }
        }
    }
}

Taken from the DHCP lab and lightly trimmed for readability. It keeps the local-server configuration, pools, lease timing, DNS, and router options.

junos

Zone policy with custom HTTP application

Source: ass_54_R1.json

security {
    address-book {
        global {
            address SENSOR_LAN 192.168.10.0/24;
            address SERVER_LAN 192.168.11.0/24;
            address WEB_SERVER 192.168.11.2/32;
        }
    }
    policies {
        from-zone SENSOR_LAN to-zone SERVER_LAN {
            policy allow-icmp-udp-http-ports-80-8000 {
                match {
                    source-address any;
                    destination-address any;
                    application [ junos-icmp-ping junos-http my-http-8000 ];
                }
                then {
                    permit;
                }
            }
        }
        default-policy {
            deny-all;
        }
    }
}

applications {
    application my-http-8000 {
        application-protocol http;
        protocol tcp;
        destination-port 8000;
    }
}

Taken from the working zone-policy configuration. The original file also included shell output and a repeated config dump, so only the policy block is shown here.

junos

OSPF area participation on routed interfaces

Source: ass_49_R2.json

protocols {
    ospf {
        area 0.0.0.0 {
            interface ge-0/0/2.0;
            interface ge-0/0/1.0;
        }
    }
}

security {
    zones {
        security-zone R2_trust {
            interfaces {
                ge-0/0/2.0 {
                    host-inbound-traffic {
                        system-services {
                            ping;
                        }
                        protocols {
                            ospf;
                        }
                    }
                }
                ge-0/0/1.0 {
                    host-inbound-traffic {
                        system-services {
                            ping;
                        }
                        protocols {
                            ospf;
                        }
                    }
                }
            }
        }
    }
}

OSPF excerpt from the three-router lab showing both the protocol stanza and the interface-level allowance required for adjacency on Junos.

junos

SSH archival transfer on commit

Source: ass_59_ssh_auto_save_to_server.json

system {
    services {
        ssh;
    }
    archival {
        configuration {
            transfer-on-commit;
            archive-sites {
                "scp://home@192.168.12.2:/home/home/Junos_Configs" password "[redacted]";
            }
        }
    }
}

security {
    ssh-known-hosts {
        host 192.168.12.2 {
            ecdsa-sha2-nistp256-key [redacted];
        }
    }
}

Taken from the router administration lab. Passwords and host keys are redacted, but the transfer-on-commit archival workflow is preserved.

junos

Junos local admin with SSH public-key authentication

Source: ass_59_ssh.json

system {
    login {
        user arvy {
            uid 2020;
            class super-user;
            authentication {
                encrypted-password "[redacted]";
                ssh-rsa [redacted];
            }
        }
    }
    services {
        ssh;
    }
}

security {
    zones {
        security-zone trust {
            interfaces {
                ge-0/0/1.0 {
                    host-inbound-traffic {
                        system-services {
                            ping;
                            ssh;
                        }
                    }
                }
                ge-0/0/2.0 {
                    host-inbound-traffic {
                        system-services {
                            ping;
                            ssh;
                        }
                    }
                }
            }
        }
    }
}

Taken from the SSH administration lab. It preserves the local-user, SSH service, and inbound-access structure while redacting password and key material.

More Projects

View all

Infrastructure Implementation

Virtual Machine Infrastructure Project

2023 ยท Dell PowerEdge T330, VMware ESXi 7, VMware vCenter

View project

Azure Administration & Cloud Operations

Azure Administration Lab Platform

2026 ยท Azure ARM Templates, Azure Bicep, RBAC

View project
Back to Projects