vSRX

  • 1.  request advice - vSRX test ipv6 tunnel using Hurricane Electric tunnelbroker

    Posted 12-13-2020 12:53
    Hello, for a lab network trial, I have an operational vSRX (v3, 20.3R1.8) in a NAT configuration behind a ISP gateway. I can do all IPv4 stuff fine. Only default routing instance. I wanted to test an IPv6 tunnel using Hurricane Electric's TunnelBroker service. The configuration at Hurricane Electric suggests the following configuration - for a JunOS device with no explanation. I'm trying to learn the steps required  vSRX configuration process. Perhaps at the  end of the process I will write up a tutorial for helping others!

    1. Can I just implement the required new interfaces or do I have to also add in the security-zone  assignment/information for those interfaces? 
    2. Any current tutorials available with a SRX or vSRX and HE tunnel broker?
    3. I've got a DDNS service name from a separate device that always tracks the public facing WAN ip address. Is it useful in this configuration? 
    4. In the code snippet below an IP address shown is my WAN ip address (does it have to be numeric, or can this be a DNS name that is resolved? 
    5. How would I test this tunnel in steps? I'm looking for a reference somewhere that I could follow, or do I use a external service to test to my IPv6 internal network? 

    Tunnel details:
    IPv6 Tunnel Endpoints
    Server IPv4 Address:216.66.22.2
    Server IPv6 Address:2001:470:7:349::1/64
    Client IPv4 Address:69.250.211.88
    Client IPv6 Address:2001:470:7:349::2/64
    Routed IPv6 Prefixes
    Routed /64:2001:470:8:34a::/64
    Routed /48:Assign /48​


    Thank you
    S. Haque

    The following is a temporary tunnel for testing. 
    interfaces {
    	ip-0/1/0 {
    		unit 0 {
    			tunnel {
    				source 69.250.211.88;
    				destination 216.66.22.2;
    			}
    			family inet6 {
    				address 2001:470:7:349::2/64;
    			}
    		}
    	}
    }
    routing-options {
    	rib inet6.0 {
    		static {
    			route ::/0 next-hop 2001:470:7:349::1;
    		}
    	}
    }
    forwarding-options {
    	family {
    		inet6 {
    			mode packet-based;
    		}
    	}
    }​





  • 2.  RE: request advice - vSRX test ipv6 tunnel using Hurricane Electric tunnelbroker

     
    Posted 12-14-2020 19:27
    Good day, S Haque!

    I'm working on something similar with a physical SRX.

    1. Can I just implement the required new interfaces or do I have to also add in the security-zone  assignment/information for those interfaces? <MS>Yes to the required new interfaces, but no to the security pieces based on the 'mode packet-based' in HE's config stanza.  That command tells the vSRX to treat ipv6 traffic in a stateless manner.</MS>
    2. Any current tutorials available with a SRX or vSRX and HE tunnel broker? <MS>I have not found any, but the video tutorials on HE's site are pretty nice.</MS>
    3. I've got a DDNS service name from a separate device that always tracks the public facing WAN ip address. Is it useful in this configuration? <MS>I believe so based on the video tutorials on HE's site.</MS>
    4. In the code snippet below an IP address shown is my WAN ip address (does it have to be numeric, or can this be a DNS name that is resolved? <MS>At this time, it has to be numeric, but I may misunderstand your question.</MS>
    5. How would I test this tunnel in steps? I'm looking for a reference somewhere that I could follow, or do I use a external service to test to my IPv6 internal network? <MS>I would check out these videos https://ipv6.he.net/presentations.php One of the verification tests is 'ping inet6 ipv6.google.com'</MS>

    Finally, the config they provided is older.  The forwarding-options statement is actually under 'security' now, so 'set security forwarding-options family...'

    Good luck on your endeavors.  Cheers!


  • 3.  RE: request advice - vSRX test ipv6 tunnel using Hurricane Electric tunnelbroker

    Posted 12-14-2020 22:44
    Hello MS, I was able to make progress on my vSRX configuration
    1. Interfaces: fxp0.0 (management), ge-0/0/0.0 (trust), ge-0/0/1.0 (untrust), ip-0/0/0.0 (IP-IP tunnel)
    2. IPv4 NAT from trust to untrust interface
    3. IPv4 and IPv6 addresses on trust interface
    4. IPv4 address on untrust interface
    5. untrust interface is on the LAN side of a residential CATV ISP router. This router has dynamic WAN.
    The tunnel is formed here A.B.C.D is the ISP tunnel side IPv4 address, and E.F.G.H is the local, interior, LAN side IPv4 address of the residential ISP CATV modem/gateway -- not the dynamic WAN address. There is a NAT process from E.F.G.H to the outside world. Thus the tunnel is formed as shown below.
    ttadmin@r5> show interfaces ip-0/0/0.0 detail
      Logical interface ip-0/0/0.0 (Index 73) (SNMP ifIndex 522) (Generation 138)
        Flags: Up Point-To-Point SNMP-Traps 0x4000 IP-Header A.B.C.D:E.F.G.H:4:df:64:00000000 Encapsulation: IPIP-NULL
    ​

    As routing is setup to direct all IPv6 traffic out to the far side of the tunnel, I can ping from the console session to anywhere:

    ttadmin@r5> ping www.google.com
    PING6(56=40+8+8 bytes) [...]::2 --> 2607:f8b0:4004:809::2004
    16 bytes from 2607:f8b0:4004:809::2004, icmp_seq=0 hlim=121 time=56.258 ms
    16 bytes from 2607:f8b0:4004:809::2004, icmp_seq=1 hlim=121 time=31.803 ms
    16 bytes from 2607:f8b0:4004:809::2004, icmp_seq=2 hlim=121 time=15.684 ms
    16 bytes from 2607:f8b0:4004:809::2004, icmp_seq=3 hlim=121 time=13.955 ms
    ^C
    --- www.google.com ping6 statistics ---
    4 packets transmitted, 4 packets received, 0% packet loss
    round-trip min/avg/max/std-dev = 13.955/29.425/56.258/16.984 ms
    
    ttadmin@r5> traceroute www.google.com
    traceroute6 to www.google.com (2607:f8b0:4004:809::2004) from [...]::2, 64 hops max, 12 byte packets
     1  tunnel578589.tunnel.tserv13.ash1.ipv6.he.net ([...]::1)  25.262 ms  23.094 ms  15.837 ms
     2  10ge2-2.core1.ash1.he.net (2001:470:0:90::1)  15.737 ms  14.633 ms  16.457 ms
     3  pr61.iad07.net.google.com (2001:504:0:2:0:1:5169:1)  19.061 ms  19.412 ms  16.341 ms
     4  2001:4860:0:1098::1 (2001:4860:0:1098::1)  15.943 ms  14.772 ms  24.678 ms
     5  * * *
     6  iad23s61-in-x04.1e100.net (2607:f8b0:4004:809::2004)  17.526 ms  20.924 ms  13.822 ms
    ​


    But I am unable to ping from the ISP to the either of a local side of the tunnel (::2) or from that ISP host to a neighbor router that is using the prefix with EUI-64 /64 address. But from the system itself  I can ping (ipv6) between both machines just fine, and IPv6 neighbor discovery is active.

    What I am thinking is that my security policies are the culprit., and request your help in a simple review. Where can I adapt the security policies that would allow (untrust -> trust pings) and (untrust -> trust) user traffic? Currently, I am a bit confused  - is the configuration below (default config) locked down tight from untrust -> trust due to the default_deny option? Ok, so perhaps this is a place to provide exceptions. how granular should the exceptions be? host by host/protocol/ports? 

    But what is preventing basic pings from the other side of the tunnel to at least hit the local side of the tunnel and the system to respond?   Any tips on how to trace this behavior  using a monitoring session? 

    EDIT #2: I think this is a useful  way to test (off-line): that is giving me a clue. Here is my finding:
    ttadmin@r5> show security match-policies from-zone untrust to-zone trust source-ip 2001:470:7:349::1 destination-ip 2001:470:7:349::2 protocol icmp6 destination-port 12345 source-port 2048
    Policy: DEFAULT_DENY, action-type: deny, State: enabled, Index: 9
    0
      Policy Type: Configured
      Sequence number: 1
      From zone: untrust, To zone: trust
      Source vrf group:
        any
      Destination vrf group:
        any
      Source addresses:
        any-ipv4(global): 0.0.0.0/0
        any-ipv6(global): ::/0
      Destination addresses:
        any-ipv4(global): 0.0.0.0/0
        any-ipv6(global): ::/0
      Application: any
        IP protocol: 0, ALG: 0, Inactivity timeout: 0
          Source port range: [0-0]
          Destination ports: [0-0]
      Per policy TCP Options: SYN check: No, SEQ check: No, Window scale: No
    ​


    Thanks ! my earlier configuration is below for reference to the current discussion. 

    version 20.3R1.8;
    
    
    [....]
    
    security {
        forwarding-options {
            family {
                inet6 {
                    mode flow-based;
                }
            }
        }
        screen {
            ids-option untrust-screen {
                icmp {
                    ping-death;
                }
                ip {
                    source-route-option;
                    tear-drop;
                }
                tcp {
                    syn-flood {
                        alarm-threshold 1024;
                        attack-threshold 200;
                        source-threshold 1024;
                        destination-threshold 2048;
                        queue-size 2000; ## Warning: 'queue-size' is deprecated
                        timeout 20;
                    }
                    land;
                }
            }
        }
        nat {
            source {
                rule-set source_nat {
                    from zone trust;
                    to zone untrust;
                    rule nat1 {
                        match {
                            source-address 0.0.0.0/0;
                        }
                        then {
                            source-nat {
                                interface;
                            }
                        }
                    }
                }
            }
        }
        policies {
            from-zone trust to-zone trust {
                policy default-permit {
                    match {
                        source-address any;
                        destination-address any;
                        application any;
                    }
                    then {
                        permit;
                    }
                }
            }
            from-zone trust to-zone untrust {
                policy default-permit {
                    match {
                        source-address any;
                        destination-address any;
                        application any;
                    }
                    then {
                        permit;
                    }
                }
            }
            from-zone untrust to-zone trust {
                policy default_deny {
                    match {
                        source-address any;
                        destination-address any;
                        application any;
                    }
                    then {
                        deny;
                    }
                }
            }
            pre-id-default-policy {
                then {
                    log {
                        session-close;
                    }
                }
            }
        }
        zones {
            security-zone trust {
                tcp-rst;
                interfaces {
                    ge-0/0/0.0 {
                        host-inbound-traffic {
                            system-services {
                                all;
                            }
                            protocols {
                                all;
                            }
                        }
                    }
                }
            }
            security-zone untrust {
                screen untrust-screen;
                interfaces {
                    ge-0/0/1.0 {
                        host-inbound-traffic {
                            system-services {
                                ntp;
                                ping;
                                traceroute;
                            }
                        }
                    }
                    ip-0/0/0.0 {
                        host-inbound-traffic {
                            system-services {
                                ping;
                            }
                        }
                    }
                }
            }
        }
    }
    
    [...]
    interfaces {
        ge-0/0/0 [...]
        ip-0/0/0 [...]
        ge-0/0/1 [...]
        fxp0 [...]
        lo0 [...]
    }
    protocols {
        router-advertisement {
            interface ge-0/0/0.0 {
                prefix [...];
            }
        }
        vrrp {
            traceoptions {
                file vrrp-log size 1m;
                flag packets;
            }
        }
    }
    routing-options {
        rib inet6.0 {
            static {
                route ::/0 next-hop [...];
            }
        }
        static {
            route 0.0.0.0/0 next-hop [...];
        }
    }​