Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - screenie.

Pages: [1] 2 3 4 5 6 ... 66
Sorry, no. No LAG interfaces on ssg140. ISG....  Or swich to srx devices (:-

So wouldn't a mip from to on on sideand a MIP from to on the other side of the vpn work?

SRX Platform and J-series / Re: SRX NAT-T Issues
« on: September 15, 2012, 05:42:37 pm »
It should wotk I think, udp 4500 is the active port, so nat-traversal. Did you try a trace on ike ? set secuirty ike trace-options  etc .....

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

Routers / Re: Help meIn MX960, create gre interface but not present.
« on: September 13, 2012, 04:35:38 pm »
Is there a services pic installed in the chassis?

NetScreen and SSG/ISG Series Firewalls / Re: GRE Tunnel Configuration
« on: November 08, 2011, 06:07:16 am »
I would think (without trying) it should be something like this

set interface tunnel.2 ip x.x.x.x/30
set interface tunnel.2 tunnel encap gre
set interface tunnel.2 tunnel local-if trust dst-ip

With the tunnel on the cisco
abd then ofcourse a route to the destination with tunnel.2 as gateway.

I read somewhere in releasenotes the tunnel interface should be in the same zone as the endpoint interface, but can;t remember the details.

Routers / Re: Bandwidth Limit on trusted zone(ssg5)
« on: September 07, 2011, 09:04:12 am »
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.

I think ssh is frowarded by a VIP then. You can't enable ssh as a service and portforward it at the same time.

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.

Try reading this first. The vesion number is a guess of mine, latest for the 25 I think. After that maybe a more specific question and config would be hekpfull.

Switches / Re: Factory reseting EX4200 from CLI
« on: June 29, 2011, 05:34:18 pm »
No, you have to disable that and probly renumber the vc member number to zero.

Routers / Re: export route BGP by status neighbor?
« on: June 29, 2011, 06:47:24 am »
Don't think it can be done with policies. Look into eventscripting!.

Switches / Re: Factory reseting EX4200 from CLI
« on: June 29, 2011, 06:43:37 am »
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.

Switches / Re: EX4200 Virtual Chassis NIC teaming.
« on: June 06, 2011, 05:45:06 pm »
Thanks for a good post kshah! You're right to clearify this. Should have included this in my answer.

I wrote this on the subject:


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.


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 {;;

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 {
        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.

Did you configure static NHTB entries? If think creating two seperated tunnels can work, but use the same phase 1!

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.

I think the bigest problem is on the cisco side. Multple proxy id's will work I think. But does the cisco allows two vpn's to the same privater addresses?

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) 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!

Pages: [1] 2 3 4 5 6 ... 66