Fixing A Juniper Switch That Was Shut Down Improperly

Juniper switches need to be shut down properly, not just powered off. They’re Unix-based, and Unix does not like being shut down improperly.

Sometimes, SSH will also fail after an improper shutdown. When trying to SSH to the switch, you will see this:

Then you have two options: reboot the switch or restart SSH.

To restart SSH:

configure private
deactivate system services ssh
commit
rollback 1
commit

THIS DEVICE HAS BOOTED FROM THE BACKUP JUNOS IMAGE

August 14, 2018

login as: root
Using keyboard-interactive authentication.
Password:
Last login: Fri Jun 29 09:58:18 2018 from 83.244.171.242
— JUNOS 15.1X49-D45 built 2016-04-25 07:29:58 UTC

***********************************************************************
** **
** WARNING: THIS DEVICE HAS BOOTED FROM THE BACKUP JUNOS IMAGE **
** **
** It is possible that the primary copy of JUNOS failed to boot up **
** properly, and so this device has booted from the backup copy. **
** **
** Please re-install JUNOS to recover the primary copy in case **
** it has been corrupted and if auto-snapshot feature is not **
** enabled. **
** **
***********************************************************************

Partitions information:
Partition Size Mountpoint
s1a 2.4G /
s2a 2.4G altroot
s3e 185M /config
s3f 2.1G /var
s4a 224M recovery
s4e 15M

System going down IMMEDIATELY

TO UPDATE THE VERSION

Categorised as: Firewall, Juniper, SRX

Actually, you can.

You need to use adb. You can choose to adopt a whole SD card or just part of the SD card.

IMPORTANT: this procedure will wipe your SD card (backup!) and not all apps can be transferred to the adopted storage.

Assuming you already have adb installed (otherwise, use the Minimal ADB app on your PC: http://forum.xda-developers.com/showthread.php?t=2317790)

I recommend that you use the mixed adoptable storage for two reasons:

Source: Me. I’m running 6.0.1 on a Z3 with a 64GB SD card, 90:10 split (adopted:standard).

So, uranus is in pain once more. Power went out and it was not properly shut down before the UPS gave its last gasp (I do need to do something about that). When I rebooted it, it seemed to have come back without an issue — it was working fine — but it had The Light on again just like it was in last time. I ssh’d into it and this is what the motd looked like:

Hmmm, so the normal image (does that mean the entire OS partition or just the boot stuff?) got corrupted when power went bye-bye. Good thing it keeps a backup. Out of curiosity, let’s see if that is related to the LED being on:

It seems to be the case. Funny that it is labelled minor but important enough to become the motd, but I digress. Personally, we should take care of that as soon as we have a scheduled maintenance window.

Ok, maintenance window time. Before rebooting, let’s prepare a few things. If we know the backup copy is good (configuration files are also backed up, and you can push them back with ansible or whatnot if you feel uncomfortable), you could be lazy like me and copy the backup into the primary partition.

As you noticed, I did this a while ago but never got around to making an article about it, but there it is. However, I still had the evil LED staring at me. Time to turn it off

request system reboot media internal

So I rebooted and did not get that motd anymore not the LED:

Juniper SRX New DHCP Configuration for Home LAN

As I mentioned from my last post, I switched back from ASA5505 to SRX100H2. The reason I am posting this is for some reason, my SRX100 couldn’t receive a public IP address from my service provider. Somehow the newer way of configuring the SRX as a DHCP client works for my SRX to receive an IP from my ISP. At this point, I am not sure if this is a code related issue.

Just like I mentioned, I am only able to receive public IP from my ISP with the newer way of configuring the untrust interface as a DHCP client. Since my SRX is the DHCP server for my wired and wireless stations, I have to reconfigure my SRX’ DHCP server to get my home network functional again.

If you are using the typical DHCP client and server on your SRX, and everything works then keep it that way, but if you want to test or implement the newer way, keep reading.

Let’s start with the untrust interface. My untrust interface is fe-0/0/0 and this interface is the interface that is connected to the Internet. The typical and old way of configuring a DHCP client on the SRX interface is shown in Example 1

Example 1

set interfaces fe-0/0/0 unit 0 family inet dhcp update-server

Here is the compatible DHCP server shown in Example 2. Also, the command propagate-settings is optional. This is used if the name-server is not specified; therefore, the DHCP server will use the name server from the ISP. Otherwise, the name resolution will not work for the LAN.

Example 2

Also, the dhcp should be enabled under the security-zone on the interface level

Example 3

Since both DHCP client and server are compatible with each other, the SRX will not bark at you. However, if you happened to be using the old/typical DHCP server, and you configure your DHCP client interface with the newer way, your SRX will complain that the configuration is not compatible as shown in Example 4

Example 4

Here is another error on the interface level

Example 5

Unfortunately, you cannot have both configuration on the same box. Either you stay with the old/typical way of configuring DHCP or you switch to the newer way of configuring DHCP. I chose the latter.

To configure the newer way DHCP client, it is almost identical to the old way. However, all the old way DHCP config need to be remove first because if it is not the the system will complain again that it is not compatible with the newer config and you won’t be able to commit.

Example 6

Once the old way configs are gone, then we can proceed. To configure the newer way DHCP client, it is very similar to the older way.

Example 7

set interfaces fe-0/0/0.0 family inet dhcp-client update-server

Example 8

Now the DHCP group needs to be configured

Example 9

The last piece is allowing the SRX to receive a DHCP request from the hosts. This is done in security-zone interface level as shown in Example 10

Example 10

That is pretty much it. For verification, you can use the commands shown below. These commands are for the new way DHCP configs

show dhcp client binding
show dhcp client binding detail
show dhcp client statistics
show dhcp server binding
show dhcp server binding detail
show dhcp server statistics

For restating the services and renewing the DHCP client interface

request dhcp client renew interface fe-0/0/0    
restart dhcp gracefully
restart dhcp-service gracefully

I hope you will find this post helpful

OS Primary Partition Corruption

You will know when you have a switch that has been shut down improperly. There will be an amber light on the chassis, and this alarm on the console:

As well as this banner:

***********************************************************************
** **
** WARNING: THIS DEVICE HAS BOOTED FROM THE BACKUP JUNOS IMAGE **
** **
** It is possible that the primary copy of JUNOS failed to boot up **
** properly, and so this device has booted from the backup copy. **
** **
** Please re-install JUNOS to recover the primary copy in case **
** it has been corrupted. **
** **
***********************************************************************

When installing the OS, a Juniper device makes two copies of the OS. One is a backup, in case the primary was not unmounted cleanly at shutdown (or just powered off).

To copy the backup image over top of the primary image (you must type this; it will not tab-complete):

request system snapshot media internal slice alternate

Note that using this command will only repair the OS; it won’t clear the alarm.

Verify with the command:

show system storage partitions

You will get output like this:

Boot Media: internal (da0)
Active Partition: da0s1a
Backup Partition: da0s2a
Currently booted from: backup (da0s2a)

Note the «Currently booted from: backup» line.

Once the snapshot is done, the switch must be rebooted to clear the alarm. Normally, a Juniper will boot the last-known-good copy of the OS. It must be forced to use the primary.

request system reboot slice alternate media internal in 0

If that does not resolve it, try the reboot command again. For some reason, a second reboot sometimes solves it.

Full OS Reinstall

If it gets powered off improperly enough times, the primary and backup images will both be marked bad, and you will see this:

To reinstall the OS:

VMWare Fusion and Palto Alto VMs

Working with Palto Alto VMs is kind of annoying. Instead of it being ready to be deployed, you would have to do some extra work to get the interfaces working. What I mean by extra work, Palto Alto does not send or receive traffic by default. Probably because it is a trial version regardless it should not behave like that. We will get into that later on. Also, I think this only applies in VMWare Fusion. When you try to view your interfaces, it shows nothing.

In addition, some of the terminal short-cuts don’t work either such as ctrl+w

This post is about the resolution to the issues mentioned above.

So far, so good at this point. Now, for some reason the CLI is kind of a mess. What I mean by that, when you do any show or any commands that would populate the screen, the cursor will jump back several lines up which overlaps with the previous output. I don’t know if yours is the same as mine, but the work around or let’s say a bandaid that I found is by fixing the CLI height and width. The settings that works for me is height = 50, and width = 100

Now, that we got the CLI output fix, let’s get to the issue. As I mentioned at the beginning of this post. The VM does have some issues with its interfaces. It does not have any interfaces as you can see below:

If you power-on your VM, you won’t be able to fully boot it up. The reason is you added some devices in our case the two Network Adapters – see Figure 3 for error. To resolve this, we would need to modify the VM’s vmx file.

You would need to use any terminal text editor. Basically, you need to open the .vmx file, which can be found within the .vmwarevm file, via any text editor application, and modify the line that states ethernet2.virtualDev = “e1000” these lines can be found somewhere near the very bottom. The e1000 needs to be changed to vmxnet3. It should look like this ethernet2.virtualDev = “vmxnet3”

Use the show interface hardware command. This will show the MAC address of your interfaces. At this point, if you are using Fusion, the output is empty. You would need to manually add an interface by going to global config mode and use the command set network interface ethernet ethernet1/X (where X is the port number) then use the

If you compare the MAC addresses of  and ethernet1/X, they don’t match, and the traffic will not pass. The resolution to this issue is:

Login to the VM again, and use the commands show system state filter sys.s1.p*.hwaddr and show interface hardware. At this point, the MAC addresses should match with their appropriate port numbers, and networking part should also work.

OSX El Capitan and FTDI USB-to-serial adapter

This post is about fixing the USB-to-serial FTDI adapter on OSX 10.11. Since I upgraded to El Capitan 10.11, my USB-to-serial adapter had stopped working.

Before 10.11 (El Capitan), I didn’t have to download the driver to get my FTDI adapter to work. Unfortunately, now, I have to. I really don’t want to mess with the system to get a single USB adapter to work.

Download this driver

If you don’t see an entry that means that your system doesn’t see the adapter.

Hope you find this post helpful.

Palo Alto Firewalls HA Pair Upgrade

I upgraded my Palo Alto firewalls from version 6.1.12 to 7.1.1 recently. It is pretty much a straight forward upgrade but might as well write about it. Also, this is for the firewalls that do not have Internet access via their management (oob) interface.

The thing is when you upgrade, you would need to restart the firewall (just like any firewall) for the upgrade to take effect. The cool thing about the PAN, once you installed the base firmware, you can install the next version right away without restarting the firewall. This is only true if you’re going to the version that is on the same base firmware. Otherwise, you will need to restart the firewall.

You get the idea.

Before we begin, here are some recommended commands that need to be disabled when upgrading an HA pair. These commands are done in configuration mode.

Starting from here, all the commands below are done in operational mode.

Let’s get started. The first thing is ssh or console into the active device.You can do ssh or console into the passive device, but to test the failover, you would need to start at the active device. Once you are connected to the active device, the device needs to be suspended first. The device status will change from being active (or passive) to suspended as shown below

Once the firewall in suspended mode, you can import the firmware. In my case, it will import the 7.0.1 base firmware via scp. The command syntax is

Once the import is completed, the next step is to install the firmware.

Since I am upgrading to 7.1.1, and I just installed 7.0.1, I would need to restart the device.

Once the device boots up, check the software version

Once you confirmed the version, import the another base firmware

Then install the firmware after importing the base firmware. However, this time the syntax has changed. The file option is not available anymore.

Always check the status of the installation

At this point, since we are going to 7.1.1 and we just installed 7.1.0, we do not need to restart the device. We can install the 7.1.1 first then we can restart.

Once the installation is done, restart the device

Once the firewall restarted, the device will be stuck in . The reason is, the current active firewall version is in 6.1.12, and the upgraded firewall is on 7.1.1. The two version are not compatible with regards to high-availability pairing.

Let’s work with the second firewall. Here is a caveat. Since the newer version is not compatible, the one I upgraded will not become either active or passive until its pair gets to the compatible version.

Now, if you are upgrading this via SSH, I would highly recommend that keep the current active device as active because once you lost your connection, that device is not going to become active until you use the command request high-availability state functional. If you are connected via SSH, you won’t be able to execute this command. Therefore, we want the active firewall to boot up as an active device not suspended.

I am doing this via SSH, so I am not going to suspend the firewall. Just like the first firewall, I am going to import the firmware.

Once imported, install the firmware.

After the reboot, verify the version of the firmware

Now, import the base firmware then install it

Once the firmware is installed, do not restart the firewall yet. We will need to install the desire firmware. Import the firmware then install.

After it reboots, login again and check  the system software version

Also, login to both device and check if the device is in suspend mode. If either one of them is in suspended mode, then use this command

That should do it.

Juniper SRX Slow Internet Speed

Last year, I replaced my SRX100H2 with my old ASA5505 because it was really slow. It was so slow that a simple google search took a while to load up.

Here, a short back story. I was talking to Verizon rep to break my DHCP lease because my SRX was not receiving a public IP from Verizon. I was keeping an eye to debugs why my SRX was not receiving public IP then eventually it did received a public IP. I could not remember what was the problem with DHCP, though. When I thought I fixed the problem, another one just showed up. My Internet was really slow. Did some troubleshooting, checked my configs, reset to default, etc, but at the end of the day everything seems to be normal.

Eventually, I called Verizon again, and they said that everything seems to be fine on their end. At this point, I was lost. Instead of wasting time troubleshooting this, I reconfigured my ASA5505, and replaced my SRX100 with ASA5505. The ASA5505 didn’t have the slow speed like the SRX100. I thought to myself that my SRX100 must be faulty.

Now, back to present time. I still have my SRX and I still want to use it. I powered it on last night and plugged it in to my ASA5505. After a year, I haven’t given up with my SRX100, and probably never will. I like this firewall.

I woke up this morning with enough sleep, and motivated to fixed this firewall’s slow performance. And guess what, I found that I have an existing security flow traceoptions in the config.

I deleted the config

Then run the speed test again. Voila!!! The performance is back to normal again. So folks do not forget to delete your traceoptions after you troubleshoot your network/firewall issues.

Avoiding This Entirely

Just enable auto-snapshot. It will automatically repair any damaged files on the primary partition. Enabling will also repair anything that is currently damaged. It also sets the primary partition as the boot partition for the next reboot, so you don’t have to do that step of forcing it to boot from the repaired partition.

configure private
set system auto-snapshot
commit and-quit

Juniper SRX300 Layer 2 Issues

I am going to make this as short as possible. I purchased an SRX300 to replace my SRX100 firewall. The one I noticed right out of the box was each interface was in routed interface. Unlike the older branch models (SRX1xy, SRX2xy, etc) the ports were in switching mode.

Also, the JunOS version is at 15.1X49-D45 In my case, I need these ports to do switching and not routing. Therefore, I went ahead and modified my SRX100 config to match the new SRX300. When I commit, the box barked at me stating something along this lines.

from-zone (trust) and to-zone (untrust) must be both L2 or L3 zones.
error: configuration check-out failed

I had no idea what it meant, so I removed my security policies and tried to commit again then I got this. It makes sense because the newer boxes uses irb interfaces now instead of vlan.

error: l3-interface: ‘vlan.11’: Only IRB interface is supported, e.g. irb.10

I replaced all vlan interfaces with irb interfaces then commit check then I got this.

error: interface-unit: ‘irb.11’: This interface cannot be configured in a zone
error: statement creation failed: irb.11

At this point, I have no idea what was happening. The box is not letting me to commit. Therefore, I fired up Chrome and went to Juniper release notes page for the 15.1X49-D45 that I currently have. I scrolled down to page 10, the layer 2 features, and found this paragraphs.

Support forenhancedLayer2transparentbridgemodeandswitchingmode—Starting with Junos OS Release 15.1X49-D40, the enhanced Layer 2 transparent bridge mode and switching mode features are supported on SRX300, SRX320, SRX340, SRX345, and SRX550M devices.

NOTE:
• LACP is not supported on SRX300 and SRX320 devices.
• LACP is not supported in transparent bridge mode.

The command set protocols l2-learning global-mode switching is the answer to my problems. However, it does not support LACP. I checked the newer versions’ release notes, and found the newer JunOS version support LACP. I upgraded the SRX300 and used the mentioned command. Everything works.

Oh! Before I forget, the set protocols l2-learning global-mode  will require for you to reboot the SRX.

When you get this banner after logging into your Juniper device

***********************************************************************
** **
** WARNING: THIS DEVICE HAS BOOTED FROM THE BACKUP JUNOS IMAGE **
** **
** It is possible that the primary copy of JUNOS failed to boot up **
** properly, and so this device has booted from the backup copy. **
** **
** Please re-install JUNOS to recover the primary copy in case **
** it has been corrupted. **
** **
***********************************************************************

This simply means that the switch/firewall/router booted from the backup partition. It is very likely that the file system got corrupted because of power loss.
We can verify this by using some of the show commands.

To fix this, we would need to copy the Junos image from the backup partition to the primary and backup partitions.
To do so, use the command below: request system snapshot media internal slice alternate
The slice seems to be a hidden command; therefore, you would have to type it in manually.

Verify the snapshots

Then issue the command request system reboot slice alternate media internal. This will reboot from the primary partition.

Now, if you are upgrading your Junos device, and it keeps booting from the backup, use the command request system software rollback then reboot the system. Once it rebooted, you would be able to upgrade your device.

VMware Fusion 7 Pro to ESXi Host and vCenter

Alright, this is going to be a quick post. I have a micro server that I purchased back in 2014. This micro server is HP Proliant N54L. I have installed ESXi 5.1 on this server to host my servers, which I never used.

Anyways, I re-IP’d my network to make it more modular, and somehow, I forgot to put a default gateway to the ESXi host. This was during when I was troubleshooting my slow Internet speed on the SRX, re-configuring my ASA5505, etc.

When I connected to my network, I could not reach the ESXi host or my guest Windows VM. I could connect to it over layer2, but not layer3. I knew what was the problem, but I had more important things to do, so I put it on hold. I don’t really use Windows machine anymore except for work, so I do not have a Windows machine I can use open vSphere thick client.

After tickering around with VMware Fusion, I found out that that Fusion 7 Pro can console to the guest VMs hosted by my ESXi server. Apparently, this is only feasible with VMware Fusion 7 Pro and newer Pro versions of Fusion.

Once you’re able to logon then you will see your ESXi guest VMs in Fusion Virtual Machine Library window under the IP address or hostname of your ESXi as shown in Figure 3 and Figure 4. Once you are connected, you are able to access the VMs hosted on your ESXi host.

Hope you find this post helpful,

So here is the second part of dynamic VPN, but this is post will mainly for verification/troubleshooting. If you are looking for configuring the dynamic-vpn (remote access VPN), please check the part 1 of this post.

Verification

To verify and the remote client successfully VPN’d in to the SRX, use the command show security ike security-associations brief. You may see more than one entry here if you have some other ike traffic such as site-to-site VPN and/or another session from another dynamic-vpn.

The 3rd line with an index# of 4542718 can be ignored. This is for my site-to-site VPN, and not relevant to this post. Anyways, that one we are interested in is the last line with in index# 4542712. As you can see in Example 1, the state is “UP” and it shows the IP address of the remote client.

Another useful command can be use is show security ike active-peer

If everything works in phase 1, and still no connection, verify the phase 2. You can use show security ipsec inactive-tunnels. As you can see in Example 3, It displays the total inactive tunnels and errors.

To see the total active tunnels, use the command show security ipsec security-associations

The last one would be show security ipsec statistics, which gives you the number of ESP errors

Troubleshooting

This issue affects only branch SRX platforms and always occurs when Dynamic VPN is configured. This is a regression issue, it is introduced from 12.1X44-D55, 12.1X46-D40, 12.1X47-D30, 12.3X48-D20, and 15.1X49-D20.

These are the known working version 12.1X47-D35, 12.3X48-D25, 15.1X49-D30 according to Juniper’s problem report. Also, I have an older SRX100H and its code version is 12.1X46-D35, and dynamic-vpn is working with this code.

VPN connection is up. but no traffic is going through

Ensure the remote client receives an IP address from the SRX. If the remote client didn’t receive an IP address from the SRX, then check your configuration related to DHCP. YOu can use show configuration system services dhcp-local-server. Ensure that you have the interface for the dynamic vpn in a group.

Also, make sure that the dhcp is in the config under the security-zone interface level.

Lastly, the security policy should be in place. The from-zone should be the untrust and the to-zone should be the destination zone. And the permit statement should be sent to the ipsec tunnel.

You can also check if there is a traffic hitting the SRX. Use the command show security flow session

show log TSHOOT

Donations are always appreciated:

Any ERC-20 (tokens/coins): 0x9f337F9e0796eD3af5ccF0332674fD1eaDfA03BC

I have been really busy at work and personal stuff, and I have not posted any useful stuff lately. This post will be for a simple home Dynamic VPN or other vendors call it Remote Access VPN configuration.

Here is a simple topology

Juniper SRX firewalls comes with a dynamic VPN permanent license, but it is very limited. I have an SRX100 firewall, and it comes with 2 dynamic VPN license as shown in Example 1. The line that is highlighted is the license that comes with SRX100.

Now, before we jump into the configuration, you would need to download Junos Pulse (discontinued) or the Pulse Secure desktop client. For Linux desktop client, you can probably use this from Institute for Advanced Study. I have never tested this, so I can’t really comment on the Linux desktop client.

Unfortunately, if you are using a newer code (firmware) on the SRX the Windows’ desktop client is not available any longer, and if you try to navigate to , you will get the banner as shown in Figure 2

The dynamic VPN requires https service for it to work. If you use JWEB via https to configure your SRX then you can skip the Example 2. The interface fe-0/0/0.0 (untrust) is my interface to connected to the Internet. We would the https service enabled on the Internet facing interface since it is the receiving interface for the dynamic VPN.

set system services web-management https system-generated-certificate
set system services web-management https interface fe-0/0/0.0

Ensure that the untrust interface, in this case is fe-0/0/0.0, is accepting https and ike. This is done under the security-zone. I do not have a static IP address that is why I have dhcp added, but for what we are trying to accomplish here, what we need are just the ike and https.

set security zones security-zone untrust interfaces fe-0/0/0.0 host-inbound-traffic system-services dhcp
set security zones security-zone untrust interfaces fe-0/0/0.0 host-inbound-traffic system-services https
set security zones security-zone untrust interfaces fe-0/0/0.0 host-inbound-traffic system-services ike

We need to configure the IKE and IPSEC proposals for the dynamic VPN for IKE and IPSEC tunnel configuration.

Once you have prepared the ike and ipsec proposals, then you would need to configure the tunnel. The proposals you have created earlier will be linked to the policies. Also, I am using DDNS, so yours may be configure differently here if you have a static IP, but if you are using DDNS at your home then it should be the same.

set access address-assignment pool DYN-REMOTE-POOL family inet network 192.168.0.0/24
set access address-assignment pool DYN-REMOTE-POOL family inet range DYN-REMOTE-IP-RANGE low 192.168.0.100
set access address-assignment pool DYN-REMOTE-POOL family inet range DYN-REMOTE-IP-RANGE high 192.168.0.110
set access address-assignment pool DYN-REMOTE-POOL family inet xauth-attributes primary-dns 8.8.8.8/32

Configuring the dynamic VPN authentication, and the dhcp pool that was created above need to be link to this configuration.

Here is a caveat:
If your remote clients is going to be in the same pool as you internal clients, you would need to use the nat proxy-arp. This is only needed if one of the interfaces is directly connected to the SRX because the SRX would need to respond to the ARP requests by the clients. Otherwise, it is not needed.

set security nat proxy-arp interface fe-0/0/0.0 address 192.168.3.100 to 192.168.3.110

To enable split-tunneling, you would need to use the remote-exceptions. Therefore, all the traffic that is not destine to the IP or subnets specified in remote-protected-resources will be routed to the remote client’s local network (client’s router to the Internet, etc). In this example, any (0.0.0.0/0) traffic destination is not 192.168.0.0/24 or 192.168.1.100/32 will not be sent to the tunnel.

Now, to get the dynamic VPN working, a security policy is needed to allow the traffic coming from the Internet into your internal network. In this case, the destination is in the trust zone; therefore, the from-zone is untrust and the to-zone is trust.

set security policies from-zone untrust to-zone trust policy DYN-untrust_TO_trust description «TO ALLOW TRAFFIC FROM DYNAMIC VPN TO PASS TRAFFIC THROUGH»
set security policies from-zone untrust to-zone trust policy DYN-untrust_TO_trust match source-address any
set security policies from-zone untrust to-zone trust policy DYN-untrust_TO_trust match destination-address any
set security policies from-zone untrust to-zone trust policy DYN-untrust_TO_trust match application any
set security policies from-zone untrust to-zone trust policy DYN-untrust_TO_trust then permit tunnel ipsec-vpn IPSEC-DYN-VPN

set security zones security-zone DYN-VPN-ZONE interfaces vlan.9 host-inbound-traffic system-services dhcp

Once the DHCP has been added to the dynamic vpn interface under the security-zone, the SRX should respond to remote client(s)’ DHCP request.

In this post, if you have not noticed, I have the dynamic VPN interface on a different security-zone than the trust zone as shown in Figure 1 topology. So I have to create another security policy to allow traffic from the security-zone where the dynamic VPN interface is to the destination which is the trust zone.

Example 11

This post is getting longer, please see Part 2 for verification and troubleshooting.