Return Packets disappearing

[tsaunat]

I have a policy to tunnel between our two data centers for the most part this seems to be working great, but one paticular type of traffic seems to be disappearing and I can't understand why.

When I send udp 4644 traffic from my secondary datacenter to a specific server on my primary datacenter. The traffic times out. After following the traffic through each step of it's journey I've found that it finds it's way through the tunnel to the end computer and starts it's journey back. The machine right before the netscreen indicates that the packet was sent on my NS204, but I can find no indication that the netscreen recived it.

So the question is more a question of how to view all the traffic the netscreen is to determine why it might not be accepting the traffic, or perhaps reasons why it wouldn't be accepted (it should be accepted as stateful traffic, but it isn't) .

 

[Njetscreamer]

The answer is a little along the lines of how long is a piece of string.
From the start, have you

1) configured a service at both ends of the tunnel
2) setup a policy on both sides permitting this new service through.

What kind of tunnel is this , route based or policy based, if policy based is the policy at the top of the list, if route based have you added the route in the routing table specifying to use the tunnel.x interface bound to phase 2 of the tunnel.

If the answer to all of the above is yes then you will need to do the following.

NS200>set ff src-ip a.b.c.d dst-ip e.f.g.h dst-port 4644
NS200>debug flow basic

run those lines on both sides of your tunnel (if they are both netscreen) and then

NS200>get db str

this will output the packet flow to console for you.

to remove filters,
NS200>unset ff
NS200>undebug all

you may also if you need to post more info do the following and remove the gw ip's if required

get config | i service
get route ip e.f.g.h (if its a route based vpn)

If you need a hand , let me know.

Kind regards

Njetscreamer

 

[tsaunat]

That bit of advice was extreamly helpful thanks.
Now I'm getting in the debug log

****** 44564.0: <V1-Trust/ethernet1> packet received [38]******
ipid = 61652(f0d4), @d7802910
packet passed sanity check.
v1-trust:146.63.202.84/4644->146.63.193.143/4999,17<Root>
L2 packet drop: mac for self, but session is not for self.

I understand what that means (I think) but why would it happen, and paticularly why only on this one paticular set of traffic?

 

[Njetscreamer]

Tsaunat,

what version of code are you currently running , is it 5.2.0rx or earlier ? Also another thing that may be of note is how the vpn is configured (is it policy or route based as policy ordering becomes very important when it is policy based).

The other thing that would be of interest as this is a non-standard port is what protocol is this traffic running over.

The error message I have not come across before in this context so I am sorry I cannot help with that one. There are a lot a lot of troubleshooting steps you can take, such as checking the session tables

(get session | i <ip address or port for example>
and you can also drill down on the session info also if it can form at all.

Kind regards

Njetscreamer

 

[tsaunat]

It is policy based tunneling

Hardware Version: 110(0)
Firmware Version: 5.0.0r8.0 (Firewall+VPN)

Sorry should have mentioned earlier UDP traffic

will look at session info for more help.

 

[tsaunat]

Anybody have any ideas? Other traffic from these two IP's even traffic on this port is allowed. What does the message "L2 packet drop: mac for self, but session is not for self" mean? has it fallen out of a stateful session? Is there something wierd going on?

 

[tsaunat]

Also one other note I changed this to accept rather than tunnel and the traffic no longer was dropped. I'd perfer to be able to tunnel all traffic and all other traffic is tunneling fine just not this.

 

[Njetscreamer]

Tsaunat,

there may be something odd going on somewhere then, to be honest if this is a netscreen to netscreen tunnel, it may be easier to alter the config to be a route based tunnel and set you policies to permit instead of tunnel. This will still encrypt and tunnel the traffic but remove the headache. Actually its easier to maintain and less rigid going for a route based tunnel anyhow.

Regards

Njetscreamer

 

[tsaunat]

I will look into route based tunnels as I have never set it up that way before. Thanks for the help!