:? Will Route Based Netscreen work with Cisco Pix VPN??



  • I do not have problem to configure Policy Based on Netscreen and Cisco Pix VPN.  I tried to configue Policy Based on the Netscreen to work with Pix VPN but it’s not working.

    1-Will Route Based Netscreen work with Cisco Pix VPN??

    Thank You for your helps.



  • I have ready through these threads and see that there are some miss guided results here.

    router based VPN works from multiple networks behind your SSG / NS to multiple networks behind 3rd party PIX / asa / checkpoint you name it.

    I have used policy based in the pass and run into issue when 3rd parties upgrade their firewall / pushing you to set any tcp / or udp port on the vpn policy (not to secure)

    the trick with using routed vpn to solve this solution is the use of good old fashing policy based routings.

    basic guide here you go (asuming  your zones are set)
    Scenario:
    We have 2 subnets
    a. 10.81.0.0 Mgt-network Zone
    b. 10.30.0.0 LandingPad Zone
    both subnets need to reach……
    10.5.0.0
    10.7.0.0
    both these subnets need to reach
    10.81.0.0
    10.30.0.0

    Nescreen config strip down version:
    to reach 10.5.0.0 and 10.30.0.0 use one Peer gateway x.x.x.x

    create tunnel int (example)

    tunnel.int 100

    create static routes

    Set route 10.5/16 tunnel.100 GW 5.5.5.1
    Set route 10.5/16 tunnel.100 GW 5.5.5.2
    Set route 10.7/16 tunnel.100 GW 7.7.7.1
    Set route 10.7/16 tunnel.100 GW 7.7.7.2

    the 5.5.5.1 and 5.5.5.2 , 7.7.7.x means nothing in terms of a real ip its just used to bing the static route
    and HNTB table properly.

    Create Phase one info: will online need to do this once GW/Peer x.x.x.x
    Create phase two info: don’t forget need to create 4,
    use proxy id
    10.81/16 10.5/16 name for this for this example 10.81_to_CorpA
    10.81/16 10.7/16 name for this for this example 10.81_to_CorpB
    10.30/16 10.5/16 name for this for this example 10.30_to_CorpA
    10.30/16 10.7/16 name for this for this example 10.30_to_CorpB

    Next bind you tunnel interface to the phase two settings here:

    SET NHTB routes:

    set interface tunnel.100 nhtb 5.5.5.1 vpn 10.81_to_CorpA
    set interface tunnel.100 nhtb 5.5.5.2 vpn 10.81_to_CorpB
    set interface tunnel.100 nhtb 7.7.7.1 vpn 10.30_to_CorpA
    set interface tunnel.100 nhtb 7.7.7.2 vpn 10.30_to_CorpB

    Ok that is the first part just to get the VPN setup and nhtb table to match the static route table.

    Policy Based routes

    set access-list extended 9 src-ip 10.81.0.0/16 dst-ip 10.5.0.0/16 protocol any entry 1
    set access-list extended 10 src-ip 10.30.0.0/16 dst-ip 10.5.0.0/16 protocol any entry 1
    set access-list extended 13 src-ip 10.81.0.0/16 dst-ip 10.7.0.0/16 protocol any entry 1
    set access-list extended 14 src-ip 10.30.0.0/16 dst-ip 10.7.0.0/16 protocol any entry 1

    set match-group name 10_81_to_10_5
    set match-group 10_81_to_10_5 ext-acl 9 match-entry 1
    set match-group name 10_30_to_10_5
    set match-group 10_30_to_10_5 ext-acl 10 match-entry 1

    set match-group name 10_81_to_10_7
    set match-group 10_81_to_10_7 ext-acl 13 match-entry 1
    set match-group name 10_30_to_10_7
    set match-group 10_30_to_10_7 ext-acl 14 match-entry 1

    set action-group name 10_81_to_10_5
    set action-group 10_81_to_10_5 next-interface tunnel.100 next-hop 5.5.5.1 action-entry 1
    set action-group name 10_30_to_10_5
    set action-group 10_30_to_10_5 next-interface tunnel.100 next-hop 5.5.5.2 action-entry 1
    set action-group name 10_81_to_10_7
    set action-group 10_81_to_10_7 next-interface tunnel.100 next-hop 7.7.7.1 action-entry 1
    set action-group name 10_30_to_10_7
    set action-group 10_30_to_10_7 next-interface tunnel.100 next-hop 7.7.7.2 action-entry 1

    set pbr policy name Yournetwork_name_to_Office_All
    set pbr policy Yournetwork_name_to_Office_All match-group 10_81_to_10_5 action-group 10_81_to_10_5
    set pbr policy Yournetwork_name_to_Office_All match-group 10_30_to_10_5 action-group 10_30_to_10_5
    set pbr policy Yournetwork_name_to_Office_All match-group 10_81_to_10_7 action-group 10_81_to_10_7
    set pbr policy Yournetwork_name_to_Office_All match-group 10_30_to_10_7 action-group 10_30_to_10_7

    FINAL Step is to bind the PBR to the zone and interface you need.

    set int red1.1 pbr Yournetwork_name_to_Office_All
    set zone yourzonename Yournetwork_name_to_Office_All

    thats it you can scall to as many subnets on either side etc…



  • yes it’s part of the phase 1 . phase 2 is the crypto map & crypto ipsec transform-set  setting.

    junipoint thanks i know is question start off asking about PIX not ASA i just was giving him a heads up for a problem i ran into.



  • For ASA VPN configuration see:
    http://www.cisco.com/univercd/cc/td/doc/product/multisec/asa_sw/v_7_2/conf_gd/vpn/ike.htm#wp1042302

    The command you have listed is for v6.3 of PIX.



  • @forcerecon:

    you should enter this command on the pix. this is recommended by cisco tac no-xauth no-config-mode

    isakmp key ******** address x.x.x.x netmask 255.255.255.255 no-xauth no-config-mode

    Also just a heads up the ASA as problems with Netscreen VPN. I found that Policy-base vpn works more then route-base vpn just how cisco implements there vpn version. The ASA really has problems routing traffic behind a netscreen to ASA vpn so alway use policy-base.

    Hi Forcerecon,

    Thank you for the ASA head up.

    I am wonder, what it does for the options no-xauth no-config-mode?

    Also, is this the command below on the phase 1 for preshare key?

    isakmp key ******** address x.x.x.x netmask 255.255.255.255 no-xauth no-config-mode



  • you should enter this command on the pix. this is recommended by cisco tac no-xauth no-config-mode

    isakmp key ******** address x.x.x.x netmask 255.255.255.255 no-xauth no-config-mode

    Also just a heads up the ASA as problems with Netscreen VPN. I found that Policy-base vpn works more then route-base vpn just how cisco implements there vpn version. The ASA really has problems routing traffic behind a netscreen to ASA vpn so alway use policy-base.



  • @melibokus:

    To simplify things for yourself, and to make it work reliably in this situation, with a route based vpn you would need to override the proxy-id at both locations (the CE documentation suggests using 0.0.0.0/0).

    Yes, that’s how we are doing proxy-id if Netscreen to Netscreen devices.

    @melibokus:

    This is well documented on the Netscreen side but (not familiar with PIX) it’s not clear how this is done on the PIX or whether this is release dependent. Perhaps a PIX engineer can explain how this is done… Access Lists and Crypto Maps???

    So override the proxy-id’s with your route-based vpn and use policies to control the traffic, or go back to using policy based vpn instead.

    Good ideal.

    I have not try 0.0.0.0/0 (any) to 0.0.0.0/0 (any)  on the Pix yet.  I will try to see.

    Thanks.



  • To simplify things for yourself, and to make it work reliably in this situation, with a route based vpn you would need to override the proxy-id at both locations (the CE documentation suggests using 0.0.0.0/0).

    This is well documented on the Netscreen side but (not familiar with PIX) it’s not clear how this is done on the PIX or whether this is release dependent. Perhaps a PIX engineer can explain how this is done… Access Lists and Crypto Maps???

    So override the proxy-id’s with your route-based vpn and use policies to control the traffic, or go back to using policy based vpn instead.



  • @junipoint:

    General rules for VPN interoperability for 3rd party VPN devices with Netscreen:

    1. Use route-based VPN for all single Netscreen supernets (i.e. 10.0.0.0/8) to multiple protected subnets of the 3rd party firewall. Use (1) tunnel interface per remote protected subnet.

    2. If you cannot summarize all of your protected Netscreen subnets into (1) large supernet, or if your 3rd party needs to see each specific subnet in your VPN setup, then you need to use policy-based VPN. You can use service groups to limit the extent of services across the VPN tunnel, since a Service Group will be negotiated with a proxyid service of “any”. Policy-based VPNs can get very ugly if you have many subnets to many subnets VPN policies. Do not use Address Groups!

    Hint: NAT can help in these situations

    3. NHTB is designed for Netscreen-Netscreen VPN tunnels to limit Tunnel interface use. NHTB Interoperability with other vendors is not guaranteed.

    4. The pre-defined Standard and Compatible phase I and phase II proposals on Netscreen work with most vendors, except with many older Cisco routers/Pix firewalls in a default setup.

    Hi Junipoint,

    Thank you so much for your explainations.  I got it now.

    Questions:

    If the netscreen has two subnets, each subnet in each zone say DMZ1 with 172.20.0.0/16 and DMZ2 with 192.168.0.0/16 subnet; the Pix has one subnet 10.10.0.0/16, how do you use route based vpn  in this situation??

    Thanks.



  • General rules for VPN interoperability for 3rd party VPN devices with Netscreen:

    1. Use route-based VPN for all single Netscreen supernets (i.e. 10.0.0.0/8) to multiple protected subnets of the 3rd party firewall. Use (1) tunnel interface per remote protected subnet.

    2. If you cannot summarize all of your protected Netscreen subnets into (1) large supernet, or if your 3rd party needs to see each specific subnet in your VPN setup, then you need to use policy-based VPN. You can use service groups to limit the extent of services across the VPN tunnel, since a Service Group will be negotiated with a proxyid service of “any”. Policy-based VPNs can get very ugly if you have many subnets to many subnets VPN policies. Do not use Address Groups!

    Hint: NAT can help in these situations

    3. NHTB is designed for Netscreen-Netscreen VPN tunnels to limit Tunnel interface use. NHTB Interoperability with other vendors is not guaranteed.

    4. The pre-defined Standard and Compatible phase I and phase II proposals on Netscreen work with most vendors, except with many older Cisco routers/Pix firewalls in a default setup.



  • Hi Mindwise,

    I managed to make the route based vpn to work perfectly only one zone to one subnet at the Cisco PIX (both direction).

    However, if I need two zones in the Netscreen to one subnet at the Cisco Pix then -> Cisco subnet can communicate with Netscreen on both zone; problem the only one zone from Netscreen can communicate with Cisco Pix .

    Also using 2 nhtb statements.

    and

    set route 216.239.111.64/26 int tunnel.111 gateway 216.239.111.5

    If I make further progress I will let you know.

    Thanks again for your helps.



  • @mindwise:

    @ggcc:

    Hi Mindwise,

    1-True, but if the debug show packet being dropped then it will not send to destination. -> i did not see the second debug output stating a ‘drop’ it was all ‘into tunnel’, the first output was indeed ‘drop packet’
    –-skipping pre-frag
      going into tunnel 40000064.
      flow_encrypt: enc vector=8cb7a8.

    2007-02-01 10:07:00 : NHTB entry search no found: vpn none tif tunnel.111 nexthop 216.239.111.92—

    3-The Netscreen VPN tunnel is up but only receiving and return response packets from the Cisco Pix site.  I mean one way (not from Netscreen to Cisco Pix site).
    i still say that ‘not receiving a response does not mean that no request was sent’

    • however, i confirm that not sending a request will result in not receiving a respons , hehehe)

    4-It is not related to vpn but I am trying to say this verson 5.4.0r2 has bug; when you turn on the screenning on the zone and using extended ping (using source ip as interface of that zone), Packet will get drop.

    -I checked the 5.4r2 is the recommended release for this 5200 with MGT-2 board.

    Yes, well the 5.4r(1/2) are not the best releases ever, especially when you use virtualsystems.

    -I did on both trust-vr and untrust-vr for the

    set route 216.239.111.64/26 int tunnel.111 gateway 216.239.111.5

    but no improve yet.

    Thanks.

    Ah, two vr’s, that in fact could explain a lot. The thing with two vr’s is that in fact that that  ‘one way’ traffic is quite commonly possible (but usually the other way around.

    ARE you using two vr’s ? if so, if you entered the routes above identical on both vr’s, that cannot be correct.

    The relevant routes and zone/vr/interface distribution are interesting but maybe more that you’d like to share 😉

    Sorry i don’t have the answer 😞

    Try have a goo weekend anyway 😉

    ( i will )

    Mindwise,

    Thank you so much.  Yes for now it’s is two vr but we will have more vr that one of the reason we need the 5200.

    Have a nice weekend.



  • @ggcc:

    Hi Mindwise,

    1-True, but if the debug show packet being dropped then it will not send to destination. -> i did not see the second debug output stating a ‘drop’ it was all ‘into tunnel’, the first output was indeed ‘drop packet’
    –-skipping pre-frag
      going into tunnel 40000064.
      flow_encrypt: enc vector=8cb7a8.

    2007-02-01 10:07:00 : NHTB entry search no found: vpn none tif tunnel.111 nexthop 216.239.111.92—

    3-The Netscreen VPN tunnel is up but only receiving and return response packets from the Cisco Pix site.  I mean one way (not from Netscreen to Cisco Pix site).
    i still say that ‘not receiving a response does not mean that no request was sent’

    • however, i confirm that not sending a request will result in not receiving a respons , hehehe)

    4-It is not related to vpn but I am trying to say this verson 5.4.0r2 has bug; when you turn on the screenning on the zone and using extended ping (using source ip as interface of that zone), Packet will get drop.

    -I checked the 5.4r2 is the recommended release for this 5200 with MGT-2 board.

    Yes, well the 5.4r(1/2) are not the best releases ever, especially when you use virtualsystems.

    -I did on both trust-vr and untrust-vr for the

    set route 216.239.111.64/26 int tunnel.111 gateway 216.239.111.5

    but no improve yet.

    Thanks.

    Ah, two vr’s, that in fact could explain a lot. The thing with two vr’s is that in fact that that  ‘one way’ traffic is quite commonly possible (but usually the other way around.

    ARE you using two vr’s ? if so, if you entered the routes above identical on both vr’s, that cannot be correct.

    The relevant routes and zone/vr/interface distribution are interesting but maybe more that you’d like to share 😉

    Sorry i don’t have the answer 😞

    Try have a goo weekend anyway 😉

    ( i will )



  • Hi Mindwise,

    1-True, but if the debug show packet being dropped then it will not send to destination.

    3-The Netscreen VPN tunnel is up but only receiving and return response packets from the Cisco Pix site.  I mean one way (not from Netscreen to Cisco Pix site).

    4-It is not related to vpn but I am trying to say this verson 5.4.0r2 has bug; when you turn on the screenning on the zone and using extended ping (using source ip as interface of that zone), Packet will get drop.

    -I checked the 5.4r2 is the recommended release for this 5200 with MGT-2 board.

    -I did on both trust-vr and untrust-vr for the

    set route 216.239.111.64/26 int tunnel.111 gateway 216.239.111.5

    but no improve yet.

    Thanks.



  • @ggcc:

    Hi Mindwise,

    1. -I see the packets go to the Policy from Netscreen to Pix by looking at the policy number of byte sent but there is no number of byte receive.

    2)-Also the unix server when ping it reported 100% packet loss.

    3)-On the server back of the Cisco Pix site, I can even telnet to the Netscreen IP interface 10.195.4.1  (I open for management telnet on this interface).  When I change something inside the AutoIKE config, example remove the tunnel.111 while ping or telnet it will drop the ping or telnet session is halted.   This tell me the tunnel.111 is working one way from Cisco PIx to Netscreen and Not from Netscreen to PIX.

    Kida wonder why??  I am running the latest 5.4.0r2.0 (Firewall+VPN)

    1. I also thinking this version my have bug too.

    For example:  if you turn on the Screen IP spoofing on this version 5.4xxx ; from the zone that you are trying to ping using extended ping   (ping a.b.c.d  from e2/5.x).  It will drop all your ping this is really rediculus.  Juniper TAC and bunch of developers think this is the new feature that they found and implement in this version.  I think this is the bug.

    Thanks.

    1. That doesn’t mean traffic doesn’t reach the desitnation ‘per se’, it just means there is no return traffic.
    2. See #1
    3. Well, in fact that also means the netscreen vpn is working otherwise the packets would not be decrypted and the return traffic would not be encrypted.
    4. I am not sure i know what you are referring to here.
    • Not having seen your routing table makes it kind of hard to say whether it could be ‘counted’ as spoofing. I have not seen the config you use.

    However, the 5.4r2 is not a recommended release unless you use the MGt-2 boards with the 10G fibrecards and need 30GB throughput 😉

    I’m not sure 5.4r3 is out for your config, but if it is, it will be better than the 5.4r2.

    Let’s try one more thing:

    • in your route table, change the route to the tunnel.111 to reflect:

    216.239.111.64/26 int t.111 gateway 216.239.111.5

    on the t.111 get the nhtb to reflect:

    216.239.111.5 “vpntocisco”

    And give us one more flow basic output 🙂

    Cheers,

    M



  • Hi Mindwise,

    I am pretty sure that when I ping from the Netscreen or from a unix server behind the Netscreen on the subnet that has Proxy SA to the Remote Pix site, The Packets have never get to the destination.

    -I see the packets go to the Policy from Netscreen to Pix by looking at the policy number of byte sent but there is no number of byte receive.

    -Also the unix server when ping it reported 100% packet loss.

    -On the server back of the Cisco Pix site, I can even telnet to the Netscreen IP interface 10.195.4.1  (I open for management telnet on this interface).  When I change something inside the AutoIKE config, example remove the tunnel.111 while ping or telnet it will drop the ping or telnet session is halted.  This tell me the tunnel.111 is working one way from Cisco PIx to Netscreen and Not from Netscreen to PIX.

    Kida wonder why??  I am running the latest 5.4.0r2.0 (Firewall+VPN)

    I also thinking this version my have bug too.

    For example:  if you turn on the Screen IP spoofing on this version 5.4xxx ; from the zone that you are trying to ping using extended ping  (ping a.b.c.d  from e2/5.x).  It will drop all your ping this is really rediculus.  Juniper TAC and bunch of developers think this is the new feature that they found and implement in this version.  I think this is the bug.

    Thanks.



  • The ‘send’ debug shows the netscreen sending the traffic into the tunnel:
    “going into tunnel 40000064”, sounds like the right one to me, are you absolutely sure these packets don’t arrive at the c!$c0 ??

    debugging on a 5000series is somewhat tricky because the asic’s on the forwarding blades keep a lot hidden from the processor 😞

    If you take the ping from the netscreen and pickup from ‘skipping pre-frag’ i would have expected to see someting like:

    skipping pre-frag
      going into tunnel 40000004.
      flow_encrypt: pipeline.
    chip info: PIO. Tunnel id 00000004
    (vn2)  doing ESP encryption and size =136
    ipsec encrypt prepare engine done
    ipsec encrypt set engine done
    ipsec encrypt engine released
    ipsec encrypt done
            put packet(2c348a0) into flush queue.
            remove packet(2c348a0) out from flush queue.

    **** jump to packet:192.168.168.254->192.168.168.250
      out encryption tunnel 40000004 gw:192.168.168.250
      no more encapping needed
    flow_send_vector_, vid = 0, is_layer2_if=0
      send packet to traffic shaping queue.
      **** pak processing end.
      flow_ip_send: fde1:192.168.168.254->192.168.168.250,50 => trust(184) flag 0x320080, vlan 0
    pak has mac
      Send to trust (198)

    Now those parts missing in your output may very well be because you run it on a 5000 series, but maybe someone else can clarify that.

    there is a big difference in debug output because the first output (with 3 sa’s) was: “packet dropped, no way(tunnel) out”

    i’d like to think that the netscreen is sending the packets but i’m not sure because it’s a 5x00.

    Anyway to check on cisco whether it’s receiving anything ?

    What screenos version are you running ?

    M



  • Hi Mindwise,

    However I can ping from the Pix site to Netscreen site without any problem. Look like it’s one way.  There are policy 421 and 422 to full fill two ways.  Below is the debug on the NS5200 the packet sent from behind the Pix to the NS5200.

    st: <vpn_prod|tunnel.111|root|0>3d9c13c: 9467:216.239.111.92/1cd3->10.195.4.1/0,1,84
    ****** 03185.0: <vpn_prod tunnel.111="">packet received [84]
    ****
      ipid = 37991(9467), @03d9c13c
      packet passed sanity check.
      tunnel.111:216.239.111.92/0->10.195.4.1/7379,1(8/0) <root>no session found
      flow_first_inline_vector: in <tunnel.111>, out <n a="">chose interface tunnel.111 as incoming nat if.
      IP classification from tunnel: vsys Root
      flow_first_inline_vector: in <tunnel.111>, out <n a="">search route to (tunnel.111, 216.239.111.92->10.195.4.1) in vr untrust-vr for vsd-0/flag-0/ifp-null
      [ Dest] 23.route 10.195.4.1->0.0.0.0, to ethernet2/5.60
      routed (x_dst_ip 10.195.4.1) from tunnel.111 (tunnel.111 in 0) to ethernet2/5.60
      IP classification from non-shared dst if : vsys Root
    Cross vsys set nat crt vsys:Root, pak vsys:Root, vsys:Root, result:0
      policy search from zone 3005-> zone 3001
    policy_flow_search  policy search nat_crt from zone 3005-> zone 3001
      RPC Mapping Table search returned 0 matched service(s) for (vsys Root, ip 10.195.4.1, port 20891, proto 1)
      No SW RPC rule match, search HW rule
      Permitted by policy 421
      No src xlate  choose interface ethernet2/5.60 as outgoing phy if
      check nsrp pak fwd: in_tun=0x40000064, VSD 0 for out ifp ethernet2/5.60
      set interface ethernet2/5.60 as loop ifp.
      session application type 0, name None, nas_id 0, timeout 60sec
      service lookup identified service 0.
      flow_first_inline_vector: in <tunnel.111>, out <ethernet2 5.60="">existing vector list 25-347b7fa0.
      Session (id:999931) created for first pak 25
      loopback session processing
      post addr xlation: 216.239.111.92->10.195.4.1.
      flow_first_inline_vector: in <ethernet2 5.60="">, out <n a="">existing vector list 20-34657460.
      create a self session (flag 0x206), timeout=60sec.
      vector index1 25, vector index2 20
      existing vector list 25-347b7fa0.
      existing v6 vector list 25-346571e0.
      new vector index 25.
      existing vector list 20-34657460.
      loopback session created
      flow_first_install_session======>
      make_nsp_ready_no_resolve()
      search route to (self, 10.195.4.1->216.239.111.92) in vr untrust-vr for vsd-0/flag-3000/ifp-tunnel.111
      [ Dest] 13.route 216.239.111.92->0.0.0.0, to tunnel.111
      route to 216.239.111.92
      nsrp msg sent.
      flow got session.
      flow session id 999931
      packet is for self, copy packet to self
    copy packet to us.
    ****** 03185.0: <self self="">packet received [84]******
      ipid = 40785(9f51), @0ed003b4
    flow_self_vector2: send pack with current vid =0, enc_size:0
      processing packet through normal path.
      packet passed sanity check.
      self:10.195.4.1/7379->216.239.111.92/0,1(0/0) <root>Not IKE nor NAT-T nor ESP protocol.
      existing session found. sess token 8
      flow got session.
      flow session id 999931
      skip ttl adjust for packet from self.
      existing vector list 25-347b7fa0.
      skipping pre-frag
      going into tunnel 40000064.
      flow_encrypt: enc vector=8cb7a8.
      pak from tunnel 0x40000064
      pak from tunnel, tunnel=40000064
    st: <vpn_prod|tunnel.111|root|0>3d9c13c: 9468:216.239.111.92/1cd3->10.195.4.1/1,1,84
    ****** 03186.0: <vpn_prod tunnel.111="">packet received [84]
    ****
      ipid = 37992(9468), @03d9c13c
      packet passed sanity check.
      tunnel.111:216.239.111.92/1->10.195.4.1/7379,1(8/0) <root>no session found
      flow_first_inline_vector: in <tunnel.111>, out <n a="">chose interface tunnel.111 as incoming nat if.
      IP classification from tunnel: vsys Root
      flow_first_inline_vector: in <tunnel.111>, out <n a="">search route to (tunnel.111, 216.239.111.92->10.195.4.1) in vr untrust-vr for vsd-0/flag-0/ifp-null
      [ Dest] 23.route 10.195.4.1->0.0.0.0, to ethernet2/5.60
      routed (x_dst_ip 10.195.4.1) from tunnel.111 (tunnel.111 in 0) to ethernet2/5.60
      IP classification from non-shared dst if : vsys Root
    Cross vsys set nat crt vsys:Root, pak vsys:Root, vsys:Root, result:0
      policy search from zone 3005-> zone 3001
    policy_flow_search  policy search nat_crt from zone 3005-> zone 3001
      RPC Mapping Table search returned 0 matched service(s) for (vsys Root, ip 10.195.4.1, port 28726, proto 1)
      No SW RPC rule match, search HW rule
      Permitted by policy 421
      No src xlate  choose interface ethernet2/5.60 as outgoing phy if
      check nsrp pak fwd: in_tun=0x40000064, VSD 0 for out ifp ethernet2/5.60
      set interface ethernet2/5.60 as loop ifp.
      session application type 0, name None, nas_id 0, timeout 60sec
      service lookup identified service 0.
      flow_first_inline_vector: in <tunnel.111>, out <ethernet2 5.60="">existing vector list 25-347b7fa0.
      Session (id:999957) created for first pak 25
      loopback session processing
      post addr xlation: 216.239.111.92->10.195.4.1.
      flow_first_inline_vector: in <ethernet2 5.60="">, out <n a="">existing vector list 20-34657460.
      create a self session (flag 0x206), timeout=60sec.
      vector index1 25, vector index2 20
      existing vector list 25-347b7fa0.
      existing v6 vector list 25-346571e0.
      new vector index 25.
      existing vector list 20-34657460.
      loopback session created
      flow_first_install_session======>
      make_nsp_ready_no_resolve()
      search route to (self, 10.195.4.1->216.239.111.92) in vr untrust-vr for vsd-0/flag-3000/ifp-tunnel.111
      [ Dest] 13.route 216.239.111.92->0.0.0.0, to tunnel.111
      route to 216.239.111.92
      nsrp msg sent.
      flow got session.
      flow session id 999957
      packet is for self, copy packet to self
    copy packet to us.
    ****** 03186.0: <self self="">packet received [84]******</self></n></ethernet2></ethernet2></tunnel.111></n></tunnel.111></n></tunnel.111></root></vpn_prod></vpn_prod|tunnel.111|root|0></root></self></n></ethernet2></ethernet2></tunnel.111></n></tunnel.111></n></tunnel.111></root></vpn_prod></vpn_prod|tunnel.111|root|0>



  • Hi Mindwise,

    Now it’s only one goes thru tunnel.111

    Both pix and netscreen subnet are matched.

    Netscreen 10.195.4.0/22
    Pix          216.239.111.64/26

    If the proxy id local and remote are not matched then Phase 2 will not complete.

    The SA is active.
    but the debug show little diff.
    as below:

    NS5200:us-scl-fw3(M)-> get sa | inc 216.239.111.5
    00000064<  216.239.111.5  500 esp:3des/sha1 cf19c089  2433  403M A/-    -1 0
    00000064>  216.239.111.5  500 esp:3des/sha1 1b8479ff  2433  403M A/-    -1 0
    NS5200:us-scl-fw3(M)->

    NS5200:us-scl-fw3(M)-> get db st
      icmp embed extern: 66.222.155.233->216.231.195.252,3,3, intern: 216.231.195.252/11844->66.222.155.233/1026,17

    2007-02-01 10:06:58 : NHTB entry search no found: vpn none tif tunnel.111 nexthop 216.239.111.92

    ****** 01747.0: <secure ethernet2="" 5.60="">packet received [128]******
      ipid = 25221(6285), @0ecff434
      self:10.195.4.1/27184->216.239.111.92/1024,1(8/0) <root>ethernet2/5.60:10.195.4.1/27184->216.239.111.92/1024,1(8/0) <root>no session found
      flow_first_inline_vector: in <ethernet2 5.60="">, out <tunnel.111>chose interface ethernet2/5.60 as incoming nat if.
      IP classification from non-shared src if : vsys Root
      flow_first_inline_vector: in <ethernet2 5.60="">, out <tunnel.111>search route to (ethernet2/5.60, 10.195.4.1->216.239.111.92) in vr trust-vr for vsd-0/flag-0/ifp-null
      [ Dest] 13.route 216.239.111.92->0.0.0.0, to tunnel.111
      routed (x_dst_ip 216.239.111.92) from ethernet2/5.60 (ethernet2/5.60 in 0) to tunnel.111
      IP classification from non-shared dst if : vsys Root
    Cross vsys set nat crt vsys:Root, pak vsys:Root, vsys:Root, result:0
      policy search from zone 3001-> zone 3005
    policy_flow_search  policy search nat_crt from zone 3001-> zone 3005
      RPC Mapping Table search returned 0 matched service(s) for (vsys Root, ip 216.239.111.92, port 60929, proto 1)
      No SW RPC rule match, search HW rule
      Permitted by policy 422
      No src xlate ## 2007-02-01 10:06:58 : NHTB entry search no found: vpn none tif tunnel.111 nexthop 216.239.111.92
      choose interface ethernet2/1 as outgoing phy if
      check nsrp pak fwd: in_tun=0xffffffff, VSD 0 for out ifp tunnel.111
      vsd 0 is active
      no loop on ifp ethernet2/1.
      session application type 0, name None, nas_id 0, timeout 60sec
      service lookup identified service 0.
      flow_first_inline_vector: in <ethernet2 5.60="">, out <ethernet2 1="">existing vector list 25-347b7fa0.
      Session (id:999819) created for first pak 25
      flow_first_install_session======>
      nsrp msg sent.
      flow got session.
      flow session id 999819
      vsd 0 is active
      skipping pre-frag
      going into tunnel 40000064.
      flow_encrypt: enc vector=8cb7a8.

    2007-02-01 10:07:00 : NHTB entry search no found: vpn none tif tunnel.111 nexthop 216.239.111.92

    ****** 01749.0: <secure ethernet2="" 5.60="">packet received [128]******
      ipid = 23655(5c67), @0ecff434
      self:10.195.4.1/27684->216.239.111.92/1024,1(8/0) <root>ethernet2/5.60:10.195.4.1/27684->216.239.111.92/1024,1(8/0) <root>no session found
      flow_first_inline_vector: in <ethernet2 5.60="">, out <tunnel.111>chose interface ethernet2/5.60 as incoming nat if.
      IP classification from non-shared src if : vsys Root
      flow_first_inline_vector: in <ethernet2 5.60="">, out <tunnel.111>search route to (ethernet2/5.60, 10.195.4.1->216.239.111.92) in vr trust-vr for vsd-0/flag-0/ifp-null
      [ Dest] 13.route 216.239.111.92->0.0.0.0, to tunnel.111
      routed (x_dst_ip 216.239.111.92) from ethernet2/5.60 (ethernet2/5.60 in 0) to tunnel.111
      IP classification from non-shared dst if : vsys Root
    Cross vsys set nat crt vsys:Root, pak vsys:Root, vsys:Root, result:0
      policy search from zone 3001-> zone 3005
    policy_flow_search  policy search nat_crt from zone 3001-> zone 3005
      RPC Mapping Table search returned 0 matched service(s) for (vsys Root, ip 216.239.111.92, port 60429, proto 1)
      No SW RPC rule match, search HW rule
      Permitted by policy 422
      No src xlate ## 2007-02-01 10:07:00 : NHTB entry search no found: vpn none tif tunnel.111 nexthop 216.239.111.92
      choose interface ethernet2/1 as outgoing phy if
      check nsrp pak fwd: in_tun=0xffffffff, VSD 0 for out ifp tunnel.111
      vsd 0 is active
      no loop on ifp ethernet2/1.
      session application type 0, name None, nas_id 0, timeout 60sec
      service lookup identified service 0.
      flow_first_inline_vector: in <ethernet2 5.60="">, out <ethernet2 1="">existing vector list 25-347b7fa0.
      Session (id:999915) created for first pak 25
      flow_first_install_session======>
      nsrp msg sent.
      flow got session.
      flow session id 999915
      vsd 0 is active
      skipping pre-frag
      going into tunnel 40000064.
      flow_encrypt: enc vector=8cb7a8.

    2007-02-01 10:07:01 : NHTB entry search no found: vpn none tif tunnel.111 nexthop 216.239.111.92

    ****** 01750.0: <secure ethernet2="" 5.60="">packet received [128]******
      ipid = 14518(38b6), @0ed022b4
      self:10.195.4.1/27984->216.239.111.92/1024,1(8/0) <root>ethernet2/5.60:10.195.4.1/27984->216.239.111.92/1024,1(8/0) <root>no session found</root></root></secure></ethernet2></ethernet2></tunnel.111></ethernet2></tunnel.111></ethernet2></root></root></secure></ethernet2></ethernet2></tunnel.111></ethernet2></tunnel.111></ethernet2></root></root></secure>



  • Hi ggcc,

    Based on the output i’m seeing the NHTB is a problem in this case

    Is the destination-net for the vpn a /26 or higher, or did you use a /32 to reach the pix (since the gateway and the ip you ping are in the same subnet).

    I’d still try to first get 1 tunnel to work from the netscreen side, it should give less NHTB troubles.

    So please get the same deb.output as before but now with only one vpn boun to the tun.111
    And the nhtb entry is also welcome 😉

    remember that proxy-id and actual ip’s going through the tunnel (for a netscreen, especially route-b-vpn, dont have to match)

    Cheers,

    m


 

31
Online

38.5k
Users

12.8k
Topics

44.5k
Posts