I have a VPN connection to a remote site and whenever nothing is plugged into the remote sites LAN bgroup the interface IP isn't managable or pingable.

Anyone know what command I skipped on CLI for setting this up? Or if there is a checkbox on the web interface I should go hit?

  • The end result was using a loopback interface as a VIP for the device and NAT'ing everything behind it so that the 400+ sites all have identical configuration for when they call into the help desk. Up voting all answers that were informative and accepting the most thorough. Thanks all – sclarson Jun 23 '09 at 13:39

The correct answer is to create a loopback interface. When nothing is plugged into the LAN bgroup, the interface goes "down", and all routes associated with it are removed from the routing table. That's a behavior you want, actually, as it helps when using route-based redundant VPNs - it's the only way for a device to know "that tunnel is down and I should now route to over here".

Okay, so what you do is:

  • In your vrouter - likely the trust-vr - check the option to "Ignore Subnet Conflict for Interfaces in This VRouter"
  • Create a new loopback.1 interface
  • Give it the last address in your LAN bgroup space, with a /32 netmask. E.g., if your LAN bgroup has, loopback.1 would be Analogous for smaller net spaces.
  • Make sure your DHCP server on that bgroup does not include the loopback interface's address in its IP pool(s).

Now you can manage the unit using that loopback IP address, which will always remain reachable; and you did not have to carve out additional address space to do that.

Ensuring that a tunnel remains "up" is an entirely different concern. In ScreenOS, this can be accomplished with the "monitor rekey" option (and "optimized" for good measure if you want to, with a specific destination IP and source port if the outside isn't pingable, and possibly with an interval of 5 instead of 1 if the lines you go over are residential ISPs). That has nothing to do with being able to manage, however. It can give you good indication and advance warning of VPN failure, if you configure a server that receives logs and sends out notifications to staff on "VPN Down". It also has the risk of making your VPNs "flap" if you misconfigure - that is, if the address that Monitor is pinging cannot, actually, be pinged, or if the interval is too aggressive for the quality / latency of your ISP connection(s). That can be handled by, for example, pinging said loopback address through the tunnel: You won't be relying on the external address being reachable to ping.


On your Phase 2 setting for the VPN (AutoKey IKE), click on the Advanced button, and then turn on (check) VPN Monitor and Rekey. This will open up the tunnel if the keys expire or if the connection drops for some reason. We use this for our remote users who often turn off all of the connected equipment. This way we still have the ability to reach the remote Netscreen even if there is no traffic on the VPN.

alt text


Try creating a loopback interface and connecting the tunnel to that.

If this is a policy based VPN tunnel and all of the clients are down, then there may not be enough 'interesting' traffic to keep the tunnel up. There may be a timer to extend (perhaps to infinity) this timeout to prevent this from happening.


Well, without knowing much about your setup (it would be good to know if it is route vs. policy based, etc) you need to keep in mind that ScreenOS usually requires traffic routed or forwarded by policy into the tunnel to initiate the tunnel or keep the tunnel up. So, if you have no traffic going into the tunnel the tunnel will not stay up. This sounds like your issue. However, there are several command line options to tweak the way your tunnels behave. Try Chapter 10 in the Oreilly ScreenOS Cookbook or downloading the ScreenOS "Concepts & Examples Guide". This is a pretty hefty PDF available from the Juniper website, but it is also broken up into multiple volumes. Try looking at volume 5: Virtual Private Networks, Advanced Virtual Private Network Features. Pay specific attention to an option called "VPN Monitoring", using "set vpn monitor rekey" should help to keep the tunnel active in different cases, but be sure to read up. Also, if you want to go a little farther you could examine DPD (Dead-peer Detection) on newer versions of code.

  • The tunnel is staying active from keep alives, its just the interface on the remote end that disables. Really its just an issue of keeping the interface up without a connection up. This won't be an issue when sites are live, just an issue with monitoring vpn stability between the time a location first is installed and when people actually start using the an office. – sclarson May 18 '09 at 15:56
  • Is the interface attached to a single host PC? If so, connecting it to a switchport should solve this problem. – Peter Jun 1 '09 at 16:06

I don't think you can. The IP interface is dependant on the physical interface (or bgroup) because of the routing table. So if the physical interface is down, the router assumes that the entire network, including itself, is unreachable.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.