[j-nsp] SRX 3600 dropped packets - how to debug?

[OBrien, Will]

You never sent your policy to the list. Is there traffic being routed inside your zones? Do you have a trust to trust permit policy for example? Are you using any alg? Have you used trace options to determine what's dropping? Are you allowing assymetric traffic flows across the cluster? Have you had a user pull a capture using wire shark to show you what's dropping? Are you using nat at all? If so what? It's very easy to shoot yourself in the foot with nat. Have you checked your chassis cluster health? Any system alarms? 

Will

On May 27, 2013, at 5:15 AM, "Pavel Lunin" <plunin at senetsy.ru> wrote:

> 
> 
> 24.05.2013 19:05, Alex Arseniev wrote:
>> If You run any kind peer-to-peer apps (uTorrent, eMule, etc, also
>> includes Skype) then You'll see that outside peers trying to establish
>> LOADS of unsolicited connection to Your inside hosts.
>> And all of them will be dropped unless You enable full cone NAT.
> 
> A bit off topic, but seems to be worth to note here as I've seen it
> several times.
> 
> Often people don't have a route for source NAT pools (especially in case
> of static routing). This leads to the following. When a disallowed
> connection from outside comes, it matches a default route, than a policy
> checkout occurs and, if untrust-to-untrust policy permits it (for some
> reason; say, folks managing NAT for broadband access tend to not bother
> with policies and just permit all everywhere), you have 1) a routing
> loop 2) session table flooded with this trash. Even if there is no
> permitting policy for untrust-to-untrust, this anyway leads to
> additional performance consumption due to policy checkup. So the best is
> to nail it down with a route like "nat-pool/xx -> deny" in order to drop
> the unwanted incoming connections as early as possible.
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp