Thanks, Spluuka, and everyone else I was able to get this working per below script using a different customer FW but at the end of the day the nat is the same except for the IP addresses involved.
I also setup a linux box with Apache running to test the https access and it worked as expected.
set security nat static rule-set rs1 from zone Customer
set security nat static rule-set rs1 rule r1 match destination-address 10.10.10.25/32
set security nat static rule-set rs1 rule r1 then static-nat prefix 10.25.50.54/32
set security nat static rule-set rs1 rule r2 match destination-address 10.10.10.26/32
set security nat static rule-set rs1 rule r2 then static-nat prefix 10.25.50.43/32
set security nat proxy-arp interface ae2.0 address 10.10.10.25/32
set security nat proxy-arp interface ae2.0 address 10.10.10.26/32
show security flow sessions nat (Working Condition)
Session ID: 1445, Policy name:Access/25, HA State: Stand-alone, Timeout: 2, Valid
In: 10.10.10.111/1 --> 10.10.10.25/4476;icmp, Conn Tag: 0x0, If: ae2.0, Pkts: 1, Bytes: 60,
Out: 10.25.50.54/4476 --> 10.10.10.111/1;icmp, Conn Tag: 0x0, If: st0.1, Pkts: 1, Bytes: 60,
Mar 11 08:45:51 08:45:51.377171:CID-0:RT:
Mar 11 08:45:51 08:45:51.377171:CID-0:RT:~~~FLOW <10.10.10.111/1->10.10.10.25/4482;1,0x0> matched filter filter-name-here(0) in root-logical-system for iif ae2.0 of root-logical-system:
Mar 11 08:45:51 08:45:51.377171:CID-0:RT: packet [60] ipid = 47893, @0x5ee7429c
Mar 11 08:45:51 08:45:51.377171:CID-0:RT:---- flow_process_pkt: (thd 1): flow_ctxt type 15, common flag 0x0, mbuf 0x5ee74080, rtbl_idx = 6
Mar 11 08:45:51 08:45:51.377171:CID-0:RT: flow process pak fast ifl 75 in_ifp ae2.0
Mar 11 08:45:51 08:45:51.377171:CID-0:RT: ae2.0:10.10.10.111->10.10.10.25, icmp, (8/0)
Mar 11 08:45:51 08:45:51.377171:CID-0:RT: find flow: table 0x69b2c88, hash 57464(0xffff), sa 10.10.10.111, da 10.10.10.25, sp 1, dp 4482, proto 1, tok 24589, conn-tag 0x00000000, vrf-grp-id 0
Mar 11 08:45:51 08:45:51.377171:CID-0:RT: no session found, start first path. in_tunnel - 0x0, from_cp_flag - 0
Mar 11 08:45:51 08:45:51.377171:CID-0:RT: flow_first_create_session
Mar 11 08:45:51 08:45:51.377171:CID-0:RT:Save init hash spu id 0 to nsp and nsp2!
Mar 11 08:45:51 08:45:51.377171:CID-0:RT:First path alloc and instl pending session, natp=0x90b98d0, id=1461
Mar 11 08:45:51 08:45:51.377171:CID-0:RT: flow_first_in_dst_nat: in <ae2.0>, out <N/A> dst_adr 10.10.10.25, sp 1, dp 4482
Mar 11 08:45:51 08:45:51.377171:CID-0:RT: chose interface ae2.0 as incoming nat if.
Mar 11 08:45:51 08:45:51.377171:CID-0:RT:flow_first_rule_dst_xlate: packet 10.10.10.111->10.10.10.25 nsp2 0.0.0.0->10.25.50.54.
Mar 11 08:45:51 08:45:51.377171:CID-0:RT:[JSF] Do ingress interest check. regd ingress plugins(2)
Mar 11 08:45:51 08:45:51.377171:CID-0:RT:[JSF][0]plugins(0x0) enabled for session = 1461 implicit mask(0x0), service request(0x0)
Mar 11 08:45:51 08:45:51.377171:CID-0:RT:-jsf : no plugin ingress interested for session 1461
Mar 11 08:45:51 08:45:51.377171:CID-0:RT:flow_first_routing: vr_id 6, call flow_route_lookup(): src_ip 10.10.10.111, x_dst_ip 10.25.50.54, in ifp ae2.0, out ifp N/A sp 1, dp 4482, ip_proto 1, tos 0
Mar 11 08:45:51 08:45:51.377171:CID-0:RT:flow_first_routing: Doing DESTINATION addr route-lookup
Mar 11 08:45:51 08:45:51.377171:CID-0:RT:flow_ipv4_rt_lkup success 10.25.50.54, iifl 0x4b, oifl 0x4e
Mar 11 08:45:51 08:45:51.377171:CID-0:RT:flow_first_routing: setting out_vrf_id in lpak to 0, grp 0
Mar 11 08:45:51 08:45:51.377171:CID-0:RT: routed (x_dst_ip 10.25.50.54) from Brookline-PD (ae2.0 in 0) to st0.1, Next-hop: 10.25.50.54
Mar 11 08:45:51 08:45:51.377171:CID-0:RT:Policy lkup: vsys 0 zone(13:Customer) -> zone(9:Tunnels) scope:0
------------------------------
Paul Andreozzi
------------------------------
Original Message:
Sent: 03-11-2024 20:04
From: spuluka
Subject: SSG Interpretation to SRX
I'm having trouble following the flow but can say the the MIP (mapped ip) in ScreenOS SSG is equivalent to Static NAT in Junos SRX.
This is a bidirectional full one-to-one mapping of an internal to external address that applies both source nat outbound and destination nat inbound to the matched ip addresses. This can be setup for single addresses or one subnet to a matched subnet.
Description is at the top of this page linking to the bookmark of a one address to one address example that seems to be what you are using.
https://www.juniper.net/documentation/us/en/software/junos/nat/topics/topic-map/security-nat-static.html#id-example-configuring-static-nat-for-single-address-translation
------------------------------
Steve Puluka BSEET - Juniper Ambassador
IP Architect - DQE Communications Pittsburgh, PA (Metro Ethernet & ISP - Retired)
http://puluka.com/home
Original Message:
Sent: 03-05-2024 14:19
From: Paul Andreozzi
Subject: SSG Interpretation to SRX
HI All, I need help in understanding the following SSG data.
I have to convert this to SRX terms, and I think I may be missing something.
Here is the SSG.
set interface "bgroup1" zone "Customer"
set interface bgroup1 port ethernet0/2
set interface bgroup1 port ethernet0/3
set interface bgroup1 ip 192.36.253.86/24
set interface bgroup1 route
set interface "bgroup1" mip 192.36.253.74 host 10.25.50.54 netmask 255.255.255.255 vr "tunnel-vr"
set policy id 8 name "Portal Access" from "Customer(zone)" to "Tunnels(zone)" "Customer Lan" "MIP(192.36.253.74)" "BRIC ArcGIS Portal Services" nat src permit log
set vrouter "trust-vr"
set route 10.25.50.0/24 vrouter "tunnel-vr" preference 20 metric 1 description "To Services"
set vrouter "tunnel-vr"
set route 10.25.50.0/24 interface tunnel.1 gateway 10.253.252.2 description "To Services"
set route 192.36.253.0/24 vrouter "trust-vr" preference 20 description "Customer LAN
I need to interpret the highlighted red.
My thoughts is that this is a destination NAT to begin with indicating that anything from the customer network (192.36.253.0/24) going to destination 192.36.253.74 the 192.36.253.74 will be translated to 10.25.50.54 making this a destination nat.
For the routing the SSG is forwarding next-table in both directions but because the SRX assumes a loop you cannot do this to I created an instance-import and used a filter to only allow the Customer Subnet to Tunnel-VR (aka routing-instance on the SRX) and the same in the opposite direction for the 10.25.50.0/24 subnet.
This does show up in the route table when I display them.
My current policy is any/any for the zones associated with this traffic until I can get the nat working.
In production I had the customer ping 192.36.253.74 from the same subnet on his network and there is a response.
I tried multiple tests in my lab where the 10.25.50.54 is pingable through my IPSec tunnel within the routing-instance so I know that is working.
I just cannot get the ping from 192.36.253.anything to 192.36.253.74 (destination real address other 10.25.50.54) to respond to a ping or traceroute.
Any info is greatly appreciated.
Paul
------------------------------
Paul Andreozzi
------------------------------