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 <p...@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:mdamkot...@gmail.com] > Sent: Thursday, August 05, 2010 1:06 PM > To: Paul Stewart > Cc: juniper-nsp@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@puck.nether.net > > https://puck.nether.net/mailman/listinfo/juniper-nsp > > > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp