Screen OS

Hi,

I have a peer with which I have an established VPN. I need to access 3 different remote IPs so I have 3 different SAs with proxyIDs for each of these hosts. For my part of the VPN I have 172.28.159.88/29 subnet and I NAT all outgoing traffic to 172.28.159.89/32 before sending it out. This works perfectly. Now there is a need to allow some remotely initiated traffic as well (from the same 3 hosts).

The general parameters would be:

• VPN interface in zone1 (untrust-red2.13), unnumbered tunnel interface tun7, untrust VR
• 3 different SAs for each remote host
• dst host in zone101 - trust VR

So I created a VIP on 172.28.159.94 to point to the host:port nedded. When I did a debug basic, I could see the traffic showing up on my part but being dropped due to no-policy-found:

****** packet decapsulated, type=ipsec, len=60******
  ipid = 5964(174c), @1d6c7114
  tunnel.7:10.104.8.88/38192->172.28.159.94/7071,6<Root>
  no session found
  flow_first_sanity_check: in <tunnel.7>, out <N/A>
  chose interface tunnel.7 as incoming nat if.
  flow_first_routing: in <tunnel.7>, out <N/A>
  search route to (tunnel.7, 10.104.8.88->172.28.159.94) in vr untrust-vr for vsd-0/flag-0/ifp-null
  [ Dest] 66.route 172.28.159.94->172.28.159.94, to redundant2.13
  routed (x_dst_ip 172.28.159.94) from tunnel.7 (tunnel.7 in 0) to redundant2.13 
  policy search from zone 1-> zone 1
 policy_flow_search  policy search nat_crt from zone 1-> zone 1
  RPC Mapping Table search returned 0 matched service(s) for (vsys Root, ip 172.28.159.94, port 7071, 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
  packet dropped, deny by zone block
  packet dropped, null policy.

  **** pak processing end.

 I had rules on the zone1->zone101 allowing the traffic to the VIP and also to the dst IP and it seems it wasn't even looked up. In the dump there is zone1->zone1 lookup so I put the same rule to allow the traffic to the VIP in this zone as well - without any change. I even changed the VIP to MIP to see if there would be anything different but there wasn't. Actually I'd prefer to have a VIP as we are talking about 1 specific port but I can live with a MIP as well..

What puzzles me is where should these policies be or is there anything wrong in the setup as the VIP/MIP isn't mapped to the real dstIP.

Thanks

Jure

Hi,

Have you configured the IPs used for VPN-NAT on the redundant2.13 interface? They should be on the tunnel interface.

Ok, I figured it out myself. VIP/MIP was a wrong way to go. What I had to do was to make a policy in zone1->zone1 intrazone where I NAT srcIP to interfaceIP and NAT the dstIP to the host in zone 101 I want it to reach. So the policy is like

FW-1(M)-> get policy id 665
name:"none" (id 665), zone Untrust -> Untrust,action Permit, status "enabled"
3 sources: "rSrc1", "rSrc2", "rSrc3"
1 destination: "172.28.159.94/32"
1 service: "theService"
Rules on this VPN policy: 0
nat src dst map to 192.168.30.18, Web filtering disabled
vpn unknown vpn, policy flag 00010420, session backup: on
traffic shaping off, scheduler n/a, serv flag 00
log init close, log count 62, alert no, counter no(0) byte rate(sec/min) 0/0
total octets 474031, counter(session/packet/octet) 0/0/0
priority 7, diffserv marking Off
tadapter: state off, gbw/mbw 0/0 policing (no)
No Authentication
No User, User Group or Group expression set

 so no VIP/MIP needed. What intrigues me a bit is the fact you need no permit policy in the zone 101 where the dstIP is located..But it works now..

Jure

Hi,

If you configure a policy with policy based dst-NAT and destination IP is in the network of Untrust interface the policy should be Untrust-to-Untrust for all connections initiated from Untrust zone. If policy based dst-NAT is used ScreenOS makes two routing desissions - one for the NAT IP and one for the original IP. The first routing decission defines which zone should be considered as a destination one. In your case the incoming packets should be routed to Untrust interface and an Untrust-to-Untrust policy should be applied. After the policy has been hit the dst-IP is translated, the routing table is looked up again and the packet is forwarded to the original IP.

If the NAT IPs are not configured on any interface, neither in the primary no in the secondary or extended network, you can use an Untrust-to-Trust policy. Both NAT and original IPs should be routed through an interface in Trust zone and both address objects should be mapped to Trust zone. The first route (for NAT IP) can be configured with a blank gateway (next hop IP). This route is used for the first routing decission only and not for real routing.