Screen OS

Hi,

I am having an issue configuring a SSG-140.  I've successfully configured 15 VIP without problem  in the same way, with multiple VIP and multiple ports. It's being

working for a long time.
I've created a last  VIP service on the ethernet0/0 interface, which is my public interface.  I have the service pointing to my server internally. The firewall reached

without problems the internal host. I've created and selected the service that it will forward the port, in this case FTP, and I've created a policy from Untrust to DMZ that will allow the service from ANY to VIP (x.x.x.x.). The status for the VIP service on ethenret0/0 is UP, however I do not see any traffic when I ask for  the FTP from outiside. The internal host reached internet without problem.
We follow all the technical from Juniper and we saw in the alarm events, sometimes not always,  00023 VIP error, that means we do not reched de host,

but is not true, the firewall always reached the internal host. Server Auto Detection is not enable.

The config is very extens, I atached the relevant to the issue
 
SSG-140(M)-> get vip
Virtual IP      Interface      Port/Port-range   Server                Service/P                                                                                        

ort-range(protocol)
x.x.x.67    ethernet0/0    80                192.168.8.11(OK)      HTTP
x.x.x.67    ethernet0/0    161               192.168.6.1(OK)       SNMP
x.x.x.67    ethernet0/0    443               192.168.8.11(OK)      HTTPS
x.x.x.67    ethernet0/0    8000              192.168.6.69(OK)      HTTP
x.x.x.68    ethernet0/0    443               192.168.8.9(OK)       HTTPS
x.x.x.68    ethernet0/0    162               192.168.6.33(OK)      TCP-162
x.x.x.68    ethernet0/0    161               192.168.6.33(OK)      SNMP
x.x.x.73    ethernet0/0    443               192.168.8.11(OK)      HTTPS
x.x.x.73    ethernet0/0    444               192.168.8.11(OK)      HTTPS
x.x.x.73    ethernet0/0    143               192.168.8.11(OK)      IMAP
x.x.x.73    ethernet0/0    110               192.168.8.11(OK)      POP3
x.x.x.73    ethernet0/0    25                192.168.8.11(OK)      SMTP
x.x.x.73    ethernet0/0    80                192.168.6.15(OK)      HTTP
x.x.x.73    ethernet0/0    5086              192.168.8.11(OK)      Lync
x.x.x.73    ethernet0/0    5087              192.168.8.11(OK)      Lync
x.x.x.74    ethernet0/0    80                192.168.8.12(OK)      HTTP
x.x.x.74    ethernet0/0    443               192.168.8.12(OK)      HTTPS
x.x.x.74    ethernet0/0    53                192.168.8.12(OK)      DNS
x.x.x.75    ethernet0/0    60021             192.168.6.29(OK)      FTP
x.x.x.75    ethernet0/0    25                192.168.8.13(OK)      SMTP
x.x.x.75    ethernet0/0    53                192.168.8.13(OK)      DNS
x.x.x.75    ethernet0/0    21                192.168.8.13(OK)      FTP
x.x.x.75    ethernet0/0    80                192.168.6.29(OK)      HTTP
x.x.x.78    ethernet0/0    80                192.168.8.22(OK)      HTTP
x.x.x.78    ethernet0/0    443               192.168.8.11(OK)      TCP-4455
x.x.x.102   ethernet0/0    21                172.16.253.4(OK)      FTP   -> this is the only one do not work
x.x.x.81    ethernet0/0    80                192.168.8.18(OK)      TCP-8080
x.x.x.81    ethernet0/0    3389              192.168.8.18(OK)      RDP
x.x.x.83    ethernet0/0    80                192.168.7.111(OK)     TCP-8080
x.x.x.122   ethernet0/0    80                10.1.1.129(OK)        HTTP
x.x.x.122   ethernet0/0    21                10.1.1.130(OK)        FTP
x.x.x.122   ethernet0/0    2383              10.1.1.130(OK)        TCP-2383
x.x.x.123   ethernet0/0    443               10.1.1.2(OK)          HTTPS
x.x.x.123   ethernet0/0    12730             10.1.1.2(OK)          TCP - 12730
x.x.x.123   ethernet0/0    444               10.1.1.3(OK)          HTTPS
x.x.x.123   ethernet0/0    12731             10.1.1.3(OK)          TCP - 12730
x.x.x.82    ethernet0/0    80                192.168.6.17(OK)      HTTP
x.x.x.85    ethernet0/0    65222             192.168.6.33(OK)      SSH
x.x.x.85    ethernet0/0    80                192.168.6.33(OK)      HTTP
x.x.x.124   ethernet0/0    443               172.16.252.1(OK)      HTTPS
x.x.x.124   ethernet0/0    5555              172.16.252.1(OK)      HTTP
x.x.x.84    ethernet0/0    443               192.168.8.14(OK)      HTTPS
x.x.x.86    ethernet0/0    80                192.168.6.15(OK)      HTTP


Those are de policies involved:

    ID From     To       Src-address      Dst-address      Service                  Action State   ASTLCB
   250 DMZ      Untrust  NetworkDMZ      Any              ANY                      Permit enabled ---X-X
   252 Trust    DMZ     Any              Any              ANY                      Permit enabled ---X-X
   253 Untrust  DMZ       Any              VIP(x.x.x.102)     FTP                      Permit enabled ---X-X

Thanks in advance for your time

Best regards,


Marc

Can you run a debug on the ftp session?

Like this:

set ff dst-up x.x.x.102 dst-port 22

clear db

debug flow basic

Try the ftp from outside

undebug all

get db stream

Hi,

I would also check if 172.16.253.xxx is routed on the VR the interface eth0/0 is mapped to.

Hi,

Thank you in advance, I appreciate very much your help.

As both ask for info, I attached here the debug and the routing,

SSG-140(M)-> get db stream
****** 63019064.0: <Untrust/ethernet0/0> packet received [52]******
ipid = 12693(3195), @1d64a914
packet passed sanity check.
flow_decap_vector IPv4 process
ethernet0/0:88.31.226.241/65077->x.x.x.102/21,6<Root>
no session found
flow_first_sanity_check: in <ethernet0/0>, out <N/A>
chose interface ethernet0/0 as incoming nat if.
flow_first_routing: in <ethernet0/0>, out <N/A>
search route to (ethernet0/0, 88.31.226.241->172.16.253.4) in vr trust-vr for vsd-0/flag-0/ifp-null
cached route 0 for 172.16.253.4
add route 125 for 172.16.253.4 to route cache table
[ Dest] 125.route 172.16.253.4->172.16.253.4, to ethernet0/8.2
routed (x_dst_ip 172.16.253.4) from ethernet0/0 (ethernet0/0 in 0) to ethernet0/8.2
policy search from zone 1-> zone 101
policy_flow_search policy search nat_crt from zone 1-> zone 10
RPC Mapping Table search returned 0 matched service(s) for (vsys Root, ip x.x.x.102, port 21, proto 6)
No SW RPC rule match, search HW rule
swrs_search_ip: policy matched id/idx/action = 320000/-1/0x0
Searching global policy.
swrs_search_ip: policy matched id/idx/action = 320000/-1/0x0
policy id (320000)
packet dropped, denied by policy
Policy id deny policy, ipv6 0, flow_potential_violation 0

routing I think it is ok, the internal host reaches internet.

ID IP-Prefix Interface Gateway P Pref Mtr Vsys
--------------------------------------------------------------------------------------
* 17 0.0.0.0/0 eth0/0 x.x.x.65 SP 20 1 Root

* 125 172.16.253.0/24 eth0/8.2 0.0.0.0 C 0 0 Root

* 126 172.16.253.254/32 eth0/8.2 0.0.0.0 H 0 0 Root

Best regards,

Marc

Hi,

I also attache the policies involved:

    250 DMZ-CBB  Untrust  Network-DMZ  Any          ANY                  Permit enabled ---X-X
    253 Untrust       DMZ  Any          VIP(x.x.x.102)       FTP                  Permit enabled ---X-X

Best regards,

Marc

Hi,

The packet is routed to the interface ethernet0/8.2 which is not mapped to DMZ. It is mapped to a custom zone which ID is 101. That's why ScreenOS cannot hit the Untrust-to-DMZ policy ID 253. The default Deny policy with ID 320000 is applied in this case.

You should create an Untrust-to-CustZone policy for FTP. You can also create an Untrust-to-Global policy. This is eg. recommended if the VIP destination hosts are located in deifferent zones but you would prefer to see all the policsies with this VIP in a single  Untrust-to-Global policy block.

The second policy check as in the debug output should find this policy:

policy_flow_search policy search nat_crt from zone 1-> zone 10

Hi,

I made I mistake posting policies: it should confuse, sorry

    252 Trust    DMZ  Any          Any          ANY                  Permit enabled ---X-X
   250 DMZ      Untrust             Network-DMZ  Any          ANY                  Permit enabled ---X-X
   253 Untrust  DMZ  Any          VIP(212.36.~ FTP                  Permit enabled ---X-X
   254 Untrust  DMZ  Any          Any          ANY                  Permit enabled -----X

    255 Untrust  Global   Any          VIP(212.36.~ FTP                  Permit enabled -----X

The zone is correct

 ID Name                             Type    Attr    VR          Default-IF   VSYS
   0 Null                             Null    Shared untrust-vr   null         Root

1 Untrust                          Sec(L3) Shared trust-vr     ethernet0/0  Root

101 DMZ                          Sec(L3)        trust-vr     ethernet0/8.2 Root

As I understand zone 1 is untrust and zone 101 is DMZ. Anyway I add the policies 254 and 255 (global one) us you suggest, with same result.

I atacched new debug with the two new policies enabled

****** 63047596.0: <Untrust/ethernet0/0> packet received [52]******
  ipid = 915(0393), @1d6e8114
  packet passed sanity check.
  flow_decap_vector IPv4 process
  ethernet0/0:80.28.222.166/54675->212.36.84.102/21,6<Root>
  no session found
  flow_first_sanity_check: in <ethernet0/0>, out <N/A>
  chose interface ethernet0/0 as incoming nat if.
  flow_first_routing: in <ethernet0/0>, out <N/A>
  search route to (ethernet0/0, 80.28.222.166->172.16.253.4) in vr trust-vr for vsd-0/flag-0/ifp-null
  cached route 0 for 172.16.253.4
  add route 125 for 172.16.253.4 to route cache table
  [ Dest] 125.route 172.16.253.4->172.16.253.4, to ethernet0/8.2
  routed (x_dst_ip 172.16.253.4) from ethernet0/0 (ethernet0/0 in 0) to ethernet0/8.2
  policy search from zone 1-> zone 101
 policy_flow_search  policy search nat_crt from zone 1-> zone 10
  RPC Mapping Table search returned 0 matched service(s) for (vsys Root, ip 212.36.84.102, port 21, proto 6)
  No SW RPC rule match, search HW rule
swrs_search_ip: policy matched id/idx/action = 320000/-1/0x0
  Searching global policy.
swrs_search_ip: policy matched id/idx/action = 320000/-1/0x0
policy id (320000)
packet dropped, denied by policy
Policy id deny policy, ipv6 0, flow_potential_violation 0

Thank you in advance.

Best regards,

Marc

Hi Marc,

DMZ is a predifined zone which has ID 3! One cannot rename nor delete it. It is also impossible to create a custom DMZ which re-writes the predifined one. The custom zones in opposite can be created, changed and deleted. They are automatically numbered staring with the number 101, which can be changed. I have no idea how to convert the predifined Zone DMZ (ID 3) into a custom zone with the same name unless you have a buggy ScreenOS release!

ScreenOS finds the destination zone DMZ ID 101 while looking up the routing table and starts to look up the policy block for the destination zone DMZ ID 3, which is empty...

Could you attach an output from get zone?

Hi,

You are right. The 101 is a custom zone, I changed the name to DMZ to hide the client's name, I feel that this has confused.

Get zone 

ID Name Type Attr VR Default-IF VSYS
0 Null Null Shared untrust-vr null Root
1 Untrust Sec(L3) Shared trust-vr ethernet0/0 Root
2 Trust Sec(L3) trust-vr ethernet0/2 Root
3 DMZ Sec(L3) trust-vr ethernet0/1 Root
4 Self Func trust-vr self Root
5 MGT Func trust-vr null Root
6 HA Func trust-vr ethernet0/9 Root
10 Global Sec(L3) trust-vr null Root
11 V1-Untrust Sec(L2) Shared trust-vr v1-untrust Root
12 V1-Trust Sec(L2) Shared trust-vr v1-trust Root
13 V1-DMZ Sec(L2) Shared trust-vr v1-dmz Root
14 VLAN Func Shared trust-vr vlan1 Root
15 V1-Null Sec(L2) Shared trust-vr l2v Root
16 Untrust-Tun Tun trust-vr hidden.1 Root
100 DMZ_XXX Sec(L3) trust-vr ethernet0/3 Root
101 DMZ-YYY Sec(L3) trust-vr ethernet0/8.2 Root  (this is the one with the issue)
102 DMZ-ZZZ Sec(L3) trust-vr ethernet0/8.1 Root
103 DMZ-DDD Sec(L3) trust-vr ethernet0/8.3 Root
104 NAS-WWW Sec(L3) trust-vr ethernet0/7 Root
105 Cloud-AAA Sec(L3) trust-vr ethernet0/4.2 Root
106 Cloud-BBB Sec(L3) trust-vr ethernet0/4.1 Root
107 Cloud-CCC Sec(L3) trust-vr ethernet0/4.3 Root

The policies:

252 Trust    DMZ  Any          Any          ANY                  Permit enabled ---X-X
   250 DMZ-YYY      Untrust             Network-DMZ-YYY  Any          ANY                  Permit enabled ---X-X
   253 Untrust  DMZ-YYY  Any          VIP(x.x.x.102)  FTP                  Permit enabled ---X-X
   254 Untrust  DMZ-YYY  Any          Any          ANY                  Permit enabled -----X

    255 Untrust  Global   Any          VIP(x.x.x.102)  FTP                  Permit enabled -----X

Best regards,

Marc

Hi,

SSG-140 supports 16 VIPs only and up to 1500 MIPs. Perhaps you have one more VIP somewhere else.

If you have a 1-to-1 public-to-private IP mapping for multiple services and no port translation the MIP is the best choice. Besides, the MIP is the fastest NAT type in ScreenOS and much simpler when configured with the multiport services.

And, you can configure a lot of MIPs.

The policy based dst-NAT is also a good alternative for VIPs/MIPs and, at the same time, the most flexible kind of NAT.

Try to configure a MIP.

I have assumed that FTP is really FTP and not a part of the name of a custom service (like FTP-XXX).

Hi

Thank you for your answers and your time.

Best regards,

Marc

Hi,

Finally we decide to reboot the SSG-140 and it started working fine, The issue has disappeared. So the config was ok. now we reached the FTP from outside.

Thank you again for your help.

Best regards,

Marc