[j-nsp] Default SRX Behaviour

[Paul Stewart]

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