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).
Original Message:
Sent: 09-22-2023 11:39
From: Koos147
Subject: Make Vlan availible on low end Router
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 !
Original Message:
Sent: 09-22-2023 10:46
From: TheDisciple
Subject: Make Vlan availible on low end Router
Hello Koos147,
It looks like there are 2 fold issues :
- 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.
- 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!
Original Message:
Sent: 09-22-2023 08:11
From: Koos147
Subject: Make Vlan availible on low end Router
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 clearedSep 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, @0x5ee78f48Sep 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 = 0Sep 22 13:56:06 13:56:06.264920:CID-1:RT:flow process pak, mbuf 0x5ee78d00, ifl 100, ctxt_type 1 inq type 6Sep 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 0x14452f98Sep 22 13:56:06 13:56:06.264920:CID-1:RT:flow_process_pkt_exception: setting in_vrf_id in lpak to 0, grp 0Sep 22 13:56:06 13:56:06.264920:CID-1:RT:host inq check inq_type 0x6Sep 22 13:56:06 13:56:06.264920:CID-1:RT:pkt out of tunnel.Proceed normallySep 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 0Sep 22 13:56:06 13:56:06.264920:CID-1:RT: no session found, start first path. in_tunnel - 0xb01f5a8, from_cp_flag - 0Sep 22 13:56:06 13:56:06.264920:CID-1:RT: Not a traffic-selector enabled tunnel. returning EOKSep 22 13:56:06 13:56:06.264920:CID-1:RT: flow_first_create_sessionSep 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=231928236089Sep 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 0Sep 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 0x924c528Sep 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 231928236089Sep 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 0Sep 22 13:56:06 13:56:06.264920:CID-1:RT:flow_first_routing: Doing DESTINATION addr route-lookupSep 22 13:56:06 13:56:06.264920:CID-1:RT:flow_ipv4_rt_lkup success 192.168.0.1, iifl 0x64, oifl 0x61Sep 22 13:56:06 13:56:06.264920:CID-1:RT:flow_first_routing: setting out_vrf_id in lpak to 0, grp 0Sep 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.1Sep 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:0Sep 22 13:56:06 13:56:06.264920:CID-1:RT: 192.168.20.254/2048 -> 192.168.0.1/54141 proto 1Sep 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 = 0Sep 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: 0x0Sep 22 13:56:06 13:56:06.264920:CID-1:RT: app 0, timeout 60s, curr ageout 60sSep 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 0Sep 22 13:56:06 13:56:06.264920:CID-1:RT:flow_first_policy_search: Policy final matchSep 22 13:56:06 13:56:06.264920:CID-1:RT: flow_conn_track_ent_lookup: zone connection track 0x10Sep 22 13:56:06 13:56:06.264920:CID-1:RT:flow_first_src_xlate: nat_src_xlated: False, nat_src_xlate_failed: FalseSep 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 0Sep 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/0Sep 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 85Sep 22 13:56:06 13:56:06.264920:CID-1:RT: packet dropped, outgoing tunnel missing in tunnel-ifSep 22 13:56:06 13:56:06.264920:CID-1:RT: outgoing tunnel missing in tunnel-if st0.249Sep 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 sessionSep 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 0x5ee78d00Sep 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 notifySep 22 13:56:07 13:56:07.126038:CID-1:RT:flow_ipv4_del_flow: sess 231928236089, in hash 32Sep 22 13:56:07 13:56:07.126038:CID-1:RT:ha_ifp: st0.249
Original Message:
Sent: 09-22-2023 02:11
From: TheDisciple
Subject: Make Vlan availible on low end Router
Hello Koos147,
There could be a few reasons for the Pings to fail :
- It may be that the traffic is not making into the tunnel between head-office-lan and 3rd-party vpn.
- 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!
Original Message:
Sent: 09-20-2023 06:08
From: Koos147
Subject: Make Vlan availible on low end Router
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?
Original Message:
Sent: 09-06-2023 00:50
From: TheDisciple
Subject: Make Vlan availible on low end Router
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!
Original Message:
Sent: 08-31-2023 08:16
From: Koos147
Subject: Make Vlan availible on low end Router
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.
Original Message:
Sent: 08-30-2023 01:39
From: TheDisciple
Subject: Make Vlan availible on low end Router
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,
Original Message:
Sent: 08-29-2023 08:40
From: Koos147
Subject: Make Vlan availible on low end Router
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?