Screen OS

SSG-550 - 5.1

 

I'm trying to get source natting working from a series of addresses to a single public IP address. this is to accomodate one of our clients addressing strategy. The traffic will then be sent over a route based tunnel to them, with all the traffic appearing to originate from this single address. I have had to create an extended interface IP to include the public IP address,I have enabled  NAT against the interface and set a DIP pool on that interface of a single IP address. I then created a policy with all the real source addresses as sources and the clients destination addresses with a few ports.

 

if I try and connect with Source Address Translation turned off on that policy the traffic passes (but obviously the tunnel fails to get past phase 2). If I turn it on, nominating the SIP pool I created, I see no logs to indicate any traffic has been passed at all. The tunnel does not attempt to come up so I assume it's not being passed. I've tried turned debug flow all on and debug nat all but still no logs.

 

Any tips would be gratefully recieved.

 

Here is the policy detail

name:"none" (id 42), zone Trust -> Untrust,action Permit, status "enabled"
src "my_source", dst "their_dest", serv "Services"
Policies on this vpn tunnel: 0
nat src dip-id 4, url filtering disabled
vpn unknown vpn, policy flag 0820, session backup: on
traffic shapping off, scheduler n/a, serv flag 00
log yes, log count 38, alert no, counter no(0) byte rate(sec/min) 0/0
total octets 7006, counter(session/packet/octet) 0/0/0
priority 7, diffserv marking Off
tadapter: state off, gbw/mbw 0/-1
No Authentication
No User, User Group or Group expression set
 

 And here are the DIP settings

Dip Id  Dip Low          Dip High         Interface       Attribute
   4    195.*.*.109    195.*.*.109    ethernet0/1     port-xlate
Port-xlated dip stickness off
 

 

Hi,

 

u r using DIP (source traslation) on tunnel interface. So in VPN->Autokey Advanced->Edit->Advanced here in proxy-id-> local IP here u should give DIP IP and on other box VPN->Autokey Advanced->Edit->Advanced here in proxy-id-> Remote IP u have to give DIP IP

 

Hopes this vl establish tunnel. Can u tell me on other side what device there???

Please let me know it work???

 

Thanks

 

Kashif

interface 0/1 is the trust interface, interface 0/0 is the untrust and this is the interface the tunnel is configured against. I thought they way to do this would be to configure DIP against the trust interface so once the traffic reached the untrust interfac, it already had a source address of the DIP pool.

 

Should I take the NAT off the policy and place it on the tunnel? Is this possible? At the moment the proxy ID for the local subnet is the NAtted address, not the real addresses.

 

The remote device is a cisco pix. I did try using a policy VPN before this but had the same problem, with the NAT in place, no logs at all and no attempt to raise the tunnel, with the NAT turned off, I saw logs reporting traffic had passed succesfully and saw the VPN tunnel reach phase 2 (but fail because of mismatched encryption domains), the pix reported proxy id's of 0.0.0.0 0.0.0.0. 

Oh and yes,the local proxy ID on the tunnel is already set to the DIP IP address.

Hi Jon,

 

Just tell me what subnets u want to pass though tunnel i mean it is one subnet or multiple can u tell me policies for tunnel traffic on both sides???

 

Thanks for your help with this.

 

The tunnel is set up with the single source NAT as the local address and 10.*.*.* addresses for the remote addresses. But that's not the issue I'm having here,if we ignore the tunnel for the time being... This is just a policy rule, it's a simple policy rule with a source NAT applied to it. With the NAT turned on, the policy rule does not report traffic being permitted at all. With the source NAt turned off, the rule allows traffic to pass and reports it being passed but that's no good to me, I need it to be NATted so it can be passed to the routed VPN.

 

Here's the tunnel interface I'm using...

 

Interface tunnel.2:
  number 20, if_info 48176, if_index 2, mode route
  link ready
  vsys Root, zone Untrust, vr trust-vr, vsd 0
  admin mtu 1500
  *ip 0.0.0.0/0  unnumbered, source interface ethernet0/0

  *manage ip 0.0.0.0
  bound vpn:
    VPN_name
  Next-Hop Tunnel Binding table
  Flag Status Next-Hop(IP)    tunnel-id  VPN

  ping disabled, telnet disabled, SSH disabled, SNMP disabled
  web disabled, ident-reset disabled, SSL disabled

  OSPF disabled  BGP disabled  RIP disabled  mtrace disabled
  PIM: not configured  IGMP not configured

 

 

OK, with the source nat removed from the policy rule, I see the traffic go through in the logs completely unnatted. So I then applied the DIP settings to the untrusted tunnel interface although I can see nowhere that I can dictate which addresses get source natted so I assume they all do. I see the device attempt phase 1 of the tunnel but it appears to get no response.

 

I have no idea if the source addresses are being natted at this point.... Any ideas if this is correct? How to I tell the dveice to nat the source addresses or is this implicit?

---

 

Hi,

 

Actually when u form vpn tunnel b/w SSG and Cisco for multiple networks to be tunneled, u should have to configure policy based VPN b/w them. so thats why i asked u about the proxy-id on SSG and access list on cisco for traffic through tunnel.

 

Please give answers, this vl help us to resolve the problem:

 

1) Proxy-id on SSG (with DIP enabled)?

2) Access-list on pix for traffic through vpn?

3) Tell with ur current configurations, vpn tunnel establish or not???

 

Thanks

 

Kashif

I've now removed all the VPN config. this is now just a simple NATing problem.

I have a policy rule which allows anything on the trust interface to get to a specific set of devices on the untrust interface.

 

name:"none" (id 42), zone Trust -> Untrust,action Permit, status "enabled"
src "Any", dst "-Net", serv "-Services"
Policies on this vpn tunnel: 0
nat src dip-id 4, url filtering disabled
vpn unknown vpn, policy flag 0820, session backup: on
traffic shapping off, scheduler n/a, serv flag 00
log yes, log count 51, alert no, counter no(0) byte rate(sec/min) 0/0
total octets 9610, counter(session/packet/octet) 0/0/0
priority 7, diffserv marking Off
tadapter: state off, gbw/mbw 0/-1
No Authentication
No User, User Group or Group expression set

 

Juniper-(M)-> get dip all
Dip Id  Dip Low          Dip High         Interface       Attribute
   4    195.1.1.1    195.1.1.1    ethernet0/1     port-xlate
Port-xlated dip stickness off
Juniper-(M)->
 

With the source-nat box unticked, the policy allows the traffic through.

With it ticked, I see no blocked or allowed traffic in the logs. 

Tell me where u created DIP?? I mean on which interface trust or untrust??

 

You can fix the problem:

 

clear db

set ffilter source-ip <ip of ur pc in trust zone>

set ffilter destination-ip

debug flow basic

 

//wait for getting information

 

undebug all

 

get db str

 

Please post output of get db str

 

Thanks

Thanks.

 

****** 9251095.0: <Trust/ethernet0/1> packet received [48]******
  ipid = 31872(7c80), @3d6d3910
  packet passed sanity check.
  ethernet0/1:10.251.1.1/4363->129.1.1.1/22,6<Root>
  no session found
  chose interface ethernet0/1 as incoming nat if.
  search route to (ethernet0/1, 10.251.1.1->129.1.1.1) in vr trust-vr for v                    sd-0/flag-0/ifp-null
  [Dest] 9.route 129.1.1.1->195.1.1.1, to ethernet0/0
  routed (129.1.1.1, 0.0.0.0) from ethernet0/1 (ethernet0/1 in 0) to etherne                    t0/0
  policy search from zone 2-> zone 1
 policy_flow_search  policy search nat_crt from zone 2-> zone 1
  No SW RPC rule match, search HW rule
  Permitted by policy 42
  dip alloc failed. dip_id = 0
  packet dropped, dip alloc failed
****** 9251098.0: <Trust/ethernet0/1> packet received [48]******
  ipid = 31881(7c89), @3d513110
  packet passed sanity check.
  ethernet0/1:10.251.1.1/4363->129.1.1.1/22,6<Root>
  no session found
  chose interface ethernet0/1 as incoming nat if.
  search route to (ethernet0/1, 10.251.1.1->129.1.1.1) in vr trust-vr for v                    sd-0/flag-0/ifp-null
  [Dest] 9.route 129.1.1.1->195.1.1.1, to ethernet0/0
  routed (129.1.1.1, 0.0.0.0) from ethernet0/1 (ethernet0/1 in 0) to etherne                    t0/0
  policy search from zone 2-> zone 1
 policy_flow_search  policy search nat_crt from zone 2-> zone 1
  No SW RPC rule match, search HW rule
  Permitted by policy 42
  dip alloc failed. dip_id = 0
  packet dropped, dip alloc failed
****** 9251104.0: <Trust/ethernet0/1> packet received [48]******
  ipid = 31890(7c92), @3d72e110
  packet passed sanity check.
  ethernet0/1:10.251.1.1/4363->129.1.1.1/22,6<Root>
  no session found
  chose interface ethernet0/1 as incoming nat if.
  search route to (ethernet0/1, 10.251.1.1->129.1.1.1) in vr trust-vr for v                    sd-0/flag-0/ifp-null
  [Dest] 9.route 129.1.1.1->195.1.1.1, to ethernet0/0
  routed (129.1.1.1, 0.0.0.0) from ethernet0/1 (ethernet0/1 in 0) to etherne                    t0/0
  policy search from zone 2-> zone 1
 policy_flow_search  policy search nat_crt from zone 2-> zone 1
  No SW RPC rule match, search HW rule
  Permitted by policy 42
  dip alloc failed. dip_id = 0
  packet dropped, dip alloc failed
 

and just so there's no confusion there, I've susbtituted IP addresses there, the gateway is a different IP address to the NAt I'm applying.

Hi,

 

 

As i was suspected u have to apply DIP on outgoing interface not on tust interface.

 

Cheers!!!

Your problem is you've applied the DIP to the wrong interface. DIP is always applied to the egress interface, not the ingress interface. Try applying your DIP on ethernet0/0 instead.

 

-Richard

I could have sworn I'd tried that but you were spot on. That works fine. Thanks both very much for all your help,it's really appreciated.

Right now I'm going to try and include a VPN on this policy, wish me luck and expect another post in a few minutes. 😉

And no need for any help on that, it worked straight away.

 

Again, thanks very much.

hi,

 

Thats good 🙂 but u mark ur own post as Accepted Solution

Oops! Sorry. 😉 It's been a very long weekend.