Support Support Downloads Knowledge Base Juniper Support Portal Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[ScreenOS] How to configure the MIP when the ingress and egress interfaces are in different VSYS

0

0

Article ID: KB26760 KB Last Updated: 15 Dec 2017Version: 2.0
Summary:
This article provides information on how to configure MIP traffic flow, when the ingress and egress interfaces are in different VSYS.
Symptoms:

 
  • The initiator (10.1.1.1) is trying to reach the 192.168.1.1 server.

  • The initiator does not have the IP address of the server (192.168.1.1).

  • The initiator accesses the server with the 10.1.1.3 MIP IP address.

  • The ingress interface is in Vsys-a (zone: Trust-Vsys-a) and the egress interface is in Vsys-b (zone: Trust-Vsys-b).
Solution:
Configuration on the root VSYS:

An interface has to be bound to a shared zone (Untrust). This will be visible across all the VSYS's:
set interface "loopback.1" zone "Untrust"
set interface loopback.1 ip 1.1.1.1/24
set interface loopback.1 route
Configuration on VSYS-A:

Import the eth1/1 interface in VSYS-A and configure the zone, IP address, and MIP configuration:
set interface ethernet1/1 import
set interface "ethernet1/1" zone "Trust-vsys-a"
set interface ethernet1/1 ip 10.1.1.2/24
set interface ethernet1/1 route

set interface "ethernet1/1" mip 10.1.1.3 host 192.168.1.1 netmask 255.255.255.255 vr "vsys-a-vr"
set vrouter "vsys-a-vr"
The routing that has to be added in VSYS-A is as follows:
set vrouter "vsys-a-vr"
set route 192.168.1.1/24 vrouter "trust-vr" preference 20 metric 1 < This is for incoming traffic

set vrouter "trust-vr"
set route 10.1.1.1/32 vrouter "vsys-a-vr" preference 20 metric 1 < This is for response traffic
The policy that has to be created in VSYS-A is as follows:
set policy id 1 from "Trust-vsys-a" to "Untrust" "Any" "MIP(10.1.1.3)" "ANY" permit log
set policy id 1
set log session-init
exit

Configuration on VSYS-B:

Import the eth1/2 interface in VSYS-B and configure the zone and IP address:
set interface ethernet1/2 import
set interface "ethernet1/2" zone "Trust-vsys-b"
set interface ethernet1/2 ip 192.168.1.2/24
set interface ethernet1/2 route
The routing that has to be added in VSYS-B is as follows:
set vrouter "trust-vr"
set route 192.168.1.1/32 vrouter "vsys-b-vr" preference 20 metric 1 < This is for the incoming traffic

set vrouter "vsys-b-vr"
set route 10.1.1.1/32 vrouter "trust-vr" preference 20 metric 1 < This is for the response traffic
The policy that has to be created in VSYS-B is as follows:
set policy id 1 from "Untrust" to "Trust-vsys-b" "Any" "192.168.1.1/32" "ANY" permit log
set policy id 1
set log session-init
exit
The output of debug flow basic is as follows:

nsisg1000(M)-> get db str
**st: <Trust-vsys-a|ethernet1/1|vsys-a|0> 4f9c118: 645c:10.1.1.1/400->10.1.1.3/6c34,1,128
****** 46126.0: <Trust-vsys-a/ethernet1/1> packet received [128]****** < Traffic hits eth1/1 in Vsys-a
ipid = 25692(645c), @04f9c118
packet passed sanity check.
flow_decap_vector IPv4 process
ethernet1/1:10.1.1.1/27700->10.1.1.3/1024,1(8/0)<vsys-a> < Traffic destined for MIP IP address
no session found
flow_first_sanity_check: in <ethernet1/1>, out <N/A>
chose interface ethernet1/1 as incoming nat if.
IP classification from MIP/VIP: vsys vsys-a
flow_first_routing: in <ethernet1/1>, out <N/A>
search route to (ethernet1/1, 10.1.1.1->192.168.1.1) in vr vsys-a-vr for vsd-0/flag-0/ifp-null < Route lookup being done for Server IP address
[ Dest] 2.route 192.168.1.1->192.168.1.1, to ethernet1/2
routed (x_dst_ip 192.168.1.1) from ethernet1/1 (ethernet1/1 in 0) to ethernet1/2
Cross vsys (vsys-a->vsys-b) at ethernet1/2: need loopback push to Untrust < Crossing Vsys-a to Vsys-b (Note: if we don’t have an interface in shared Vsys
                                                                                                                                                           then traffic would fail)

policy search from zone 19-> zone 1 < Policy lookup in Vsys-a
policy_flow_search policy search nat_crt from zone 19-> zone 21
RPC Mapping Table search returned 0 matched service(s) for
(vsys vsys-a, ip 10.1.1.3, port 60413, proto 1)
No SW RPC rule match, search HW rule
rs_search_ip: policy matched id/idx/action = 1/0/0x9
Permitted by policy 1 < Permitted by policy in Vsys-a
No src xlate choose interface ethernet1/2 as outgoing phy if
check nsrp pak fwd: in_tun=0xffffffff, VSD 0 for out ifp ethernet1/2
skip loopback check for cross vsys (vsys-a->vsys-b)
session application type 0, name None, nas_id 0, timeout 60sec
service lookup identified service 0.
flow_first_final_check: in <ethernet1/1>, out <ethernet1/2>
SM_RULE:0
existing vector list 20-103f4ea4.
Session (id:10057) created for first pak 20
loopback session processing
post addr xlation: 10.1.1.1->192.168.1.1.
flow_first_sanity_check: in <loopback.2>, out <N/A>
chose interface loopback.2 as incoming nat if.
flow_first_routing: in <loopback.2>, out <N/A>
search route to (loopback.2, 10.1.1.1->192.168.1.1)
in vr trust-vr for vsd-0/flag-0/ifp-null
[ Dest] 2.route 192.168.1.1->192.168.1.1, to ethernet1/2
routed (x_dst_ip 192.168.1.1) from loopback.2 (loopback.2 in 0) to ethernet1/2
IP classification from non-shared dst if : vsys vsys-b
Cross vsys set nat crt vsys:vsys-b, pak vsys:Root, vsys:vsys-b, result:0
policy search from zone 1-> zone 22 < Policy lookup in Vsys-b
policy_flow_search policy search nat_crt from zone 1-> zone 22
RPC Mapping Table search returned 0 matched service(s) for
(vsys vsys-b, ip 192.168.1.1, port 60413, proto 1)
No SW RPC rule match, search HW rule
rs_search_ip: policy matched id/idx/action = 1/0/0x9
Permitted by policy 1 < Permitted by policy in Vsys-b
No src xlate choose interface ethernet1/2 as outgoing phy if
check nsrp pak fwd: in_tun=0xffffffff, VSD 0 for out ifp ethernet1/2
vsd 0 is active
no loop on ifp ethernet1/2.
session application type 0, name None, nas_id 0, timeout 60sec
service lookup identified service 0.
flow_first_final_check: in <loopback.2>, out <ethernet1/2>
SM_RULE:0
existing vector list 20-103f4ea4.
Session (id:10051) created for first pak 20
vector index1 20, vector index2 20
existing vector list 20-103f4ea4.
existing v6 vector list 20-fd299dc.
new vector index 20.
loopback session created
flow_first_install_session======>
route to 192.168.1.1
arp entry found for 192.168.1.1
ifp2 ethernet1/2, out_ifp ethernet1/2, flag 00800000, tunnel ffffffff, rc 1
outgoing wing prepared, ready
handle cleartext reverse route
search route to (ethernet1/2, 192.168.1.1->10.1.1.1)
in vr vsys-a-vr for vsd-0/flag-3000/ifp-ethernet1/1
[ Dest] 2.route 10.1.1.1->10.1.1.1, to ethernet1/1
route to 10.1.1.1
arp entry found for 10.1.1.1
ifp2 ethernet1/1, out_ifp ethernet1/1, flag 00800001, tunnel ffffffff, rc 1
flow got session.
flow session id 10057
flow_main_body_vector in ifp ethernet1/1 out ifp ethernet1/2
flow vector index 0x20, vector addr 0x103f4ea4, orig vector 0x103f4ea4
vsd 0 is active
post addr xlation: 10.1.1.1->192.168.1.1.
packet send out to 0017cb401680 (cached) through ethernet1/2 < Traffic sent out through eth1/2
Modification History:
2017-12-07: Article reviewed for accuracy. No changes made. Article is correct and complete.
Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search