[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