Screen OS

Hi,

I have a FW with ScreenOS 5.4

It has one untrust interface with lets' say public ip 1.1.1.2/27(1.1.1.1-1.1.1.30 range)

One public DMZ interface with public IP 1.1.1.33/27(1.1.1.33-62 range).

One private DMZ interface with private IP 192.168.152.1/24

One trusted interface with private IP 10.144.0.10/16.

On the untrust interface i have a lot of MIPs from 1.1.1.x(x in 1 to 30 range) ips to private DMZ ips 192.168.152.x and they work OK but now I am out of public IP addresses on untrust interface subnet and I want to use public IPs from DMZ range and have MIPs like 1.1.1.y(y in 33 to 62 range) to private DMZ ips 192.168.152.x.

I have tried a MIP from 1.1.1.40 to 192.168.152.22 and it does not work. I have tried to see with get session and nothing.

Thanks for helping.

TCP. 

5.4 is a bit old to start with. But MIP's on DMZ should work I think. Can you debug the session:

set ff dst-ip <ip mip>

debug flow basic

clear db

generate traffic to the mip

undebug all

get db stream

HI,

Here is the debug output:

****** 1464660.0: <Untrust/ethernet0/2> packet received [52]******
ipid = 31361(7a81), @2e6f9910
packet passed sanity check.
ethernet0/2:4.4.4.1/2801->1.1.1.40/3389,6<Root>
no session found
flow_first_sanity_check: in <ethernet0/2>, out <N/A>
chose interface ethernet0/2 as incoming nat if.
flow_first_routing: in <ethernet0/2>, out <N/A>
search route to (ethernet0/2, 4.4.4.1->1.1.1.40) in vr untrust-vr for vsd-0/flag-0/ifp-null
[ Dest] 3.route 1.1.1.40->1.1.1.40, to ethernet0/1
routed (x_dst_ip 1.1.1.40) from ethernet0/2 (ethernet0/2 in 0) to ethernet0/1
policy search from zone 1-> zone 3
policy_flow_search policy search nat_crt from zone 1-> zone 3
RPC Mapping Table search returned 0 matched service(s) for (vsys Root, ip 1.1.1.40, port 3389, proto 6)
No SW RPC rule match, search HW rule
Searching global policy.
packet dropped, denied by policy

It looks like the MIP doesn't work on DMZ interface(it doesn't redirect to 192.168.152.22, it remains with public ip from DMZ and it doesn't find a host with 1.1.1.40 so it drops the packet).

Regards,

TCP. 

Hi,

Do you have a policy from untrust to DMZ zone.

It should allow traffic from :4.4.4.1/2801->1.1.1.40/3389,

The traffic will first go from Untrust to DMZ without natting and will then create a loopback session for the MIP natting.

Below is a KB for similar scenario:

kb.juniper.net/KB25825

Regards.

Hardeep

Hi,

I have already a policy for untrust to DMZ for MIP:

set policy id 180 from "Untrust" to "DMZ" "Any" "MIP(1.1.1.40)" "MS-RDP" permit

Do I need to add another untrust to DMZ policy for 1.1.1.40 public IP in MDZ?

Regards,

TCP.

Yes, you dont need to define MIP on the policy.

Try using ANY as the destination on the policy.

Regards,

Hardeep

Hi,

What I did and it worked it was adding two policies:

set address "DMZ" "DMZ_server_public_IP" 1.1.1.40 255.255.255.255

set policy id 10 from "Untrust" to "DMZ"  "Any" "DMZ_server_public_IP" "MS-RDP" permit

set policy id 11 from "DMZ" to "intdmz"  "Any" "MIP(1.1.1.40)" "MS-RDP" permit

With only one rule(the first one it didn't work).

If you have another suggestion please don't hesitate.

Regards,

TCP.

Hi,

This is correct. If the MIP is not located on the packet's ingress interface you need two policies. This looks like a session that crosses the firewall twice. The looping sessions work in a similar manner. In most cases a src-NAT should be enabled in the first policy to avoid asymmetric routing of the responce packets.

Nothing prevents you from creating this MIP on Untrust interface. This may be impossible in very old ScreenOS releases, but should be OK in 5.4.

Hi,

It was easier to create the MIP on untrust interface but all IPs in the untrust range were used already that's why i have chosen DMZ MIP.

Is it possible to use MIPs on untrust interface with public IPs from the DMZ range?

Regards,

TCP. 

Hi,

Yes, this is exactly what I mean.

You can use vritually any addresses for MIPs without taking care if they belong to the interface network or not.

Hi,

Tested and it's OK.

Many thanks,

TCP.