• Welcome to Hurricane Electric's IPv6 Tunnel Broker Forums.

JUNOS IPv6 Tunnel - Multiple Virtual Routers

Started by RunningSecure, July 13, 2011, 01:15:41 AM

Previous topic - Next topic

RunningSecure

Hi all,

I am configuring a tunnel between a test SRX100 and HE, I am fairly sure I have the basics correct however my configuration on the SRX
includes multiple VRs. Here are the samples of my config:

ip-0/1/0 {
         unit 0 {
             tunnel {
                 source x.x.x.x;
                 destination 216.218.221.42;
             }
             family inet6 {
                 address 2001:470:35:313::2/64;

routing-options {
     rib inet6.0 {
         static {
             route ::/0 next-hop 2001:470:35:313::1;

forwarding-options {
         family {
             inet6 {
                 mode packet-based;


policy-options {
     policy-statement Untrust_to_Trust_Import {
         term Untrust_Route_Import {
             then accept;

routing-instances {
     Trust-VR {
         instance-type virtual-router;
         interface fe-0/0/1.0;
         interface st0.0;
         routing-options {
             static {
                 route 10.10.11.0/24 next-hop st0.0;
             }
             instance-import Untrust_to_Trust_Import;
         }
     }
     Untrust-VR {
         instance-type virtual-router;
         interface fe-0/0/0.0;
         routing-options {
             static {
                 route 0.0.0.0/0 next-hop x.x.x.x;

My issue is that I cannot route anything over the tunnel, when I try and ping the gateway at HE I get:

root# run ping 2001:470:35:313::1
PING6(56=40+8+8 bytes) :: --> 2001:470:35:313::1
ping: sendmsg: No route to host
ping6: wrote 2001:470:35:313::1 16 chars, ret=-1
ping: sendmsg: No route to host
ping6: wrote 2001:470:35:313::1 16 chars, ret=-1
ping: sendmsg: No route to host
ping6: wrote 2001:470:35:313::1 16 chars, ret=-1
^C
--- 2001:470:35:313::1 ping6 statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

I believe the issue is related to the routing tables and my VRs however I am still learning JUNOS and would greatly appreciate
assistance if there are any JUNOS techies that can assist.

cheers

maestroevolution

Hi Running,

The ip in ip interface on all J-series and SRX is ip-0/0/0.   The sample configuration is the sticky post is incorrect.  I sent a message to broquea about a year ago on that, but didn't get a response (nor did I follow-up)

If you run "show interfaces terse", you can see all the interfaces, both physical (fe-x/y/z) and virtual (ip-0/0/0).

My configuration is below for reference.  JunOS and IPv6 work fine in vrfs, although I'm not sure what you're trying to accomplish with your separation below.  (I recognize the ScreenOS names for the VRs, of course).

Also, while the sample configuration in the sticky post puts IPv6 into packet mode, this is not a requirement.  The SRX does stateful IPv6 since 10.2, with NATPT support added in 10.4.  For learning, it is easier to leave in packet-mode while you learn the IPv6 basics, but you can (and I do) treat IPv6 statefully.

Here's what my configuration looks like:

joel@chilis220> show configuration interfaces ip-0/0/0
unit 3 {
    description "IPv6 over v4 tunnel to Hurricane Electric";
    tunnel {
        source a.b.c.d;
        destination 209.51.181.2;
    }
    family inet6 {
        address 2001:470:1f10:xxxx::2/64;
    }
}

joel@chilis220> show route table inet6 protocol static

inet6.0: 27 destinations, 29 routes (26 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

::/0               *[Static/5] 2d 07:21:59
                    > to 2001:470:1f10:xxxx::1 via ip-0/0/0.3

Joel

maestroevolution

Also,

If you're running in a mixed firewall/packet mode, you will probably need the following:  this is a firewall filter that explicitly marks your ip-in-ip traffic as packet mode (as the outer packet is IPv4).

Replace the a.b.c.d with your public IP address and apply to your untrusted interface.  This is ge-0/0/7 on SRX.

joel@chilis220> show configuration interfaces ge-0/0/7   
unit 0 {
    description Comcast;
    family inet {
        filter {
            input fix-v6v4-tunnel;
        }
        dhcp {
            update-server;
        }
    }
}

joel@chilis220> show configuration firewall | find fix-v6
    filter fix-v6v4-tunnel {
        term one {
            from {
                destination-address {
                    a.b.c.d/32;
                }
                protocol 41;
            }
            then packet-mode;
        }
        term one.five {
            from {
                source-address {
                    a.b.c.d/32;
                }
                protocol 41;
            }
            then packet-mode;
        }
        term two {
            then accept;
        }
    }




RunningSecure

Hi,

Thank you for responding, splitting the VRs is simply something I have always done in ScreenOS to maintain security of routing table and give more flexibility when introducing routing protocols etc. As I am reasonably new to JUNOS I am taking the same concepts and applying, I really am just playing at the moment to see what I can and can't do compared to ScreenOS.

Will hopefully get some more time to play next week so will let you know how I get on.

cheers


maestroevolution

Hi @Running,

If you have ScreenOS expertise, you will be familiar with 90-95% of the features.

Zones, address-books, security policies, and screens are all the same.   Routing protocols / policy / etc are all JunOS

NAT is done differently, though, and IMHO this is a good thing.  NAT is done outside of the security policy, so 1) you always write security policy to the 'real' addresses, not a MIP/DIP/VIP etc.  In ScreenOS, it was always a pain in the butt to change a source nat dip pool, as it was tied to the policy, and you couldn't change it while any policies referenced it.

FYI: One restriction that JunOS has for IPSEC is that the ike interface must be in the main routing table (inet.0).  You can bind the st0 interface into any routing-instance you want, but the IKE endpoint must be in inet.0

This isn't related to IPv6, but I noticed that in the config you provided.

Thanks,

Joel