SRX

Ok,   im quite new to junos, but i have a fair amount of experience with ScreenOS.

I am trying to build a vpn from a new SRX 240 to a SSG.

i used this tool to build the config

https://www.juniper.net/customers/support/configtools/vpnconfig.html

The very odd part is that i can only bring up the tunnel from fxp0 but not from the virtual-router interface reth1.0.  Let me elaborate.

So the tunnel builds from the SSG to 2.2.2.2 but not to 3.3.3.3 like i would want and expect it to.

is there something special i have to do with it being a virtual router?

       interfaces {

            fxp0 {

                unit 0 {

                    family inet {

                        address 2.2.2.2/27;

                    }

                }

            }

        }

reth1 {

    /* Made up of ge-0/0/4 & ge-5/0/4 */

    redundant-ether-options {

        redundancy-group 1;

    }

    unit 0 {

        family inet {

            address 3.3.3.3/28;

        }

    }

}

security {

... 

...       

        }

        gateway FW1XXX {

            ike-policy FW1XXX;

            address 10.10.10.1;

            no-nat-traversal;

            external-interface reth1.0;

Has you oppened the IKE System Service in the reth1 interface?

For IPsec to run on a "production interface" you need to assign it to a security zone and open the ike system service:

../..

security zones security-zone ABC {

   host-inbound-traffic {

      system-services {

         ike;

         }

     }

}

../..

Hi s24sean,

Currently in Junos st0.x interface must be placed in the inet.0 Virtual Router table in order to support point-to-multipoint VPN’s, where in ScreenOS tunnel interface placement did not matter for which VR it was placed in.

Best regards,

Igor

Hi s24sean,

As we don't have the st0 config in your case to see if it is p2p or p2mp, but I can see you are terminating the vpn on reth1.0 which is in a non inet.0 VR, here are more details about this:

Junos can only terminate a IPSec VPN on an interface in the inet.0 Virtual Router. So for instance, if you terminate a VPN on the interface ret1.0, then that interface must be in the inet.0 table. Note that you can still have the actual st0 interface (in the case of point-to-point route based VPN’s) in a non inet.0 VR, but the interface terminating the VPN must be in the inet.0 table for the VPN to terminate properly.

The st0.x interface should be in the inet.0 virtual router to be able to support point-to-multipoint route based VPN’s. If you place the st0 in a separate VR (regardless of what interface the interface the terminates the VPN is in) then you can only support point-to-point VPN’s on that tunnel.

Best regards,

Igor

s24sean,

To piggy-back on what Igor posted, we do have a KB article that identifies a work-around:

KB12866 - Terminate an IPSec VPN tunnel when the external interface belongs to a routing instance

I'll also file a bug with the VPN Configuration tool to add a warning or condition for this case.

Thank you for bringing it to our attention.

Regards,

Josine

s24sean,

Unfortunately, the work-around that I referred to in KB12866 has been removed.  We added the following note:

NOTE:  Previously a work-around solution was provided in this KB article. However the Juniper Networks Engineering team found some serious limitations with the work-around solution. Hence we are no longer supporting the work-around solution.  Juniper is continuing to work on a more robust implementation for an upcoming future JUNOS release. Please contact your Juniper Sales Representative for information regarding the feature roadmap for this feature.

We apologize for the inconvenience.

Regards,

Josine

Does anybody know when/if it will be possible to build ipsec vpn from a virtual-router routing-instance? It´s a function we use alot on our ScreenOS-platforms whitch we plan to migrate to Junos-platforms. All depends on this function.

Regards

Patrik Karlsson

Hi,

I heard that it is possible to put the interface (where IKE terminates) into a routing instance other than inet.0 when running the latest releases. Anybody who can confirm this?

Z.

Anyone have any luck on this?  It appears that the phase 1 SA is attempted, but there isn't ever a responder. Here's what have been using on 10.1r3.7, but no luck:

interfaces {
    ge-0/0/0 {
        unit 0 {
            family inet {
                address 1.1.1.1/30;
            }
        }
    }
    ge-0/0/1 {
        unit 0 {
            family inet {
                address 10.0.0.254/24;
            }
        }
    }
    st0 {
        unit 0 {
            family inet {
                address 10.255.255.1/30;
            }
        }
    }
}
routing-options {
    interface-routes {
        rib-group inet guestwifi;
    }
    static {
        route 0.0.0.0/0 next-hop st0.0;
    }
    rib-groups {
        guestwifi {
            import-rib [ inet.0 guestwifi.inet.0 ];
        }
    }
}
protocols {
    ospf {
        area 0.0.0.0 {
            interface st0.0;
            interface ge-0/0/1.0;
        }
    }
}
security {
    ike {
        traceoptions {
            file kmd;
            flag all;
        }
        policy test-pol {
            mode main;
            proposal-set standard;
            pre-shared-key ascii-text "$9$k.Tzn/CuBI6/vWX7VbTzF3tuSrev8XIR"; ## SECRET-DATA
        }
        gateway test-gate {
            ike-policy test-pol;
            address 1.1.1.2;
            local-identity inet 1.1.1.1;
            external-interface ge-0/0/0;
        }
    }
    ipsec {
        traceoptions {
            flag all;
        }
        policy test-policy {
            proposal-set standard;
        }
        vpn test-vpn {
            bind-interface st0.0;
            ike {
                gateway test-gate;
                ipsec-policy test-policy;
            }
            establish-tunnels immediately;
        }
    }
    nat {
        source {
            rule-set TRUST-UNTRUST {
                from zone TRUST;
                to zone UNTRUST;
                rule 1 {
                    match {
                        source-address 0.0.0.0/0;
                        destination-address 0.0.0.0/0;
                    }
                    then {
                        source-nat {
                            interface;
                        }
                    }
                }
            }
        }
    }
    zones {
        security-zone TRUST {
            host-inbound-traffic {
                system-services {
                    all;
                }
                protocols {
                    all;
                }
            }
            interfaces {
                ge-0/0/1.0;
                st0.0;
            }
        }
        security-zone UNTRUST {
            host-inbound-traffic {
                system-services {
                    ike;
                    ping;
                }
            }
            interfaces {
                ge-0/0/0.0;
            }
        }
    }
    policies {
        from-zone TRUST to-zone TRUST {
            policy 1 {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
        from-zone TRUST to-zone UNTRUST {
            policy 1 {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
    }
    flow {
        traceoptions {
            file debug;
            flag basic-datapath;
            packet-filter 1 {
                source-prefix 10.255.255.0/24;
                destination-prefix 0.0.0.0/0;
            }
            packet-filter 2 {
                source-prefix 1.1.1.0/30;
                destination-prefix 1.1.1.0/30;
            }
            packet-filter 3 {
                source-prefix 0.0.0.0/0;
                destination-prefix 10.255.255.0/24;
            }
        }
    }
}
routing-instances {
    guestwifi {
        instance-type virtual-router;
        interface ge-0/0/0.0;
    }
}

interfaces {
    ge-0/0/0 {
        unit 0 {
            family inet {
                address 1.1.1.2/30;
            }
        }
    }
    ge-0/0/1 {
        unit 0 {
            family inet {
                address 10.0.1.254/24;
            }
        }
    }
    st0 {
        unit 0 {
            family inet {
                address 10.255.255.2/30;
            }
        }
    }
}
routing-options {
    interface-routes {
        rib-group inet guestwifi;
    }
    rib-groups {
        guestwifi {
            import-rib [ inet.0 guestwifi.inet.0 ];
        }
    }
}
protocols {
    ospf {
        area 0.0.0.0 {
            interface st0.0;
            interface ge-0/0/1.0;
        }
    }
}
security {
    ike {
        traceoptions {
            file kmd;
            flag all;
        }
        policy test-pol {
            mode main;
            proposal-set standard;
            pre-shared-key ascii-text "$9$-eV24JGDkmfZGCt0BEh24oaikFn/Cp0f5"; ## SECRET-DATA
        }
        gateway test-gate {
            ike-policy test-pol;
            address 1.1.1.1;
            local-identity inet 1.1.1.2;
            external-interface ge-0/0/0;
        }
    }
    ipsec {
        traceoptions {
            flag all;
        }
        policy test-policy {
            proposal-set standard;
        }
        vpn test-vpn {
            bind-interface st0.0;
            ike {
                gateway test-gate;
                ipsec-policy test-policy;
            }
            establish-tunnels immediately;
        }
    }
    nat {
        source {
            rule-set TRUST-UNTRUST {
                from zone TRUST;
                to zone UNTRUST;
                rule 1 {
                    match {
                        source-address 0.0.0.0/0;
                        destination-address 0.0.0.0/0;
                    }
                    then {
                        source-nat {
                            interface;
                        }
                    }
                }
            }
        }
    }
    zones {
        security-zone TRUST {
            host-inbound-traffic {
                system-services {
                    all;
                }
                protocols {
                    all;
                }
            }
            interfaces {
                ge-0/0/1.0;
                st0.0;
            }
        }
        security-zone UNTRUST {
            host-inbound-traffic {
                system-services {
                    ike;
                    ping;
                }
            }
            interfaces {
                ge-0/0/0.0;
            }
        }
    }
    policies {
        from-zone TRUST to-zone TRUST {
            policy 1 {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
        from-zone TRUST to-zone UNTRUST {
            policy 1 {
                match {
                    source-address any;
                    destination-address any;
                    application any;
                }
                then {
                    permit;
                }
            }
        }
    }
    flow {
        traceoptions {
            file debug;
            flag basic-datapath;
        }
    }
}
routing-instances {
    guestwifi {
        instance-type virtual-router;
        interface ge-0/0/0.0;
    }
}

HI there

Actually you are terminating the external interface for the ike GW in a routing-instance. Unfortunately, that is currently not supported.

You can however terminate the tunnel interface in routing instance and I believe there is some limited support for that since 10.0R3 onwards.

Please try with just the st interface in routing-instance and ge-0/0/0 will still need to be in inet.0 for VPN to work.

Junos 11.1 makes it possible to terminate an IKE session in a routing-instance

Hi !

I'm interested by this topic, as I need to establish IKE/IPSEC tunnels in a virtual routing instance (VR).

* Node: SRX 240H

* JunOS version: 11.4R4.4

* firewall running in a active/standby Cluster

1) I need to know if it is possible to establish IKE/IPSEC tunnels in a virtual routing instance (VR), using Policy-based IPSec VPN, with reth interfaces in the VR ?

Using reth (reth.x as vlan will be used) interfaces is different than the configuration example given in KB1423. So, I prefer to ask.

2) By the way, all my Security Zones (named Green and Blue in KB1423) will share the same virtual routing instance: in that case, is it necessary to use rib-groups ?

Thanks,

Estelle

This issue has been resolve witht the release of junos 11.1 and later . Please refer the KB ,: http://kb.juniper.net/InfoCenter/index?page=content&id=KB21487