JuniperForum.com

Just add two members from each node to the reth interface........ You can also enable LACP if you need that.

And maybe You'll like this https://learningportal.juniper.net/juniper/user_activity_info.aspx?id=3310

If this guy is allways on the same IP or you can resolve his IP by DNS: Just add a rule higher up in the policy from trust to untrust. Then in advanced options set maximum bandwith.

Management services should be enabled on external interface for managment from outside. But then you also fill in permitted or also called manager-ip adresses, with tyour internal network and home IP address.

No, you have to disable that and probly renumber the vc member number to zero.

Log in to UNIX shell (start sh) and delete all config files from /config and /config/db/config (not sure about the latest location, on all junos it is /var/db/config. something else on EX. You can locate the fiel with find / "*config*" -print.

I wrote this on the subject:

Introduction.

A lot of engineers who switch from ScreenOS to JUNOS are missing the manager-ip functionality found in ScreenOS. This technote gives a similar functionality for a srx or J-series.

Solution.

The solution found here is described is many documents, but I tried to make a small summary. Look for “protecting the Routing Engine” when looking for background information.
 

The srx does not have the manager-ip build-in. Coming from the packetbased JUNOS version something came be build to achieve the same functionality. The core of this are stateless firewall filters. This filters can be applies to interface. But instead of applying it to all interface it’s applied between the PFE (packet forwarding engine) and the RE (Routing Engine). Consider that as at the point traffic enters the SRX itself instead of being forwarded. The to do this is to apply a filter to the loopback interface. The loopback stack is used in sending traffic from PFE to RE.
On packetbased JUNOS you have to write rather complex filters, but for the SRX most for the work is already done in zone or interface host-inbound-traffic settings.
The add-on to this filtering on prefixes.

The first step in the config is to create a list of networks (or hosts) allowed to manage. For this you can use a prefix-list:




policy-options {
    prefix-list manager-ip {
        10.0.0.0/8;
        192.168.4.254/32;
    }
}

This list is referenced in the actual filter, so this is where you can change your manager-ip’s!

The next step is to write a filter. On trick thing here is you have to include all your management services in the first rule! (Don’t forget NSM when you use it)

firewall {
    filter manager-ip {
        term block_non_manager {
            from {
                prefix-list {
                    manager-ip except;
                }
                protocol tcp;
                destination-port [ ssh https telnet http ];
            }
            then {
                reject;
            }
        }
        term accept_everything_else {
            then accept;
        }
    }
}

As you can see management traffic (when using a port listed in destination port) is rejected except when coming from an address listed in the prefixlist “manager-ip”.

Finaly we have to apply this filter to the loopback interface:

interfaces {
        lo0 {
        unit 0 {
            family inet {
                filter {
                    input manager-ip;
                }
            }
        }
    }
}

And don’t forget to commit confirmed when trying this on a remote system…….

You'll have to add the nam ports.

The NHTB can't be a problem I think. You can set a (fake if needed) next hop in the routing table. Then configure static NHTB entries on the tunnel interface. Same next-hop address and the correct vpn. In 6.2 you can just configure 2 phase 2's over the same phase 1. That should work as well.

That wouldn't work, because only the first policy would be hit. What comes to my mind using a vpn group. I never tried it myself but as long as the cisco supports ike heart beat it should work I think. Normally You would use it to move the von from one location to another, with the same addresses. I think the backup is kept inactive so this is what i suggest:

configure two vpn's on the the HO side to the remote location. Both have the same remote gateway ofcourse (the public address of the cisco). Enable ike heartbeat on them. place both vpn's in a vpn group. Or use DPD as failover method.

A description of VPN groups is here (page 309 and furher) http://www.juniper.net/techpubs/software/screenos/screenos6.2.0/ce_v5.pdf. Again: all theory, no guarantees (:-

I'm not sure you can configure the cisco to support this, same problem maybe, only the first VPN hits. Don't know enough about ios to advice you on this.

Please keep me posted, interesting problem!

Can you get the complete config? (get conf) and save it? If so reset the device to factory default (login on console woth the device serial number as username and the same serial number as password). Restore the config and set a new admin password.