SRX

 View Only
last person joined: yesterday 

Ask questions and share experiences about the SRX Series, vSRX, and cSRX.
Expand all | Collapse all

Make Vlan availible on low end Router

  • 1.  Make Vlan availible on low end Router

    Posted 08-29-2023 11:20

    Good day,

    We have a customer with and srx320.
    There is a ipsec tunnel to a 3th party connected to 1 vlan at the customers site. (other party simply have 1 route to that subnet)

    they have an external warehouse for 2 months. and need 1 wireless device to be connected to the 3th party.
    The problem is that the warehouse is really big. and running cables etc doesn't make sense for the 2 months.

    So our plan is to add a battery powered router with an 4G sim.  during lunch and night the battery will charge. 

    only problem is that the 3th party isn't really helpful. (they offered an $10K solution. and are disappointed that we don't want that)

    I was thinking. to use a Teltonika (aka openwrt) or an draytek or another cheap 4/5G router. to create a tunnel to the main office. 

    Only problem is that we need the wireless device to comminicate trough the local vlan.

    Juniper Supports Q-in-Q  Teltonika Supports EoIP Both should do the trick. but as far as i can see both brands don't support the same protocol.

    they both support GRE but i am not sure if that is going to help.

    Is it possible to let the wireless device > Teltonika > Ipsec > srx and then nat in the local vlan?

    does someone have an creative idea?



  • 2.  RE: Make Vlan availible on low end Router

    Posted 08-30-2023 01:40

    Hello Koos147,

    Can you convert this question into a basic network diagram of how you are planning to implement it?

    I am little fuzzy about the path & subnets you are trying to access. I am sure there is a way to do this.

    Thanks,




  • 3.  RE: Make Vlan availible on low end Router

    Posted 08-31-2023 08:16
    Hello TheDisciple,
    Your right. hope the simple drawing bellow makes it easier. 
    so there are 2 possible solutions.
    one is to extend the 192.168.10.x vlan to the Teltonika. this way the device exists in the correct vlan. 
    Another way is to assign the wireless device an 192.168.20.x ip. and route all its traffic to the Juniper. from here use nat to use an 192.168.10.x ip.
    We have the possibility to get an static public ip on the Teltonika. so that should be no problem.
    It is not possible to change the wireless device and run som sort of vpn on this device. 
    the wireless device uses an simple web application in the 192.168.0.x network. so speed isn't a thing here.
    if there is a better device to use. options are open. but we need to run it on battery's. device will sometimes loses power. so juniper isn't the right solution here. also the budget is tight. 



  • 4.  RE: Make Vlan availible on low end Router

    Posted 09-06-2023 00:50

    Hello Koos147,

    This sounds like a classic Hub-&-Spoke scenario with 2 spokes (read 2 tunnels) and a Hub.   

    If Teltonika can't do an IPSEC tunnel, then think of it as spoke with tunnel without encryption.

    GRE tunnel  is possible as long as you can reach SRX device over internet.

    The only challenge , I see is that GRE traffic is NOT encrypted.

    If security over internet is not a concern, then this solution works. Otherwise, you might need a VPN capable device in front of Teltonika to make GRE run over IPSEC.

    I would use some sort of NAT ( depending upon existing routing of the network but potentially a Static NAT) on SRX to make the traffic from Wireless device conform to the Traffic selector of your external partner.

    Hope it helps.

    Thanks! 




  • 5.  RE: Make Vlan availible on low end Router

    Posted 09-20-2023 06:09

    Good day,

    Today i am at the customers location.

    We have made the ipsec from Teltonika to SRX.
    as traffic selectors i added 
    192.168.20.0/24 > 192.168.10.0/24
    192.168.20.0/24 > 192.168.0.0/24

    I am able to ping devices in the head office location no problem
    on the srx i made the following policy's
    External > headoffice-lan
    External > 3th party vpn zone

    as expected there is no ping to 3th party
    so i added an source nat

        from zone external-location;
        to zone [ head-office-lan 3th-party-vpn ];
        rule scanner {
            match {
                source-address 192.168.20.0/24;
                destination-address [ 192.168.10.0/24 192.168.0.0/24 ];
            }
            then {
                source-nat {
                    pool {
                        Ip-in-head-office-lan;
                    }
                }
            }
        }
    } 

    but still no ping from the wireless devices.

    what am i missing?




  • 6.  RE: Make Vlan availible on low end Router

    Posted 09-22-2023 02:12

    Hello Koos147,

    There could be a few reasons for the Pings to fail :

    1. It may be that the traffic is not making into the tunnel between head-office-lan and 3rd-party vpn.
    2. There could be certain security policy mismatch etc. 

    I would start with a flow traceoptions on the head office to see what happens to the packet. Most likely it is a zone mismatch or something similar that can be addressed via some config manipulation.

    Hope this helps!




  • 7.  RE: Make Vlan availible on low end Router

    Posted 09-22-2023 08:12

    Thanks for pointing to the right direction.

    for what i understand the traffic never get translated. and therefore never matching the traffic selectors of the 3th party vpn.

    Sep 22 13:55:49 fwsrx320 clear-log[71004]: logfile cleared
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:~~~FLOW <192.168.20.254/19658->192.168.0.1/0;1,0x0> matched filter teltonika(0) in root-logical-system for iif st0.120 of root-logical-system:
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:   packet [84] ipid = 40966, @0x5ee78f48
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:---- flow_process_pkt: (thd 1): flow_ctxt type 1, common flag 0x0, mbuf 0x5ee78d00, rtbl_idx = 0
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:flow process pak, mbuf 0x5ee78d00, ifl 100, ctxt_type 1 inq type 6
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT: in_ifp <warehouse-vpn:st0.120>
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:flow_process_pkt_exception: setting rtt in lpak to 0x14452f98
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:flow_process_pkt_exception: setting in_vrf_id in lpak to 0, grp 0
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:host inq check inq_type 0x6
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:pkt out of tunnel.Proceed normally
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:  st0.120:192.168.20.254->192.168.0.1, icmp, (8/0)
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT: find flow: table 0x6c070a8, hash 7104(0xffff), sa 192.168.20.254, da 192.168.0.1, sp 19658, dp 0, proto 1, tok 21, conn-tag 0x00000000, vrf-grp-id 0
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:  no session found, start first path. in_tunnel - 0xb01f5a8, from_cp_flag - 0
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:  Not a traffic-selector enabled tunnel. returning EOK
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:  flow_first_create_session
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:Save init hash spu id 0 to nsp and nsp2!
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:First path alloc and instl pending session, natp=0x93124c8, id=231928236089
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:  flow_first_in_dst_nat: in <st0.120>, out <N/A> dst_adr 192.168.0.1, sp 19658, dp 0
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:  chose interface st0.120 as incoming nat if.
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:flow_first_rule_dst_xlate: DST no-xlate: 0.0.0.0(0) to 192.168.0.1(0)
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:[JSF] Do ingress interest check. regd ingress plugins(2)
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:get_tunnel_out_ha_ifp: use the cached out_ifp reth2.0 from tunnel 0x924c528
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:[JSF][0]plugins(0x0) enabled for session = 231928236089  implicit mask(0x0), service request(0x0)
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:-jsf : no plugin ingress interested for session 231928236089
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:flow_first_routing: vr_id 0, call flow_route_lookup(): src_ip 192.168.20.254, x_dst_ip 192.168.0.1, in ifp st0.120, out ifp N/A sp 19658, dp 0, ip_proto 1, tos 0
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:flow_first_routing: Doing DESTINATION addr route-lookup
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:flow_ipv4_rt_lkup success 192.168.0.1, iifl 0x64, oifl 0x61
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:flow_first_routing: setting out_vrf_id in lpak to 0, grp 0
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:  routed (x_dst_ip 192.168.0.1) from warehouse-vpn (st0.120 in 0) to st0.249, Next-hop: 192.168.0.1
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:Policy lkup: vsys 0 zone(21:warehouse-vpn) -> zone(16:3thparty-vpn) scope:0  src vrf (0) dsv vrf (0) scope:0
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:             192.168.20.254/2048 -> 192.168.0.1/54141 proto 1
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:flow_first_policy_search: policy search from zone warehouse-vpn-> zone 3thparty-vpn (0x0,0x4cca0000,0x0), result: 0x14db13d0, pending: 0?, is_http_cached = 0
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:flow_first_policy_search: dynapp_none_policy: TRUE, uc_none_policy: TRUE, is_final: 0x0, is_explicit: 0x0, policy_meta_data: 0x0
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:  app 0, timeout 60s, curr ageout 60s
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:  permitted by policy any(85)
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:  packet passed, Permitted by policy.
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:flow_first_policy_search:policy explicit matched or jdpi final matched, set session with dynamic_appid 0
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:flow_first_policy_search: Policy final match
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:  flow_conn_track_ent_lookup: zone connection track 0x10
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:flow_first_src_xlate:  nat_src_xlated: False, nat_src_xlate_failed: False
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:flow_first_src_xlate:  incoming src port is : 19658.
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:flow_first_src_xlate: src nat returns status: 0, rule/pool id: 0/0, pst_nat: False, nat_eim: False.
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:  dip id = 0/0, 192.168.20.254/19658->192.168.20.254/19658 protocol 0
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:Doing IPSec traffic-selector match for [Proto:1] 192.168.20.254/19658 -> 192.168.0.1/0
    
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT: get_nsp_tunnel - Tunnel not found. if st0.249, nexthop ip 0xaf9f801, policy id 85
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:  packet dropped, outgoing tunnel missing in tunnel-if
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT: outgoing tunnel missing in tunnel-if st0.249
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:flow_first_get_out_ifp: get tunnel_info failed!
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:flow_initiate_first_path: first pak no session
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:  flow find session returns error.
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:flow_proc_rc: -1.
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:flow_process_pkt_exception: Freeing lpak 0x2088d50 associated with mbuf 0x5ee78d00
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT: ---- flow_process_pkt rc 0x7 (fp rc 0)
    Sep 22 13:56:07 13:56:07.126038:CID-1:RT:jsf sess close notify
    Sep 22 13:56:07 13:56:07.126038:CID-1:RT:flow_ipv4_del_flow: sess 231928236089, in hash 32
    Sep 22 13:56:07 13:56:07.126038:CID-1:RT:ha_ifp: st0.249
    
    



  • 8.  RE: Make Vlan availible on low end Router

    Posted 09-22-2023 10:46

    Hello Koos147,

    It looks like there are 2 fold issues :

    1. The Source NAT did not occur because from-zone in Source NAT is written as "external-location" whereas flow trace shows that incoming st0 interface lies in  warehouse-vpn . Therefore, it does NOT match Source NAT.
    2. The destination route lookup for "192.168.0.1" is pointing to st0.249 which is NOT found. You need to ensure that this route is good.

    Hope this helps!




  • 9.  RE: Make Vlan availible on low end Router

    Posted 09-22-2023 11:40

    Hello TheDisciple,

    the zones names contains company names. so number 1 is lost in translation :) my bad.

    For point 2, the route from main office to 3th party is working fine for devices on main office.

    are you sure that it is possible to use nat for traffic comming from an ipsec tunnel?

    Thanks for your effort !




  • 10.  RE: Make Vlan availible on low end Router

    Posted 09-22-2023 12:46

    Hello Koos147,

    Yes, you can NAT traffic going into and coming from ipsec tunnel.

    If the tunnel between 3rd party and main office is working , is it also using st0.249 ? It will be strange if it works for other traffic but says tunnel not found for this particular traffic.

    I am assuming that your working tunnel between main office and 3rd party is operational bidirectional (i.e. traffic can be initiated from either side).

    Hope this helps!




  • 11.  RE: Make Vlan availible on low end Router

    Posted 09-25-2023 10:40

    Good day,

    The st0.249 interface is placed in the static route. so it is the same for local traffic as for remote traffic.

    i found that there is no traffic selector on our side. however the 3th party is using static routes to our site. so we can't add another subnet.

    the tunnel itself allows all traffic. access to resources on our network are limited by policies.




  • 12.  RE: Make Vlan availible on low end Router

    Posted 09-25-2023 11:46

    Hello Koos,

    Since there is no TS on our side , most likely there won't be a TS on the other end either. You can confirm it by looking into the output of "show security ipsec sa detail".

    e.g. 

    user@host> 

    show security ipsec security-associations detail

    ID: 131073 Virtual-system: root, VPN Name: ike-vpn
      Local Gateway: 10.62.1.3, Remote Gateway: 10.62.1.2
      Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0) <<<<<<
      Remote Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0) <<<<<

    Irrespective of use of TS, if you use of the Source IPs from the main office subnet , the traffic should be able to traverse the tunnel.

    Having said that, I would first fix the error seen in traceoptions 

    "

    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:Doing IPSec traffic-selector match for [Proto:1] 192.168.20.254/19658 -> 192.168.0.1/0
    
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT: get_nsp_tunnel - Tunnel not found. if st0.249, nexthop ip 0xaf9f801, policy id 85
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT:  packet dropped, outgoing tunnel missing in tunnel-if
    Sep 22 13:56:06 13:56:06.264920:CID-1:RT: outgoing tunnel missing in tunnel-if st0.249

    "

    Hope this helps!