On 06/30/2011 09:41 AM, [email protected] wrote:
Hello Kevin,
...
I don't know if you can help with this or not, but I've set up a Debug
flow filter on the ISG1000 to see the sessions going through the
ISG1000. The xx.yy.5.46 is the address I gave to the Laptop and the
aa.bbb.63.5 is the server I'm trying to reach. I can see the connexion
being received from the VPN tunne 434 which is the right tunnel for this
connexion, it finds the correct route to the server and forwards it to
the right interface but the return is, I think, where the problem is, it
finds an existing session for the connexion which is the right one, then
I see the following: going into tunnel 4000021f. I don't know why it
won't go into the tunnel 434 or if 4000021f refers to tunnel 434.
If it refers to the tunnel 434 then I'm lost, as I get no response on
the laptop. I've compared this debug with an other one that have a
similar setup, in the other scenario, it refers to the tunnel number and
not to a weird tunnel ID like the one in this example.
pak from tunnel 0x4000021f
pak from tunnel, tunnel=4000021f
**st: <VPN|tunnel.434|Root|0>
4d9c144:
2b19:xx.yy.5.46/600->aa.bbb.63.5/300,1,60
****** 17928694.0: <VPN/tunnel.434>
packet received [60]******
ipid = 11033(2b19), @04d9c144
packet passed sanity check.
flow_decap_vector IPv4 process
packet decapsulated, type=ipsec, len=60
ipid = 11033(2b19), @04d9c144
tunnel.434:xx.yy.5.46/768->aa.bbb.63.5/1536,1(8/0)<Root>
no session found
flow_first_sanity_check: in
<tunnel.434>, out <N/A>
chose interface tunnel.434 as
incoming nat if.
flow_first_routing: in <tunnel.434>,
out <N/A>
search route to (tunnel.434,
xx.yy.5.46->aa.bbb.63.5) in vr
trust-vr for vsd-0/flag-0/ifp-null
[ Dest] 8.route
aa.bbb.63.5->10.120.132.1, to
ethernet1/1
routed (x_dst_ip aa.bbb.63.5) from
tunnel.434 (tunnel.434 in 0) to
ethernet1/1
policy search from zone 1000-> zone 2
policy_flow_search policy search
nat_crt from zone 1000-> zone 2
RPC Mapping Table search returned 0
matched service(s) for (vsys Root,
ip aa.bbb.63.5, port 17500, proto 1)
No SW RPC rule match, search HW rule
swrs_search_ip: policy matched
id/idx/action = 63/110/0x9
Permitted by policy 63
No src xlate choose interface
ethernet1/1 as outgoing phy if
check nsrp pak fwd:
in_tun=0x4000021f, VSD 0 for out ifp
ethernet1/1
no loop on ifp ethernet1/1.
session application type 0, name
None, nas_id 0, timeout 60sec
service lookup identified service 0.
flow_first_final_check: in
<tunnel.434>, out <ethernet1/1>
SM_RULE:0
existing vector list 25-231c4004.
Session (id:520851) created for
first pak 25
flow_first_install_session======>
route to 10.120.132.1
arp entry found for 10.120.132.1
ifp2 ethernet1/1, out_ifp
ethernet1/1, flag 00800800, tunnel
ffffffff, rc 1
outgoing wing prepared, ready
handle tunnel reverse route
search route to (ethernet1/1,
aa.bbb.63.5->xx.yy.5.46) in vr
trust-vr for
vsd-0/flag-3000/ifp-tunnel.434
[ Dest] 513.route
xx.yy.5.46->xx.yy.5.46, to tunnel.434
route to xx.yy.5.46
going into tunnel.
ifp2 tunnel.434, out_ifp tunnel.434,
flag 00002801, tunnel 4000021f, rc 1
flow got session.
flow session id 520851
flow_main_body_vector in ifp
tunnel.434 out ifp ethernet1/1
flow vector index 0x25, vector addr
0x231c4004, orig vector 0x231c4004
vsd 0 is active
post addr xlation:
xx.yy.5.46->aa.bbb.63.5.
skipping pre-frag
no more encapping needed
packet send out to 0015f97bde46
through ethernet1/1
**st: <Trust|ethernet1/1|Root|0>
4c304c0:
6018:aa.bbb.63.5/600->xx.yy.5.46/300,1,60
****** 17928694.0:
<Trust/ethernet1/1> packet received
[60]******
ipid = 24600(6018), @04c304c0
packet passed sanity check.
flow_decap_vector IPv4 process
ethernet1/1:aa.bbb.63.5/1536->xx.yy.5.46/768,1(0/0)<Root>
existing session found. sess token 3
flow got session.
flow session id 520851
flow_main_body_vector in ifp
ethernet1/1 out ifp N/A
flow vector index 0x25, vector addr
0x231c4004, orig vector 0x231c4004
vsd 0 is active
post addr xlation:
aa.bbb.63.5->xx.yy.5.46.
skipping pre-frag
going into tunnel 4000021f.
flow_encrypt: enc vector=c077d4.
Hi Marie,
I apologize for my late response, I've been travelling the last month or so.
First off, tunnel 4000021f does seem to match up with tunnel.434 as this
line from the inbound packet suggests:
> ifp2 tunnel.434, out_ifp tunnel.434, flag 00002801, tunnel 4000021f, rc 1
However, once the packet goes into the tunnel, then I think the
addressing changes. The address that you were filtering on (xx.yy.5.46)
is the VPN client address ("inside" address), but once the packet goes
into the tunnel, the packet is then addressed to the host laptop
(Internet address). So you might also need to do flow filters on the
"outside" address to see if perhaps the Juniper is having problems
sending/routing to those addresses.
_______________________________________________
vpn-help mailing list
[email protected]
http://lists.shrew.net/mailman/listinfo/vpn-help
