[j-nsp] Default SRX Behaviour
Paul Stewart
paul at paulstewart.org
Thu Aug 5 15:30:39 EDT 2010
Thanks - it's looking like 1800 seconds....
paul at dis2.millbrook1> show security flow session destination-prefix
216.168.xxx.xxx
Session ID: 434890, Policy name: Linux-to-Internet/8, Timeout: 1800
In: 216.168.xx.xxx/37820 --> 216.168.xxx.xxx/9103;tcp, If: vlan.11
Out: 216.168.xxx.xxx/9103 --> 216.168.xx.xxx/37820;tcp, If: ge-6/0/23.0
Paul
-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net] On Behalf Of Scott T. Cameron
Sent: Thursday, August 05, 2010 1:57 PM
To: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] Default SRX Behaviour
What is the timeout for the relevant policy/application set at?
@sdc01fw01a> show security flow session destination-prefix 172.30.249.189
node0:
--------------------------------------------------------------------------
Session ID: 120144688, Policy name: VPN/354, State: Active, Timeout: 1780
In: 172.30.84.106/54607 --> 172.30.249.189/22;tcp, If: reth1.9
Out: 172.30.249.189/22 --> 172.30.84.106/54607;tcp, If: reth7.0
1 sessions displayed
I've got a 30 minute timeout on my ssh session.
Scott
On Thu, Aug 5, 2010 at 1:19 PM, Paul Stewart <paul at paulstewart.org> wrote:
> Thanks very much - have had a few offline replies already. We're trying a
> few of these suggestions one step at a time. Bacula apparently has a
> "heartbeat" option which is supposed to resolve that particular issue -
> we're testing now.
>
> Appreciate all the responses - nice to know this isn't a completely
> isolated
> behavior...
>
> Paul
>
>
> -----Original Message-----
> From: Michael Damkot [mailto:mdamkottwc at gmail.com]
> Sent: Thursday, August 05, 2010 1:06 PM
> To: Paul Stewart
> Cc: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] Default SRX Behaviour
>
> Paul-
>
> I was having some similar events as far as your TCP session issues...
>
> I found a work around by using:
> set security flow tcp-session rst-invalidate-session.
>
>
> Not sure if it's the perfect solution, but it did seem to solve our
similar
> issue.
>
>
> On Aug 5, 2010, at 09:59 , Paul Stewart wrote:
>
> > Hi there..
> >
> >
> >
> > We just deployed an SRX650 in front of some servers recently - at this
> > point it's doing nothing more than routing + running screen on inbound
> > traffic. No other UTM features are enabled at this point.
> >
> >
> >
> > Configuration is pretty "stock" but we're running into a few issues.
> First
> > the relevant config:
> >
> >
> >
> > security {
> >
> > idp {
> >
> > security-package {
> >
> > url https://services.netscreen.com/cgi-bin/index.cgi;
> >
> > }
> >
> > }
> >
> > screen {
> >
> > ids-option Internet-Inbound {
> >
> > icmp {
> >
> > ping-death;
> >
> > }
> >
> > ip {
> >
> > source-route-option;
> >
> > tear-drop;
> >
> > }
> >
> > tcp {
> >
> > syn-flood {
> >
> > alarm-threshold 1024;
> >
> > attack-threshold 200;
> >
> > source-threshold 1024;
> >
> > destination-threshold 2048;
> >
> > timeout 20;
> >
> > }
> >
> > land;
> >
> > }
> >
> > }
> >
> > }
> >
> > zones {
> >
> > security-zone Internet {
> >
> > screen Internet-Inbound;
> >
> > interfaces {
> >
> > ge-6/0/23.0 {
> >
> > host-inbound-traffic {
> >
> > system-services {
> >
> > ssh;
> >
> > snmp;
> >
> > ping;
> >
> > traceroute;
> >
> > }
> >
> > protocols {
> >
> > ospf;
> >
> > }
> >
> > }
> >
> > }
> >
> > }
> >
> > }
> >
> > security-zone Linux {
> >
> > interfaces {
> >
> > vlan.11 {
> >
> > host-inbound-traffic {
> >
> > system-services {
> >
> > ping;
> >
> > }
> >
> > }
> >
> > }
> >
> > }
> >
> > }
> >
> >
> >
> >
> >
> > policies {
> >
> > from-zone Internet to-zone Linux {
> >
> > policy Internet-to-Linux {
> >
> > match {
> >
> > source-address any;
> >
> > destination-address any;
> >
> > application any;
> >
> > }
> >
> > then {
> >
> > permit;
> >
> > }
> >
> > }
> >
> > }
> >
> > from-zone Linux to-zone Internet {
> >
> > policy Linux-to-Internet {
> >
> > match {
> >
> > source-address any;
> >
> > destination-address any;
> >
> > application any;
> >
> > }
> >
> > then {
> >
> > permit;
> >
> > }
> >
> > }
> >
> > }
> >
> >
> >
> >
> >
> > The problem is a couple of things that we've noticed so far. the first
is
> a
> > minor issue with inactivity - if I have a SSH session open to one of
> these
> > servers and let it sit for approximately 2 minutes then the connection
> > drops. The SSH configuration on the boxes is set to 10 minutes of
> > inactivity which worked well before the SRX was implemented.
> >
> >
> >
> > The second issue is alarming us - we run Bacula for server backups. The
> > actual Bacula server is remote from this network (not on the same subnet
> or
> > attached to the SRX logically/physically). Some of the servers are
> backing
> > up just fine (smaller datasets) but some of these servers which contain
> > larger amounts of backup data are timing out after an hour or more of
the
> > backup working - something is stopping the data transfer in the middle.
> >
> >
> >
> > We removed the "screen" process on the security-zone but that made no
> > difference - now I'm thinking there is some default settings that are
> > causing this but not sure where to look.
> >
> >
> >
> > Model: srx650
> >
> > JUNOS Software Release [10.0R3.10]
> >
> >
> >
> > Any thoughts? Appreciate it.
> >
> >
> >
> > Paul
> >
> >
> >
> >
> >
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
More information about the juniper-nsp
mailing list