On 28/05/13 14:57, Phil Mayers wrote:
I have my suspicions about what exactly the ALG is (mis)counting as a
drop, and will be trying to reproduce it on the bench now it's been
taken out of service.
All,
Just to confirm that, as tested on the bench on SRX 3600 and JunOS
12.1R6.5 *all*
Side note on the DNS ALG, RHEL 6 doesn't like the SRX DNS ALG. RHEL 6 makes
both A and lookups for each name resolution in the same connection,
resulting in two requests being sent out, one response being received and
the session closing, cutting off the second response. This causes a 5-10
On 29/05/2013 20:24, Morgan McLean wrote:
Side note on the DNS ALG, RHEL 6 doesn't like the SRX DNS ALG. RHEL 6
makes both A and lookups for each name resolution in the same
connection, resulting in two requests being sent out, one response being
received and the session closing, cutting
Ya, I'm not saying it's specific to RHEL 6, but we realized the proverbial
pain in the ass when we started doing some early testing with it.
Interestingly enough, we didn't hit the issue on our core firewall, it was
only when coming from the edge firewall. The edge is a 650 cluster running
See if this article helps you (juniper login required)
http://kb.juniper.net/InfoCenter/index?page=contentid=KB16509smlogin=true
On Tue, May 28, 2013 at 2:41 AM, Phil Mayers p.may...@imperial.ac.ukwrote:
On 05/27/2013 03:45 PM, OBrien, Will wrote:
Are you using any alg?
Ah ha... thanks
On 28/05/13 19:40, ashish verma wrote:
That said, I can't believe the firewall was *actually* dropping 1500pps of
DNS traffic; we'd have widespread problems reported, surely. So, it seems
that maybe ALG-processed traffic is being counted under packets dropped
for show security flow statistics?
The primary use of the dns alg is to reduce session count. This is very
apparent on net screens. I reduced 500k sessions down to 400k by turning it on.
That said, you can achieve similar results by setting dns specific policies
with short timeouts.
Will
On May 28, 2013, at 8:41 AM, Julien
On 28/05/13 14:40, Julien Goodwin wrote:
On 28/05/13 19:40, ashish verma wrote:
That said, I can't believe the firewall was *actually* dropping 1500pps of
DNS traffic; we'd have widespread problems reported, surely. So, it seems
that maybe ALG-processed traffic is being counted under packets
On 28/05/13 14:51, OBrien, Will wrote:
The primary use of the dns alg is to reduce session count. This is
very apparent on net screens. I reduced 500k sessions down to 400k by
turning it on. That said, you can achieve similar results by setting
dns specific policies with short timeouts.
Out of
22.05.2013 21:01, Phil Mayers wrote:
How can I determine what the dropped packets are, and why they're
being dropped?
show interfaces extensive and check out Flow error statistics
(Packets dropped due to):
Another place to look at: show security screen statistics zone/iface.
On 05/27/2013 10:41 AM, Pavel Lunin wrote:
22.05.2013 21:01, Phil Mayers wrote:
How can I determine what the dropped packets are, and why they're
being dropped?
show interfaces extensive and check out Flow error statistics
(Packets dropped due to):
Nothing in there corresponding to the
On 27/05/2013 10:44, Phil Mayers wrote:
On 05/27/2013 10:41 AM, Pavel Lunin wrote:
22.05.2013 21:01, Phil Mayers wrote:
How can I determine what the dropped packets are, and why they're
being dropped?
show interfaces extensive and check out Flow error statistics
(Packets dropped due to):
27.05.2013 13:44, Phil Mayers wrote:
show interfaces extensive and check out Flow error statistics
(Packets dropped due to):
Nothing in there corresponding to the numbers/rates I'm seeing on the
show security flow statistics
If users are complaining, try to understand what exactly they have
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
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
On 05/27/2013 03:45 PM, OBrien, Will wrote:
Are you using any alg?
Ah ha... thanks for the nudge. The ALG settings are SRX-defaults:
admin@srx-eval show security alg status
ALG Status :
DNS : Enabled
FTP : Enabled
H323 : Disabled
MGCP : Disabled
MSRPC: Enabled
Hey Phil,
A friendly hello from Lancaster Uni, also using SRX 3600's.
Can you reproduce the loss? Or alternatively know source/destination ranges of
likely connections? A user it's more likely to affect or can demonstrate it
reliably?
As pretty much unless this is a policy that's doing it (if
On 24/05/13 11:33, Wood, Peter (ISS) wrote:
Hey Phil,
A friendly hello from Lancaster Uni, also using SRX 3600's.
Can you reproduce the loss? Or alternatively know source/destination
ranges of likely connections? A user it's more likely to affect or
can demonstrate it reliably?
Depends what
- Original Message -
From: Phil Mayers p.may...@imperial.ac.uk
To: Wood, Peter (ISS) p.w...@lancaster.ac.uk
Cc: juniper-nsp@puck.nether.net
Sent: Friday, May 24, 2013 12:02 PM
Subject: Re: [j-nsp] SRX 3600 dropped packets - how to debug?
At the moment, the SRX is sitting in front
On 24/05/13 16:05, Alex Arseniev wrote:
At the moment, the SRX is sitting in front of our personally owned
VRF; this means all our wireless and wired laptops, and RAS VPN
address ranges.
If You run any kind peer-to-peer apps (uTorrent, eMule, etc, also
includes Skype) then You'll see that
We've got an SRX 3600 in for testing. It's a simple config - two
interfaces, one in untrust and another in trust, and two permit-all
policies. No app-firewall, screens or other oddness.
The device is logging a *lot* of dropped packets:
Flow Statistics Summary:
System total valid
21 matches
Mail list logo
