Re: [j-nsp] SSH version 4 vulnerability on JUNOS
I've checked in with Juniper CERT a couple of times after SSH vulnerabilities get made public and given the fact they run such older ssh binaries. The answer i've received every time is they run a modified version of OpenSSH 4.4, and disallow unsigned, third party or modified binaries to run under Junos by default. With that said, I wouldn't really worry about an X11 session hijacking vulnerability.. given you don't have X11 installed on your device. This seems like a generic scan report that looks for anything under OpenSSH 5.0 and just tells you to upgrade. I think you're safe to ignore here Harri. Hope this helps, -Tim Eberhard On Mon, Sep 9, 2013 at 9:16 AM, Harri Makela wrote: > Hi There > > I got following report from after the vulneraboility scanning. Now first > we don`t use IPv6 and secondly how we can check on Juniper that versio is > SSH 4? > > > Synopsis: The remote SSH service is prone to an X11 session > hijacking\nvulnerability. > > Description: According to its banner, the version of SSH installed on the > remote host is older than 5.0. Such versions may allow a local user to > hijack X11 sessions because it improperly binds TCP ports on the local IPv6 > interface if the corresponding ports on the IPv4 interface are in use. > > Solution : Upgrade to OpenSSH version 5.0 or later. > > This is what I have searched on ex-8208 switch and came for SSH:- > > > set system services ssh root-login deny > set system services ssh protocol-version v2 -> it says version 2 > > > Sorry if these are too basic questions as I am new to all this. > > Thanks > HM > ___ > 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
Re: [j-nsp] Flow Session Analyzer
I assume you're talking about my tool? SRX or Netscreen? If you're talking about the SRX version OSX can run the native python source. You'll just need to download python 3.x. You can find a copy of the source code here: https://github.com/xmin0s/SRX-Session-Analyzer Just grab the 3 files, run it via python (e.g. python3 SRX-Session-Analyzer-GUI.py) from the command line and it'll run as normal. You can change it to open up directly by right clicking the python file, click get info and changing the "open with" to python3 launcher. Then it should run by just clicking it. As far as the compiled windows versions I took a look at the hosting provider and it should be fixed shortly. Although you can just download python3 on windows and run it from the python file as well. It's all the same .py file originally, I just compile it into an exe so users don't have to have python installed. Thanks, -Tim Eberhard On Tue, Aug 13, 2013 at 8:37 AM, Franco Ghashehbaba wrote: > Hello everyone, > > I'm trying to get Flow Session Analyzer for Mac OS, I have been seeing lots > of link but at the end > I can not get it. Dose anyone has actual program so I can install it? > > > Franco > ___ > 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
Re: [j-nsp] SRX210 + AppTrack. How to analyse?
I gave a talk on this at the bajug2. There are a couple of ways to do this, take a look at the slides from my talk. found here: http://www.slideshare.net/timeberhard/tim-eberhard-bajug3talk It also covers a tool I wrote to analyze the session tables and syslog messages for top talkers. Sure, in my example I used STRM but in reality you can use one of the many open source netflow analyzers. Hope this helps, Tim Eberhard On Sun, Aug 11, 2013 at 10:11 PM, Skeeve Stevens < skeeve+juniper...@eintellegonetworks.com> wrote: > Hey all, > > I have a customer in a bandwidth sensitive location (expensive and slow), > and they would like to know what is going through their device, and who is > doing it. > > In Cisco terms, this was NBAR - we used it many times to track down > bandwidth hogs. > > This is a small branch site using a SRX210H, and obviously STRM is too > expensive for a reporting engine. > > So what I am looking for is... How can we look at their device, and see > what is happening (preferably live) on a protocol and user (IP?) basis. > > I understand it can export to syslog, but that just gives me lots of text > to deal with... nothing that is easy to look at. > > Thank you for helping out guys! > > ...Skeeve > > *Skeeve Stevens - *eintellego Networks Pty Ltd > ske...@eintellegonetworks.com ; www.eintellegonetworks.com > > Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve > > facebook.com/eintellegonetworks ; <http://twitter.com/networkceoau> > linkedin.com/in/skeeve > > twitter.com/networkceoau ; blog: www.network-ceo.net > > > The Experts Who The Experts Call > Juniper - Cisco - Cloud > ___ > 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
Re: [j-nsp] srx240 VPN Question
There are two methods possible ways of doing this (to me). 1) Stand up two VPN tunnels and just have one down at all times. You would use your existing configuration (assuming it's main mode) and just change the source IP where you expect the VPN initiator to come from. 2) Change your existing main mode vpn into an aggressive mode VPN. This way you can local identity authenticate based upon FQDN and the IP check of the initiator doesn't take place. This might help: http://www.juniper.net/techpubs/software/junos-security/junos-security10.2/junos-security-swconfig-security/topic-40777.html On Wed, May 11, 2011 at 7:53 AM, Pappas, AJ wrote: > I have a srx240. I have someone who has a vpn with us who wants to change > from a static IP address on an ipsec tunnel to a FQDN. Is there any > documentation on how to do this or if it is possible? He is able to > provide the two ip’s to me that it will be coming from. This is for a > failover from them. Two separate providers / ip’s. > > ** ** > > *AJ Pappas * | Network Administrator ** > > *Ottawa Regional Hospital & Healthcare Center* > [image: Description: Description: Description: logo]** > > > www.ottawaregional.org | apap...@ottawaregional.org > *phone:* 815.431.5180 | *mobile line: *815.993.8522 > 1100 East Norris Drive, Ottawa, IL 61350 USA > > ** ** > > *P* Please consider the environment before printing this e-mail. > > ** ** > > ** ** > > Confidentiality Notice: This e-mail may contain confidential information. > The information is intended only for the use of the recipient named above. > If you are not the intended recipient, you are hereby notified that any > disclosure, copying, distribution, or the taking of any action in reliance > on the contents of this information, except its direct delivery to the > intended recipient named above, is strictly prohibited. If you have > received this e-mail in error, please notify the sender of this and also > delete the e-mail from all systems this message is stored on. > > ** ** > > ___ > 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
Re: [j-nsp] SRX1400 opinions
Srx's have replication issues with large routing environments. Duplicating two full feeds to the redundant peer will take a long time. In some testing many hours. With that said the 1400 can do it. Just keep that one major caveat in mind when you want clustered fail over. Hope this helps, -Tim Eberhard On Apr 27, 2013, at 10:14 AM, James Howlett wrote: > Hello, > > I have a network build on J4350 and SRX240 and i need to upgrade. I was > thinking about switching two devices for SRX1400. > My network has 2 full bgp feeds and some peerings. We use about 150-200Mbps > average. Will SRX1400 be a good choice then? > > Best regards, > jim > > ___ > 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
Re: [j-nsp] J/SRX ICMP handling
Selective packet services is always an option assuming you're in a branch srx (650 and below). Basically just write a firewall filter that allows icmp with a then action of packet mode. Keeping track of icmp may not add any value but be aware with SPS you now lose NAT, screens and IDP (which you said you don't use already) but those may not be an issue in your environment. Hope this helps, Tim Eberhard On Apr 24, 2013, at 10:23 PM, Dale Shaw wrote: > Hi all, > > This post relates to a previous post of mine on asymmetrically routed > UDP traffic: > https://puck.nether.net/pipermail/juniper-nsp/2012-December/024878.html > > It seems as though a J/SRX in flow mode will drop ICMP packets such as > unreachable and ttl-exceeded if, after consulting the session table, > an entry corresponding to the header embedded in the ICMP packet is > not found. In other words, "I'm gonna drop any ICMP packets[1] I see > if I didn't handle the associated conversation". > > Assume I send a UDP packet between hosts "A" and "D" and it's routed > outbound via SRX "B", and for whatever reason an ICMP unreachable or > ttl-exceeded is generated (think traceroute). If that ICMP packet is > sent towards host "D" not via SRX "B" but via SRX "C", SRX "C" drops > it: > > (src/dst IPs replaced with "A" and "D") > Jan 23 14:53:45 14:53:44.938394:CID-00:FPC-11:PIC-01:THREAD_ID-27:RT: > st0.1033:"D"->"A", icmp, (3/3) > Jan 23 14:53:45 14:53:44.938424:CID-00:FPC-11:PIC-01:THREAD_ID-27:RT: > find flow: table 0x63ce7688, hash 494060(0x7), sa "D", da "A", sp > 33438, dp 47488, proto 17, tok 7 > Jan 23 14:53:45 14:53:44.938483:CID-00:FPC-11:PIC-01:THREAD_ID-27:RT: > packet dropped, no session found for embedded icmp pak > Jan 23 14:53:45 14:53:44.938495:CID-00:FPC-11:PIC-01:THREAD_ID-27:RT: > flow find session returns error. > > Seems like perfectly reasonable behaviour for a firewall, right? > Right, except when it's not :-) > > Can this behaviour be modified without fully or selectively running in > packet mode? I'm running JUNOS 10.4R11. > > Cheers, > Dale > > [1] Well, any ICMP packets that include a copy of the original > datagram's header: echo request/reply are forwarded (subject to being > permitted by security policy, of course). > ___ > 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
Re: [j-nsp] SRX upgrade procedure -ready for enterprise?
I would never, ever follow that KB. It's just asking for a major outage.. With that said, you have two options. 1) ISSU and 2) Reboot both close to the same time and take the hit. Depending on your hardware it might be 4 minutes, it might be 8-10 minutes. If option one is the path you choose to go keep in mind the limitations and I would suggest you test it in a lab well before you ever do it in production. ISSU on the SRX is still *very* new. Here is a list of limitations: http://kb.juniper.net/InfoCenter/index?page=content&id=KB17946&actp=RSS I've seen ISSU fail more than a couple of times when it was supposed to be fully supported. This caused us to take a hit, then have to reboot both devices anyways. So we ended up expecting a hitless upgrade and got 10 minutes of downtime anyways. If you're up for running bleeding edge code then maybe ISSU will work properly, but if availability is that critical you should have a lab to test this in. Good luck, -Tim Eberhard On Fri, Mar 8, 2013 at 9:50 AM, Andy Litzinger wrote: > We're evaluating SRX clusters as replacements for our aging ASAs FO pairs in > various places in our network including the Datacenter Edge. I was reading > the upgrade procedure KB: > http://kb.juniper.net/InfoCenter/index?page=content&id=KB17947 and started > to have some heart palpitations. It seems a complicated procedure fraught > with peril. Anyone out there have any thoughts (positive/negative) on their > experience on upgrading an SRX cluster with minimal downtime? > > thanks! > -andy > ___ > 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
Re: [j-nsp] Junos 12.3 Release Date
12.3, right on time. On Feb 2, 2013, at 1:40 PM, Paul Goyette wrote: > 12.3 has now been released. > > Yes, there was a posting delay due to PSN-2013-01-823, but > posting is now complete. > > >> -Original Message- >> From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp- >> boun...@puck.nether.net] On Behalf Of JP Velders >> Sent: Saturday, February 02, 2013 12:54 PM >> To: juniper-nsp@puck.nether.net >> Subject: Re: [j-nsp] Junos 12.3 Release Date >> >> >>> Date: Tue, 22 Jan 2013 18:07:53 +0100 >>> From: Andrei-Marius Radu >>> Subject: Re: [j-nsp] Junos 12.3 Release Date >> >>> As far as I am aware 12.3 will be released at the beginning of 2013 >>> and indeed it will be an EEOL release. >> >> The release notes and documentation have been put on-line already, >> probably due to the planned release date of Jan 31st 2013. I guess >> they might've delayed release due to PSN-2013-01-823, but that's >> speculation. >> >> For everyone who wants to know what's new or broken: >> http://www.juniper.net/techpubs/en_US/junos12.3/information- >> products/topic-collections/release-notes/12.3/index.html >> >> Kind regards, >> JP Velders >> ___ >> 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
Re: [j-nsp] SRX240H vs SRX240H2
I always thought the SRX240H was the memory upgraded version to the 240B (aka base). The 240H2 I believed has the memory upgrade and a faster (possibly just overclocked?) processor. Perhaps I am incorrect though. The H2 line is pretty new and I haven't touched one yet to compare. On Fri, Jan 18, 2013 at 6:09 PM, David Kotlerewsky wrote: > Same specs, just a memory upgrade. > > Sent from my iPhone > > On Jan 18, 2013, at 1:47 PM, Robert Hass wrote: > >> Hi >> What is difference between SRX240H and SRX240H2 except doubled memory/flash. >> I'm mostly interested are CPUs are same. >> >> Rob >> ___ >> 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
Re: [j-nsp] TCPDUMP on High-end SRX
That will *only* grab traffic to the control plane, not through the interfaces. For what its worth. -Tim Eberhard On Tue, Dec 11, 2012 at 12:24 PM, 叶雨飞 wrote: > monitor traffic no-resolve interface x write-file xxx.pcap > > or, if you prefer, simply start shell then tcpdump -i xxx -n -p -w > .pcap > > On Tue, Dec 11, 2012 at 9:00 AM, mahmoud yasin > wrote: > > Hi > > > > How to use TCPDump to capture the In/Out traffic from the firewall > interface (device self generated traffic). > > Also how to read the output using wireshark (how to get a copy of the > file)? > > This is required for High-end firewalls. > > > > Regards > > Myasin > > ___ > > 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
Re: [j-nsp] Weird SRX flow timeout issue
Benny, I've been working with the SRX since before it was in beta loading it up on a SSG550-M and netscreen previous to that. TCP keep alives, or any tcp packet that transverses that session has ALWAYS reset the timeout. The only time where you would see this "not working" is if you had a situation of asymmetric routing or some time of crazy load balancing through firewalls. This is a basic system function, and yes, tcp-syn-checking has everything to do with the session timeout problem. With tcp-syn-checking ANY data packet (keepalive, syn, ack, or a normal data packet) can create a new session, or in this case reestablish an existing connection. Just so it's crystal clear here.. If you have syn checking on: You open up a connection. Connection times out All additional data meant for that specific session is dropped and a reset is sent in an attempt to reinitiate the connection (assuming tcp-rst is configured). The 3 way hand shake MUST take place for a new session to be created. If you have syn checking off: You open up a connection. Connection times out The moment any data packet comes that is allowed by security policy a session is created. I hope this clears things up. If you still doubt this feel free to reference juniper's documentation. http://www.juniper.net/techpubs/software/junos-security/junos-security10.2/junos-security-swconfig-security/topic-44055.html -Tim Eberhard On Mon, Nov 12, 2012 at 3:25 PM, Benny Amorsen wrote: > Tim Eberhard writes: > >> The SRX's behavior is if any packet passes over that session to reset >> the timeout on that session, keep alive, data packet, whatever. As >> long as it matches that session it will reset the timeout to the >> default value and start decrementing again. So I'm not sure what you >> mean when it says dropping tcp sessions with active TCP keepalives. > > I proposed using TCP keepalives to keep sessions alive. Julien Goodwin > informed me that this did not work on the SRX, as of a few years ago. > > If that is fixed, all is well. > > None of which has anything to do with tcp-syn-checking. > > > /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Weird SRX flow timeout issue
The SRX's behavior is if any packet passes over that session to reset the timeout on that session, keep alive, data packet, whatever. As long as it matches that session it will reset the timeout to the default value and start decrementing again. So I'm not sure what you mean when it says dropping tcp sessions with active TCP keepalives. I've never had a problem where an application sent keepalives at a rate greater than the default time out (say time out is 30 minutes, keepalives are every 10 minutes). Then that session can last as long as it wants. This is expected behavior. -Tim Eberhard On Mon, Nov 12, 2012 at 1:43 PM, Benny Amorsen wrote: > Tim Eberhard writes: > >> While I haven't read this entire thread, it's worth mentioning that >> this is a correct statement. TCP connections (by default) must be >> initiated by a standard 3-way handshake. You can disabled this by >> turning off tcp-syn-checking under security -> flow. >> >> I wouldn't recommend it however, as enforcing proper TCP state is >> always a good security practice. > > Enforcing proper TCP state is certainly good security practice. Dropping > a TCP session with active TCP keepalives is simply buggy and wrong. > > That does not have anything to do with the 3-way handshake or > tcp-syn-checking which should be on. > > > /Benny ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Weird SRX flow timeout issue
While I haven't read this entire thread, it's worth mentioning that this is a correct statement. TCP connections (by default) must be initiated by a standard 3-way handshake. You can disabled this by turning off tcp-syn-checking under security -> flow. I wouldn't recommend it however, as enforcing proper TCP state is always a good security practice. -Tim EBerhard On Mon, Nov 12, 2012 at 1:07 PM, Benny Amorsen wrote: > Julien Goodwin writes: > >> Sadly SRX doesn't (or at least a few years ago didn't) consider TCP >> keepalives sufficient to keep the session open. > > Thank you for that heads-up, that is certainly something to keep in > mind. > > > /Benny > > > > > ___ > 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
Re: [j-nsp] SRX - tap mode?
High end SRX's support tap mode. Branch as far as I know do not. http://www.juniper.net/techpubs/software/junos-security/junos-security10.2/junos-security-swconfig-security/topic-45272.html Hope this helps, -Tim Eberhard On Wed, Sep 12, 2012 at 10:33 AM, William McLendon wrote: > hi everyone, > > do SRX firewalls support a "tap mode" installation? Really just looking at > it for purposes of evaluation of IDP functionality where tap mode would be > the least intrusive method to see data vs having to put it inline (and then > deal with the inevitable "you put a device inline and now XYZ doesn't work!") > > I seem to recall that they do not, and they have to be installed in L3 mode > or in Transparent mode, but was hoping I may have missed the feature in a > release note somewhere. > > Thanks, > > Will > ___ > 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
Re: [j-nsp] Best way to detect abnormal traffic without enabling security?
Additionally Netflow/jflow sampling would provide a greater level of insight. Careful with the sampling rate however as you don't want to make the ddos worse... There are lots of free and paid products that will analyze jflow. Juniper sells a Q1 labs product they call STRM. It does a great job. Hope this helps, Tim Eberhard On Sep 8, 2012, at 7:28 AM, Mark Radabaugh wrote: > My suggestion would be a managed Ethernet switch on whichever side of the > J2350 that you can put it with a SPAN port to dump traffic to Wireshark. It > should be fairly easy to spot the offending traffic. > > Mark > > > On 3/31/12 12:50 AM, Yucong Sun (叶雨飞) wrote: >> Hi, >> >> I am currently using a pair of J2350 exporting about 200+ /32 BGP >> route to my peer, and I'm been hit by DDOS several times, the hardest >> part for me is to figure out which IP was getting the DDOS and >> deactivate that route, which will de-announce that route to my peer. >> >> However I have no established method right now to figure out which IP >> is getting DDOSed, so I am hoping somebody can pass along some >> sampling or dump method to quickly identify toublesome dst ip. >> >> Thanks! >> ___ >> juniper-nsp mailing list juniper-nsp@puck.nether.net >> https://puck.nether.net/mailman/listinfo/juniper-nsp > > > -- > Mark Radabaugh > Amplex > > m...@amplex.net 419.837.5015 > > ___ > 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
Re: [j-nsp] SRX DNS Forwarding - helpers domain
A quick search on that error message says it's a return routing issue.
http://kb.juniper.net/InfoCenter/index?page=content&id=KB21363&cat=JUNOS&actp=LIST
-Tim Eberhard
On Tue, Jun 26, 2012 at 8:03 AM, f...@flipstar.net wrote:
> Hey everybody,
>
> I wonder if anybody is successfully using "forwarding-options helpers
> domain" (DNS) [1] on branch SRX?
>
> In my setup the client queries the srx which forwards the request to the dns
> server.
> The dns sends a reply that never passes the srx back to the client.
>
> Client SRX DNS
> 192.168.200.105 -> 192.168.200.1 -> 10.100.1.20
> x <-
>
> Junos 11.4R3.7
>
> pw@srx650-1# show forwarding-options helpers domain
> server 10.100.1.20;
> interface {
> reth0.1052;
> reth0.1053;
> reth0.1051;
> }
>
> The reply from the dns server is dropped in the srx :-(
>
>
> Jun 26 14:51:17
> 14:51:16.1467499:CID-1:RT:<10.100.1.20/53->192.168.200.105/51651;17> matched
> filter dns_to_cli:
> Jun 26 14:51:17 14:51:16.1467499:CID-1:RT:packet [68] ipid = 64549,
> @43e92fa4
> Jun 26 14:51:17 14:51:16.1467700:CID-1:RT: flow_process_pkt: (thd 4):
> flow_ctxt type 14, common flag 0x0, mbuf 0x43e92d80, rtbl_idx = 0
> Jun 26 14:51:17 14:51:16.1467700:CID-1:RT: flow process pak fast ifl 107
> in_ifp reth0.1051
> Jun 26 14:51:17 14:51:16.1467700:CID-1:RT: find flow: table 0x51f8bd18, hash
> 42509(0x), sa 10.100.1.20, da 192.168.200.105, sp 53, dp 51651, proto
> 17, tok 10
> Jun 26 14:51:17 14:51:16.1467768:CID-1:RT: flow got session.
> Jun 26 14:51:17 14:51:16.1467768:CID-1:RT: flow fast tcp/udp session id
> 268027
> Jun 26 14:51:17 14:51:16.1467784:CID-1:RT: route lookup failed: dest-ip
> 192.168.200.105 orig ifp .local..0 output_ifp reth0.1052 fto 0x492786e8
> orig-zone 2 out-zone 11 vsd 0
> Jun 26 14:51:17 14:51:16.1467784:CID-1:RT: packet dropped, pak dropped
> since re-route failed
>
> ^^^
> Jun 26 14:51:17 14:51:16.1467784:CID-1:RT: - flow_process_pkt rc 0x7 (fp
> rc -1)
>
>
> Regards
> flip
>
>
> [1]
> https://www.juniper.net/techpubs/en_US/junos11.4/topics/usage-guidelines/policy-configuring-dns-and-tftp-packet-forwarding.html
> ___
> 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
Re: [j-nsp] Whats the best way to announce an IP range in BGP? Doesn't physically exist anywhere.
While it's true that like all flow based devices the session table is susceptible to session table attacks. There are some major built in protection schemes put into place to limit the effectiveness and protect the SRX. For the record your proof of concept would take a lot of pps to fill up the session table given that it's UDP and UDP has a default time out of 60 seconds... You have source/destination based session limiting screens which are highly effective and handled in hardware. Syn flood protection, udp flood protection and others. Additionally you have the option to include aggressive age out of idle sessions in the event of the session table reaching the upper limits of capacity. In that event the session table will start aggressively removing idle sessions until it reaches a proper session table size. While no single feature is a silver bullet there are at least a good amount of options in the way of protecting your SRX session table and the SRX itself. Hardening your device to such attacks is critical if you are going to have any level of access in putting the SRX as your outside internet facing device. I 100% agree with Stefan by the way, using stateless firewall filters for a layered approach is also recommended if you plan on replacing your DIA router. For the record, using such stateless firewall filters there is no session built there is no passing go. The packet is just dropped to /dev/null (or null0 depending how you look at it). No session is ever created for traffic dropped by a firewall filter. I hope this helps, -Tim Eberhard On Mon, Jun 25, 2012 at 7:06 AM, Scott T. Cameron wrote: > On Mon, Jun 25, 2012 at 6:56 AM, Pavel Lunin wrote: > >> >> >> >> This is exactly what happened. The session table filled up. One of >> >> our security guys took down our edge 650 cluster from a single unix >> >> box out on the net. >> > This is what happens when you use a stateful box for an internet router. >> > >> > a router with a covering aggreate and some knowledge of the more >> > specifc on the interior would inexpensively discard traffic bound for >> > unreachable destinations. >> >> 1. First, sorry for writing this once again, but it's just not the case. >> Any more or less smart stateful device, whether SRX or anything else, >> must not create session states for packets falling under a discard >> route. And SRX does not, I checked. Filling up the session table is >> caused by either a bug or (rather) a design/config mistake. > > > I'm not sure I agree with this assessment. > > The SRX is very quick at disposing of invalid sessions, generally. > However, it is easily susceptible to DDOS if you let it reach the session > table. > > Here's some quick POC code: > > http://pastebin.com/FjgavSwn > > You can run this against some non-operational IPs, but present via, say, > discard route in your config. You will see the invalid sessions rise > dramatically via 'show sec flow sess sum'. > > I am no expert, but you can see how quickly this could be abused by someone > who was intent on disrupting your network -- and they wouldn't have to use > cheap perl code to do the job. > > Malicious user aside, a legitimate application trying to hit an invalid IP > would give the same result. Self-made DDOS are very common in my > experience. In one case, we had an "updater" application which would > update drivers and software for our hardware. It was installed on millions > of computers. One day, the service was shutdown and new software was > distributed with the products. Many users, however, never updated, and the > software was very aggressive in calling home. Without knowing this, a /24 > was pulled down to the SRX, and the updater instantly filled the session > table. > > Scott > ___ > 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
Re: [j-nsp] Problem Routing process doesn't work on SRX cluster
To expand on what scott said.
The routing daemon on the backup SRX (RG0 backup) doesn't run by
design. To handle some static routes out the fxp0 interface you can
set routes using the groups much like you configured the hostname and
such. It's well documented, feel free to give it a look if you haven't
already configured that.
Here is a quick link on how to set up routing on the back up SRX.
https://www.juniper.net/techpubs/en_US/junos/topics/reference/configuration-statement/backup-router-edit-system.html
Hope this helps,
-Tim Eberhard
On Tue, Jun 19, 2012 at 7:26 AM, Scott T. Cameron wrote:
> rpd is disabled on the backup node in a chassis cluster.
>
> You can set some routes through fpx0 using the groups node0/node1, but it
> has to be truly OOB.
>
> Scott
>
> On Tue, Jun 19, 2012 at 8:21 AM, Roland Droual
> wrote:
>
>> Hello the list,
>>
>>
>> I solve most of problems to ping from my SRX cluster.
>> But now, I have a new problem, because I did a lot of changes:
>> I don't have routing process on the cluster of site B.
>>
>>
>> toto@BA-SRX650-01# show chassis cluster
>> reth-count 6;
>> redundancy-group 0 {
>> node 0 priority 100;
>> node 1 priority 1;
>> }
>> redundancy-group 1 {
>> node 0 priority 100;
>> node 1 priority 1;
>> interface-monitor {
>> ge-6/0/19 weight 255;
>> ge-6/0/20 weight 255;
>> ge-6/0/21 weight 255;
>> ge-6/0/22 weight 255;
>> ge-6/0/23 weight 255;
>> ge-15/0/19 weight 255;
>> ge-15/0/20 weight 255;
>> ge-15/0/21 weight 255;
>> ge-15/0/22 weight 255;
>> ge-15/0/23 weight 255;
>> ge-6/0/18 weight 255;
>> ge-15/0/18 weight 255;
>> }
>> }
>>
>>
>> toto@BA-SRX650-01# run show chassis cluster status
>> Cluster ID: 1
>> Node Priority Status Preempt Manual failover
>>
>> Redundancy group: 0 , Failover count: 0
>> node0 100 secondary no no
>> node1 1 primary no no
>>
>> Redundancy group: 1 , Failover count: 0
>> node0 0 secondary no no
>> node1 0 primary no no
>>
>> toto@BA-SRX650-01> show route all
>> error: the routing subsystem is not running
>>
>>
>> toto@BA-SRX650-01> restart routing
>> error: Routing protocols process is not running
>> error: Routing protocols process was not restarted
>>
>> =
>> artere@BA-SRX650-01# run show chassis alarms
>> node0:
>> --
>> 1 alarms currently active
>> Alarm time Class Description
>> 2012-06-19 19:51:11 UTC Major PEM 0 Output Failure
>>
>> node1:
>> --
>> 1 alarms currently active
>> Alarm time Class Description
>> 2012-06-19 20:07:36 UTC Major PEM 0 Output Failure
>>
>> I don't know where I can find the solution. How can I solve the problem
>> about routing process doesn't work ?
>>
>> Thanks
>>
>> Roland
>>
>> ___
>> 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
Re: [j-nsp] Firewall best practices
Ben, let me introduce you to my little friend called the global address book. Introduced in 11.4. set security address-book global address p1 192.168.1.13/32 -Tim Eberhard On Mon, Jun 11, 2012 at 7:04 PM, Ben Dale wrote: > > What would really help though is if Junos allowed multiple address-books to > be bound to a single zone - that way, SRXs buried deeper in your network > would have access to all address-book entries on a single upstream zone with > very little configuration management. I'm sure this concept would make tools > like Space and NSM easier to use as well - Juniper SRX PLMs are you listening > out there? SAVE US! > > Cheers, > > Ben ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Firewall best practices
While I agree space is a decent viable option there are lots of limitations and caveats around the Space security designer product. Test it throughly before buying and know how it acts and what it does that will not work in your environment. Another thing worth mentioning is SD has been out less than a year. It's first release (re-release after being rewritten from scratch) was 11.4, most recently and greatly needed update is 12.1. I hope this helps, -Tim Eberhard On Mon, Jun 11, 2012 at 6:52 PM, Patrick Dickey wrote: > Morgan- I would take a good hard look at Junos Space's Security Design > package. Its has centralized address books, tier'd policy management, config > management, and VPN tools (among a ton of other features), all from a single > pane of glass. Ask your reseller for a demo or check it out online. The > information Juniper is publishing on the website may be a little out of date, > but there is more info available to your Juniper sales team. > > > HTH > > Patrick > > > > > From: Morgan McLean > To: juniper-nsp@puck.nether.net > Sent: Monday, June 11, 2012 5:18 PM > Subject: [j-nsp] Firewall best practices > > Hi everyone, > > I have a question regarding managing policies among multiple sets of > firewalls. I don't know what industry standard / best practice is for > managing rules among multiple devices. > > Currently our office has an srx cluster, site A has an edge srx cluster and > core srx cluster, and site B has an edge srx cluster and core srx cluster. > The edge srx clusters generally interface with border routers or providers > directly, IPSEC, DMZ and any outbound 3rd party web filter redirects etc. > The core srx clusters handle firewalling between our different > environments. Separating search engines, databases, web servers, etc etc. > > I don't know what the best way to manage the firewall rules is between > these sites. I don't think its sustainable to write the same rule on site A > core, site A edge, site B edge, site B core. And then managing the address > book entries on every device also becomes a hassle, making sure its > all synchronized etc. Is there a better method of doing this? > > I don't even want to think about what happens if I want traffic from the > office to route through site A in order to reach site B in the event of a > VPN issue between the office and site B directly. > > Is there a good method for keeping these things managed, like only having > the edge firewall for site A manage incoming connections, and let the other > sites edge firewall deal with site A's outgoing connections, etc? > > I'm a mess. If we add two more sites my head might explode. > > Morgan > ___ > 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
Re: [j-nsp] SRX650 - Failover - reth TRUNK with: vlan L2 mode transparent, and vlan L3
I can tell you with certainty that if you try to configure bridge
(which required a reboot). If any other families other than bridge are
configured it will error out upon commit. Flexible ethernet services
does not include bridge. As of today mixed mode does not work on any
SRX series device.
I hope this clears things up,
-Tim Eberhard
On Thu, May 31, 2012 at 9:05 AM, Per Granath wrote:
> Flexible Ethernet services should be supported since 10.1.
> http://www.juniper.net/techpubs/en_US/junos10.1/information-products/topic-collections/release-notes/10.1/topic-42298.html
>
> It should allow you to mix, at least, 'inet' and 'vlan-vpls' on the interface.
> Not sure if it will allow 'bridge', but in theory you could use vpls instead
> (if that works for cluster).
>
>> -Original Message-
>> From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-
>> boun...@puck.nether.net] On Behalf Of roland DROUAL
>> Sent: Thursday, May 31, 2012 3:06 PM
>> To: juniper-nsp@puck.nether.net
>> Subject: Re: [j-nsp] SRX650 - Failover - reth TRUNK with: vlan L2 mode
>> transparent, and vlan L3
>>
>> I can't try this command because it's not accepted.
>>
>> ==
>> {primary:node0}[edit interfaces reth0]
>> xyz@AS-SRX650-01# set encapsulation ?
>> Possible completions:
>> ether-vpls-ppp Ethernet VPLS over PPP (bridging) device
>> ethernet-bridge Ethernet layer-2 bridging
>> ethernet-ccc Ethernet cross-connect
>> ethernet-vpls Ethernet virtual private LAN service
>> extended-frame-relay-ccc Any Frame Relay DLCI for cross-connect
>> extended-frame-relay-tcc Any Frame Relay DLCI for translational cross-
>> connect
>> extended-vlan-bridge VLAN layer-2 bridging
>> extended-vlan-ccc Nonstandard TPID tagging for a cross-connect
>> extended-vlan-vpls Extended VLAN virtual private LAN service
>> frame-relay-port-ccc Frame Relay port encapsulation for a
>> cross-connect
>> vlan-ccc 802.1q tagging for a cross-connect
>> vlan-vpls VLAN virtual private LAN service
>> {primary:node0}[edit interfaces reth0]
>>
>> I give you the simple config which I can save. It's simply, but it's not
>> working. I
>> can't ping from inside (reth1.200) until outside (reth0.200) accross the
>> SRX650.
>>
>> reth0 {
>> description "TRUNK vers RAP";
>> vlan-tagging;
>> redundant-ether-options {
>> redundancy-group 1;
>> }
>> unit 200 {
>> vlan-id 200;
>> }
>> unit 954 {
>> vlan-id 954;
>> family inet {
>> address 195.221.127.158/30;
>> }
>> }
>> }
>> reth1 {
>> description "TRUNK vers INSIDE";
>> vlan-tagging;
>> redundant-ether-options {
>> redundancy-group 1;
>> }
>> unit 100 {
>> vlan-id 100;
>> family inet {
>> address 10.1.4.2/29;
>> }
>> }
>> unit 200 {
>> description INTER-SITES;
>> vlan-id 200;
>> }
>> }
>> security {
>> policies {
>> from-zone INTER-SITE to-zone INTER-SITE {
>> policy allow-test {
>> match {
>> source-address any;
>> destination-address any;
>> application any;
>> }
>> then {
>> permit;
>> }
>> }
>> }
>> }
>> zones {
>> security-zone INTER-SITE {
>> host-inbound-traffic {
>> system-services {
>> all;
>> }
>> protocols {
>> all;
>> }
>> }
>> interfaces {
>> reth0.200;
>> reth1.200;
>> }
>> }
>> ==
>>
>> Thanks for your help !
>>
>> Roland DROUAL
>>
>>
>> Try adding:
>>
>> set inter
Re: [j-nsp] SRX650 - Failover - reth TRUNK with: vlan L2 mode transparent, and vlan L3
Mixed mode is not supported on an srx.
For a layer 3 ip you have to use an irb interface. This is non-routable so it
may not be what you're looking for. It's used for management of the device
typically. At best it's an ip to ping.
On May 31, 2012, at 12:59 AM, Per Granath wrote:
> Try adding:
>
> set interfaces reth0 encapsulation flexible-ethernet-services
>
>
>> I try to have a vlan 200 in layer 2 mode transparent accross the SRX in
>> failover
>> mode.
>> Is it possible to have a redundant interface as trunk link, with 1 vlan
>> with an
>> @IP, and 1 vlan in transparent mode.
>>
>>
>> I give you my config:
>> ===
>> reth0 {
>> description "TRUNK vers RAP";
>> vlan-tagging;
>> redundant-ether-options {
>> redundancy-group 1;
>> }
>> unit 200 {
>> family bridge {
>> interface-mode trunk;
>> vlan-id-list 200;
>> }
>> }
>> unit 954 {
>> vlan-id 954;
>> family inet {
>> address 195.221.127.158/30;
>> }
>> }
>> }
>
>
> ___
> 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
Re: [j-nsp] Branch SRX and satellite
What you're most likely running into is the DHCP ttl limitation. While it's not often a problem, the SRX sends out a DHCP request with a TTL of 1. http://forums.juniper.net/t5/SRX-Services-Gateway/SRX-DHCP-client-sends-discover-request-with-TTL-1/td-p/99180 I've seen this in the past, and while rare it does happen every now and again depending on the ISP. As far as I know there hasn't been an feature to tweak the TTL for dhcp discover requests. I hope this helps, -Tim Eberhard On Mon, May 28, 2012 at 5:29 PM, Aaron Dewell wrote: > > Hi all, > > I've been having a problem with an SRX210 connected to a Wildblue satellite > modem (Surfbeam 2 if it matters). This is DHCP which appears to be proxied > by the modem. There are a couple of different states, but neither work: > > Case 1: No ARP entry for the DHCP default route (forwarding table entry says > "hold") > Case 2: ARP entry but cannot ping the router or anything else > > Upon reboot, it works right after obtaining the lease for about 10 seconds, > then stops (in one of those two states). > > Their "troubleshooting" method involves plugging it into a PC, which works, > at which point they wash their hands of it, saying it's clearly a router > problem. I have swapped in an SRX100, as well as another 210, and both > exhibit identical symptoms. Also, the router works connected to a CX111/VZW > Aircard. And it has been working for a few months and only quit last week > (no change in SRX config). > > The current best theory is an invalid ARP packet which windows accepts but > JunOS does not. That explains case #1 but not #2. > > I have the Wildblue people going out to swap out the modem tomorrow morning > (too bad they can't just send one to switch) on the theory that it's the most > likely thing to be the problem. > > Has anyone had any issues with an SRX connected to a satellite modem before? > Any suggestions would be greatly appreciated! > > Thanks! > > Aaron > > > ___ > 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
Re: [j-nsp] problems with srx240
Gotta love those proteus guys. Doing a write up on this so I don't have to :) http://www.proteus.net/sites/default/files/how_to_disable_idp_in_an_srx_0.pdf I'm pretty sure you need to either kill the process or bounce the box for it to "officially" take effect as the memory is allocated/consumed upon start up. Hope this helps, -Tim Eberhard On Sat, May 5, 2012 at 7:51 AM, David Klein wrote: > How do you disable IDP and UTM? > > Thanks... > > -David Klein > > -Original Message- > From: juniper-nsp-boun...@puck.nether.net > [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Tim Eberhard > Sent: Friday, May 04, 2012 9:13 PM > To: Maciej Jan Broniarz > Cc: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] problems with srx240 > > If I recall correctly, I looked into this previously and found that this was > due to idp being enabled (which it is by default) but not being used by > policy. I want to say the fix to stop these non-impacting albeit annoying > log messages is to just disable IDP all together. > > Hope that helps, > -Tim Eberhard > > On Fri, May 4, 2012 at 5:38 PM, Maciej Jan Broniarz > wrote: >> Hi, >> >> My SRX240 box started showing the following error in the logs: >> >> May 5 00:36:08 srx240-lab srx240-lab Frame 00: sp = 0x49202a58, pc = >> 0x08020254 May 5 00:36:08 srx240-lab srx240-lab Frame 01: sp = >> 0x49202b00, pc = 0x0800c1fc May 5 00:36:08 srx240-lab srx240-lab >> Frame 02: sp = 0x49202b70, pc = 0x0800d300 May 5 00:36:08 srx240-lab >> srx240-lab Frame 03: sp = 0x49202b90, pc = 0x082cb550 May 5 00:36:08 >> srx240-lab srx240-lab Frame 04: sp = 0x49202be8, pc = 0x080198c0 May >> 5 00:36:08 srx240-lab srx240-lab Frame 05: sp = 0x49202c10, pc = >> 0x080198c0 May 5 00:36:08 srx240-lab srx240-lab Frame 06: sp = >> 0x49202c38, pc = 0x080198c0 May 5 00:36:08 srx240-lab srx240-lab >> Frame 07: sp = 0x49202c60, pc = 0x08019a2c May 5 00:36:08 srx240-lab >> srx240-lab Frame 08: sp = 0x49202c98, pc = 0x0801fc34 May 5 00:36:08 >> srx240-lab srx240-lab Frame 09: sp = 0x49202cc0, pc = 0x09dc54c8 May >> 5 00:36:18 srx240-lab srx240-lab SCHED: Thread 14 (Forwarding Thread) >> ran for 1572 ms without yielding May 5 00:36:18 srx240-lab >> srx240-lab Scheduler Oinker May 5 00:36:18 srx240-lab srx240-lab >> Frame 00: sp = 0x491b8c68, pc = 0x08020254 May 5 00:36:18 srx240-lab >> srx240-lab Frame 01: sp = 0x491b8d10, pc = 0x0800c1fc May 5 00:36:18 >> srx240-lab srx240-lab Frame 02: sp = 0x491b8d80, pc = 0x088b3c8c May >> 5 00:36:18 srx240-lab srx240-lab Frame 03: sp = 0x491b8dd0, pc = >> 0x088b76d0 May 5 00:36:18 srx240-lab srx240-lab Frame 04: sp = >> 0x491b8e50, pc = 0x0801fc34 May 5 00:36:18 srx240-lab srx240-lab >> Frame 05: sp = 0x491b8e78, pc = 0x09dc54c8 >> >> The box isn't heavy loaded - just about 1-2megs of trafiic per sec. >> >> What might be the problem here? >> >> All best, >> mjb >> >> ___ >> 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
Re: [j-nsp] problems with srx240
If I recall correctly, I looked into this previously and found that this was due to idp being enabled (which it is by default) but not being used by policy. I want to say the fix to stop these non-impacting albeit annoying log messages is to just disable IDP all together. Hope that helps, -Tim Eberhard On Fri, May 4, 2012 at 5:38 PM, Maciej Jan Broniarz wrote: > Hi, > > My SRX240 box started showing the following error in the logs: > > May 5 00:36:08 srx240-lab srx240-lab Frame 00: sp = 0x49202a58, pc = > 0x08020254 > May 5 00:36:08 srx240-lab srx240-lab Frame 01: sp = 0x49202b00, pc = > 0x0800c1fc > May 5 00:36:08 srx240-lab srx240-lab Frame 02: sp = 0x49202b70, pc = > 0x0800d300 > May 5 00:36:08 srx240-lab srx240-lab Frame 03: sp = 0x49202b90, pc = > 0x082cb550 > May 5 00:36:08 srx240-lab srx240-lab Frame 04: sp = 0x49202be8, pc = > 0x080198c0 > May 5 00:36:08 srx240-lab srx240-lab Frame 05: sp = 0x49202c10, pc = > 0x080198c0 > May 5 00:36:08 srx240-lab srx240-lab Frame 06: sp = 0x49202c38, pc = > 0x080198c0 > May 5 00:36:08 srx240-lab srx240-lab Frame 07: sp = 0x49202c60, pc = > 0x08019a2c > May 5 00:36:08 srx240-lab srx240-lab Frame 08: sp = 0x49202c98, pc = > 0x0801fc34 > May 5 00:36:08 srx240-lab srx240-lab Frame 09: sp = 0x49202cc0, pc = > 0x09dc54c8 > May 5 00:36:18 srx240-lab srx240-lab SCHED: Thread 14 (Forwarding Thread) > ran for 1572 ms without yielding > May 5 00:36:18 srx240-lab srx240-lab Scheduler Oinker > May 5 00:36:18 srx240-lab srx240-lab Frame 00: sp = 0x491b8c68, pc = > 0x08020254 > May 5 00:36:18 srx240-lab srx240-lab Frame 01: sp = 0x491b8d10, pc = > 0x0800c1fc > May 5 00:36:18 srx240-lab srx240-lab Frame 02: sp = 0x491b8d80, pc = > 0x088b3c8c > May 5 00:36:18 srx240-lab srx240-lab Frame 03: sp = 0x491b8dd0, pc = > 0x088b76d0 > May 5 00:36:18 srx240-lab srx240-lab Frame 04: sp = 0x491b8e50, pc = > 0x0801fc34 > May 5 00:36:18 srx240-lab srx240-lab Frame 05: sp = 0x491b8e78, pc = > 0x09dc54c8 > > The box isn't heavy loaded - just about 1-2megs of trafiic per sec. > > What might be the problem here? > > All best, > mjb > > ___ > 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
Re: [j-nsp] Layer 2 feature on srx
Off the cuff..Looks to me like you're missing your bridge domain-type.
Sadly this doesn't produce any kind of errors when you attempt to
commit.
set bridge-domains domain-type bridge.
Additionally I noticed you're using two different vlans. As long as
traffic is flowing across a single vlan you'll be fine. If they need
to go from vlan 100 to 200 you'll need to do a vlan rewrite.
Hope this helps,
-Tim Eberhard
On Mon, Apr 9, 2012 at 7:06 AM, bruno wrote:
> i am running 11.4R1.6
> root@R1# run show version
> Hostname: R1
> Model: srx210h
> JUNOS Software Release [11.4R1.6]
>
>
>
> --
> Best Regards,
> Bruno
>
>
>
>
>
>
>
>
>
> -- Original --
> From: "Tom Storey";
> Date: Mon, Apr 9, 2012 07:56 PM
> To: "bruno";
> Cc: "juniper-nsp";
> Subject: Re: [j-nsp] Layer 2 feature on srx
>
>
> What software are you running on your SRX's?
>
> The only reason I ask is that I am running 10.4R4.5 on an SRX100, and
> this is how I do my VLANs (SRX is in flow mode, but does that really
> matter to L2??):
>
> interfaces {
> fe-0/0/1 {
> description "** Trunk to esxi1";
> unit 0 {
> family ethernet-switching {
> port-mode trunk;
> vlan {
> members all;
> }
> native-vlan-id 1;
> }
> }
> }
> fe-0/0/4 {
> description "** Console server";
> unit 0 {
> family ethernet-switching {
> vlan {
> members VLAN11-MGMT;
> }
> }
> }
> }
> vlan {
> unit 10 {
> family inet {
> address 172.25.144.65/26;
> }
> family inet6 {
> address 2001:::1::/64 {
> eui-64;
> }
> }
> }
> unit 11 {
> family inet {
> address 172.25.144.17/28;
> }
> }
> }
> }
> vlans {
> VLAN10-LAN {
> vlan-id 10;
> l3-interface vlan.10;
> }
> VLAN11-MGMT {
> vlan-id 11;
> l3-interface vlan.11;
> }
> }
>
> The primary difference seems to be that I use "vlans" instead of
> "bridge-domains" at the bottom, and the "vlan" interface instead of
> "irb".
>
> Ive also successfully trunked VLANs to/from a HP switch using this
> configuration.
>
> Tom
>
>
> On 9 April 2012 10:05, bruno wrote:
>> hello expert,
>> i use two srx210h to test some Layer 2 networking features on MX Series
>> routers. the topo is very simple
>> PC1---SRX1SRX2PC2. the link in srx1---srx2 is set to trunk mode.
>> PC1 and PC2 is belong to vlan 100. PC1 can't ping PC2.
>>
>>
>> interfaces {
>> ge-0/0/1 {
>> description TO-SRX2;
>> vlan-tagging;
>> unit 0 {
>> family bridge {
>> interface-mode trunk;
>> vlan-id-list [ 100 200 ];
>> }
>> }
>> }
>> fe-0/0/4 {
>> unit 0 {
>> family bridge {
>> interface-mode access;
>> vlan-id 100;
>> }
>> }
>> }
>> irb {
>> unit 100 {
>> description "GW For VLAN 100";
>> family inet {
>> address 100.1.1.254/24;
>> }
>> }
>> unit 200 {
>> description "GW For VLAN 200";
>> family inet {
>> address 200.1.1.254/24;
>> }
>> }
>> }
>> }
>> security {
>> forwarding-options {
>> family {
>> mpls {
>> mode packet-based;
>> }
>> }
>> }
>> }
>> bridge-domains {
>> vlan_100 {
>> vlan-id 100;
>> routing-interface irb.100;
>> }
>> vlan_200 {
>> vlan-id 200;
>> routing-interface irb.200;
>> }
>> }
>>
>>
>>
>> --
>> Best Regards,
>> Bruno
>> ___
>> 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
Re: [j-nsp] Destination NAT on SRX cluster
I'd agree it seems that you're running into a bug. Trying your config
on my SRX I am able to commit through. Reth's tend to be different
than a normal interface from a code standpoint, but nat isn't a
limitation (thank god).
If you're working in a lab, try to upgrade to my code version perhaps.
If you're in prod, good luck..open up a jtac case and find out which
release fixes it. Sorry Leigh, best of luck.
[edit security nat]
root@Lab-SRX240-11# commit check
configuration check succeeds
[edit security nat]
root@Lab-SRX240-11# show | compare
[edit security nat]
+ destination {
+ pool wilderness {
+ address 172.16.253.10/32 port 22;
+ }
+ rule-set incoming-connections {
+ from interface ge-0/0/0.0;
+ rule port-forard {
+ match {
+ destination-address 88.94.205.5/32;
+ destination-port 22;
+ }
+ then {
+ destination-nat pool wilderness;
+ }
+ }
+ }
+ }
+ proxy-arp {
+ interface ge-0/0/0.0 {
+ address {
+ 88.94.205.5/32;
+ }
+ }
+ }
[edit security nat]
root@Lab-SRX240-11# run show version
Hostname: Lab-SRX240-11
Model: srx240h-poe
JUNOS Software Release [11.4R1.6]
Hope this helps,
-Tim Eberhard
On Tue, Mar 20, 2012 at 12:09 PM, Leigh Porter
wrote:
>
>
>> From: Ben Dale [mailto:bd...@comlinx.com.au]
>>
>> Hi Leigh,
>>
>> On 20/03/2012, at 10:53 PM, Leigh Porter wrote:
>>
>> >
>> > error: The number of destination NAT pools exceeds limit of 0 [edit
>> > security nat destination rule-set incoming-connections rule
>> > port-forward then destination-nat] 'pool'
>> > failed to get pool (wilderness)
>> > error: configuration check-out failed
>>
>> It looks like a bug, but try changing the "from interface reth0.352" to
>> "from zone " and see if the issue goes
>> away. Failing that, upgrade to 11.1R6 and see if that fixes it.
>
> Yeah I thought bug too. I tried the "from zone .." but it didn't fix it. I'm
> just about to try 11.blah
>
> Thanks,
> Leigh
>
>
> __
> This email has been scanned by the Symantec Email Security.cloud service.
> For more information please visit http://www.symanteccloud.com
> __
>
> ___
> 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
Re: [j-nsp] SRX240 - ready for prime time?
Having dealt with the SRX through some very trying times (from early alpha boxes running on SSG) to current 11.x code I have to say the SRX has come a long long way. The 9.x code train and even well into 10.x saw some pretty big bugs with HA, VPN and other critical features. I have you say 10.4 and the 11.x code train have been pretty stable in whatever environment I've thrown them in. I tend to use the SRX's for their core functions (e.g. NAT, security policies, VPN's, etc) and stay away from IDP/UTM but from what i've seen they've been in good shape. I would encourage you to check out the 240. It's an amazing firewall for the price. Stick to 10.4 or something in the 11.x code and you'll be fine. I think you'll be shocked how stable and bug free it is after hearing all the bad items on this list. Good luck, hope this helps. -Tim Eberhard On Mon, Mar 5, 2012 at 5:28 PM, TCIS List Acct wrote: > Over the past few years the general feeling I've gotten reading j-nsp and > elsewhere was to stay away from the SRX line until the code matured. We've > got an upcoming project that I'm considering using a SRX 240 for. > > Has the code matured to the point that it can be considered a stable > platform for security (just basic firewall, 1:1 NATs, maybe a few VPNs), > high availability, and some very basic layer 3 routing services? > > TIA. > > --Mike > ___ > 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
Re: [j-nsp] Junos Load Balancing Behavior
Srx's, assuming you're running in flow mode will not load balance as of today. The forwarding table will show two routes, but it will only pick one. This has been discussed here previously, a quick google search of ECMP and SRX should help. Good luck, sorry to give you the bad news.. Tim Eberhard On Feb 2, 2012, at 11:01 AM, Devin Kennedy wrote: > Hello: > > > > I'm looking for some insight on the load balancing behavior that Junos uses > by default. We are certifying our Junos platform CE routers (SRX, MX10, > M7i) and not seeing what we expected given the documentation we have. > > > > According to the Juniper docs and the old JNCIP study guide, OSPF will > automatically load balance if there are two equal cost routes. And indeed > in the routing table we have default route advertised via OSPF to a CE > router which shows two next hops (one to each of two PE's). > > > > juniper@SRX240-5> show route 0/0 exact > > > > inet.0: 23 destinations, 23 routes (23 active, 0 holddown, 0 hidden) > > + = Active Route, - = Last Active, * = Both > > > > 0.0.0.0/0 *[OSPF/150] 20:45:21, metric 112, tag 13979 > > to 10.7.122.1 via ge-0/0/6.0 > >> to 10.7.122.2 via ge-0/0/6.0 > > > > However in the forwarding table there is only one next-hop shown and when > testing traffic flows we don't see any load balancing by default. > > > > juniper@SRX240-5> show route forwarding-table destination 0/0 > > Routing table: default.inet > > Internet: > > DestinationType RtRef Next hop Type Index NhRef Netif > > defaultuser 0ulst 262142 2 > > 80:71:1f:c0:3c:81 ucst 584 4 ge-0/0/6.0 > > defaultperm 0rjct36 4 > > 0.0.0.0/32 perm 0dscd34 2 > > > > Routing table: __master.anon__.inet > > Internet: > > DestinationType RtRef Next hop Type Index NhRef Netif > > defaultperm 0rjct 517 1 > > 0.0.0.0/32 perm 0dscd 515 1 > > > > Everything goes across the one next hop only (the one with the > in front of > it). We have to add an export policy to the routing-options > forwarding-table stanza to get it to work. > > > > This is from the Junos documentation for OSPF for version 10.4: > > > > "When several equal-cost routes to a destination exist, traffic is > distributed equally among them." > > > > http://www.juniper.net/techpubs/en_US/junos10.4/topics/concept/ospf-routing- > overview.html > > > > Shouldn't the load balancing work by default as the documentation would lead > one to believe? Does anyone have any insight into this? Is the > documentation incorrect and you actually are required to always add a > load-balancing export policy in order to get the desired load-balancing > behavior? > > > > > > > > Best Regards, > > > > Devin J Kennedy > > Juniper Engineer - AT&T Labs > > > > > > ___ > 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
Re: [j-nsp] DR deployment of SRX
Depends on what model of SRX you're talking about. High end or branch? High end: http://kb.juniper.net/library/CUSTOMERSERVICE/GLOBAL_JTAC/technotes/SRX%20High%20Availability%20Deployment%20Guide.pdf http://www.juniper.net/us/en/local/pdf/app-notes/3500168-en.pdf Branch: http://www.juniper.net/us/en/local/pdf/app-notes/3500132-en.pdf http://kb.juniper.net/library/CUSTOMERSERVICE/technotes/8010055-EN.PDF The HA chapter in the book Junos Security is also pretty comprehensive, but in the name of full disclosure.. I'm bias as I'm a co-author. As for challenges/limitations. I would highly recommend you read the release notes for whatever code you're running. Juniper does a really good job at listing the limitations for clusters with features (i.e. you can't do a packet capture on a reth interface,) I hope this helps, -Tim Eberhard On Sat, Jan 21, 2012 at 3:07 AM, Dan Chevrie wrote: > Hi- > is there any document related to DR deployment of SRX? challenges, services > and benefits? > > any help would be highly appreciated. > > > -Dan > ___ > 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
Re: [j-nsp] SRX650 Dual SRE6
It's been well known that the dual RE design while there is space in the chassis it's not supported in software as of today. I just looked at the release notes and I can't find any reference to dual RE's being supported. Did you expect it to be a feature there? I'm honestly not aware of it being on the roadmap to be supported, then again I haven't seen much of the 12.x roadmap as of late. I would talk to your SE about this if it's something you need to have to find out if/when it will be supported and under what circumstances. Good luck, -Tim Eberhard On Sat, Nov 19, 2011 at 8:26 PM, GIULIANO (WZTECH) wrote: > People, > > Does anyone knows if SRX650 box supports dual SRE6 (Services and Routing > Engine 6) ? > > It is possible with JUNOS 11.4 (last version available) to use both routing > engines ? > > Any special configuration to do ... for this both SRE6 to work ? > > We have tried dual SRE6 ... but what happen is that system do not recognizes > second routing engine. > > The second SRE stays in shutdown mode ... or inactive mode. > > Can you please give to me some feedback ? Anyone experience sometinh > similar ? > > Thanks a lot, > > Giuliano > ___ > 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
Re: [j-nsp] J-Series Router Options
Ben, Nobody is forcing the jseries to become firewalls. They did alter the default behavior of the packet handling to be flow mode..but you can configure that. To enable "packet mode" junos. Just issue the following commands. delete security set security forwarding-options family mpls mode packet-based set security forwarding-options family iso mode packet-based set security forwarding-options family inet6 mode packet-based This works on an SRX to turn it into a packet based device just the same as it does for a jseries. In regards to the flash size, I honestly can't speak to that. Maybe buy a couple of larger flash disks in bulk? Otherwise clean up the file system, load the code from sftp/ftp/tftp and upgrade with no-copy. That way you don't have to transfer it locally. Hope this helps, -Tim Eberhard On Mon, Nov 7, 2011 at 8:18 AM, R. Benjamin Kessler wrote: > Hello All - > > We have a client with a lot of J-Series routers running 9.3 code or earlier. > We really like the features and functionality of JUNOS as a router and are > more than a little annoyed that Juniper seems to be forcing us to turn these > routers into firewalls. > > What are others doing to deal with the "flow" issues associated with more > recent versions of code? > > Also, many of these routers have "small" CF cards (e.g. 256MB or 512MB) which > will also cause issues with more modern versions of code. > > I'm interested in knowing how others have tackled these challenges for > customers with hundreds of these in the field. > > Thanks, > > Ben > ___ > 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
[j-nsp] Netscreen Looking Glass
All, While going through some old stuff I wrote I came across a looking glass web based front end that I wrote for netscreens. The idea was to mimic the great looking glass type apps that exist for the routers for netscreen firewalls. For those that don't know a looking glass app allows users to issue predefined commands on your devices. Given how limited the netscreens are with their permissions (read-only or read-write/root) this was needed for me at the time. This allowed a handful of users to issue basic commands such as looking at the state of interfaces, pinging, looking at the local traffic logs, etc. It's written in python and runs via CGI. Just requires a webserver loaded with python 2.x and the pexpect module. Not sure if anyone can make use of it, but I figured releasing it publicly is better than letting it sit on my hard drive wasting away. Source, instructions and a screenshot are all posted over on sourceforge. : https://sourceforge.net/projects/nslg/ Feel free to let me know what you think if you use it. Thanks, -Tim Eberhard ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] SRX Session Analyzer
All, After finally finding some free time (a new job or two, and a new kid) I was able to at least sit down and hack out a base version of my SRX Session Analyzer. For those of you who used NSSA (Netscreen Session Analyzer) I wrote it to assist in troubleshooting Juniper firewalls. Basically this tool will take a look at your current SRX session table and give you a list of top talkers by IP, port, policy, Interface and now by packets and bytes. It is written completely in python and requires nothing other than what is in the compressed file. For you Windows 7 64bit guys: performanceclassifieds.net/SRX-Session-Analyzer.rar performanceclassifieds.net/SRX-Session-Analyzer.zip For you Windows 7 32bit guys: performanceclassifieds.net/SRX-Session-Analyzer-Win7-32.rar performanceclassifieds.net/SRX-Session-Analyzer-Win7-32.zip For you 32bit (windows xp) guys: performanceclassifieds.net/SRX-Session-Analyzer-win32.rar performanceclassifieds.net/SRX-Session-Analyzer-win32.zip If you run osx/linux feel free to email me directly and i'll get you a working copy. It just requires that you install python 3.2. As always this is virus free and requires no internet connection. Source available upon request. Please let me know what you think and if you find a bug let me know. This is the very first release. Hopefully it helps some people out. Lots of folks have been emailing me requesting it. Thanks, -Tim Eberhard ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX - DHCP client is not working right
I've noticed the same. Since 10.4r5 the dhcp client has issues. We
rollback code and it works without any problems. Same issues on 11.1
code. Fun stuff to troubleshoot.
-Tim Eberhard
On Wed, Oct 12, 2011 at 8:09 PM, Brent Jones wrote:
> On Wed, Oct 12, 2011 at 2:07 AM, martin papik wrote:
>> Hi,
>> a have detected very strange behaviour when SRX interface is configured as
>> DHCP client interface and this interface (untrust zone) is connected to
>> cable ISP modem (Motorola SurfBoard SB 5101). The ISP is UPC company
>> (Europe). The IP assigned address from ISP is related to MAC address of SRX
>> interface. But assigned IP is not right. With different device (like linksys
>> WRT with clone MAC) the assigned IP is OK.
>> I found same problem in juniper forum discussion here:
>> http://www.juniperforum.com/index.php?topic=8129.0
>>
>> My conf is:
>>
>> version 11.1R3.5;
>>
>> interfaces {
>> fe-0/0/0 {
>> unit 0 {
>> family inet {
>> dhcp;
>> }
>> }
>> }
>>
>> ..
>>
>> security-zone untrust {
>> screen untrust-screen;
>> interfaces {
>> fe-0/0/0.0 {
>> host-inbound-traffic {
>> system-services {
>> dhcp;
>> ping;
>> }
>> }
>> }
>> }
>> }
>>
>> Have anybody some idea why assigned IP from ISP is not right (MAC is
>> registred by ISP and with another devices DHCP client working with good IP)?
>> I was thinking about TTL parameter, but I dont know how I can change
>> it..
>>
>> Thanks
>> Martin
>> ___
>> juniper-nsp mailing list juniper-nsp@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>
> The DHCP client code doesn't work well (or at all) on 11.1 right now.
>
> Roll back to 10.4, and you'll be good to go
>
> --
> Brent Jones
> br...@servuhome.net
>
> ___
> 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
Re: [j-nsp] Multihome SRX650 2 default routes
Yes, my apologies if I wasn't clear in my original email. The "hack"
involved to get ECMP and any real security functionality working with
the SRX involves multiple virtual routers.
On Wed, Sep 7, 2011 at 7:32 AM, Chen Jiang wrote:
> you can use routing-instance to achieve ECMP/NAT in SRX.
>
> On Sun, Aug 28, 2011 at 1:22 AM, Daniel Daloia
> wrote:
>>
>> If that's true then that's horrible news. The data sheet for the sex
>> branch series lines says that it can do ECMP, but says nothing about mixing
>> it with advanced services. This seems so trivial. Going to spend some time
>> in the lab.
>>
>> Thanks!
>>
>> On Aug 27, 2011, at 3:02 AM, Tim Eberhard wrote:
>>
>> > ECMP doesn't work as of today in branch series SRX's if "advanced"
>> > security features are enabled such as NAT, IDP, ALG's, and such. The
>> > problem is with the flow module and where routing decisions take
>> > place.
>> >
>> > It will work if the both destination interfaces are in the same zone
>> > and you're using basic security policies. If you require any form of
>> > NAT (which is typical with two ISP links) then this will not load
>> > balance across the two paths.
>> >
>> > I've tested this in my lab and it's a known limitation within Juniper.
>> > The forwarding table shows both routes (creating two static default
>> > routes will do the trick) then enabling layer 3 load balancing but the
>> > routing table will always prefer one route and send traffic down only
>> > that route.
>> >
>> > There are hacks (and not very clean ones to be honest) involving
>> > multiple routers one to terminate the inbound traffic and nat it, then
>> > the second to do the ECMP. This is not ideal and I wouldn't ever
>> > recommend it for a customer environment.
>> >
>> > Best of luck. I hope the branch guys can get this fixed. ScreenOS has
>> > been able to do this for a while. I'm told this may get addressed in
>> > 12.1 but nothing is official.
>> > -Tim Eberhard
>> >
>> >
>> >
>> > On Fri, Aug 26, 2011 at 10:33 AM, Daniel M Daloia Jr
>> > wrote:
>> >> Thanks Ben. This would be the case with two separate virtual routers
>> >> since they would have to be in different security zones which why I didn't
>> >> think that would work. I would like to keep the firewall in flow mode.
>> >>
>> >>
>> >> I found some information on multipath which I am going to lab up soon.
>> >> I can keep the interfaces in the same security zone if that is the case
>> >> and
>> >> create a peer group for the two neighbours.
>> >>
>> >>
>> >>
>> >> http://www.juniper.net/techpubs/en_US/junos10.4/topics/reference/configuration-statement/multipath-edit-protocols-bgp.html
>> >>
>> >> Thanks!
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> From: Ben Boyd
>> >> To: Daniel M Daloia Jr
>> >> Cc: "juniper-nsp@puck.nether.net"
>> >> Sent: Friday, August 26, 2011 10:44 AM
>> >> Subject: Re: [j-nsp] Multihome SRX650 2 default routes
>> >>
>> >>
>> >> If you install both routes in the forwarding table you'll probably end
>> >> up dropping a lot of your traffic.
>> >>
>> >> The SRX is a stateful firewall, so if you sent traffic to one provider
>> >> and got it back on another it would drop the traffic.
>> >>
>> >> It would be best to do this in a router or to load balance per prefix
>> >> with as path prepending going out and local pref coming in.
>> >>
>> >> Anyway, here's how you would do it, but be careful.
>> >> root# show
>> >> policy-statement TestLBOut {
>> >> then {
>> >> load-balance per-packet;
>> >> }
>> >> }
>> >>
>> >> lroot# show routing-options
>> >> forwarding-table {
>> >> export TestLBOut;
>> >> }
>> >>
>> >>
>> >>
>> >> Thanks,
>> >> Ben Boyd
>> >> --
>> >> Sent from my iPhone
>> >>
>> >> On Aug 25, 2011, at 11:09, Daniel M Daloia Jr
>> >&g
Re: [j-nsp] Juniper chip architecture
*some* useful information can be found here: http://juniper.cluepon.net/Category:Hardware Lots of big blank spots and lots of older information, but it's a good start and about as good as you're going to get (as far as I know of) without being an internal Juniper employee. Good luck, -Tim Eberhard On Sat, Aug 27, 2011 at 10:31 PM, Jackson Jacobson wrote: > Sorry for what seems to be a dumb question. > > I see a lot of talk about different juniper chip architecture. What's trio, > etc? What makes it better than other venders? How can I get more info on > juniper internal architectures? > > Salud, > > j.j.j. > ___ > 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
Re: [j-nsp] Multihome SRX650 2 default routes
Best of luck Daniel. Please report back if you find other results but
I spent a fair amount of time in my lab and then working with some of
my internal contacts within Juniper on this issue.
For the record, I hate how the iphone autocorrects SRX into sex.
That's bitten me more than once now. :)
-Tim Eberhard
On Sat, Aug 27, 2011 at 12:22 PM, Daniel Daloia wrote:
> If that's true then that's horrible news. The data sheet for the sex branch
> series lines says that it can do ECMP, but says nothing about mixing it with
> advanced services. This seems so trivial. Going to spend some time in the lab.
>
> Thanks!
>
> On Aug 27, 2011, at 3:02 AM, Tim Eberhard wrote:
>
>> ECMP doesn't work as of today in branch series SRX's if "advanced"
>> security features are enabled such as NAT, IDP, ALG's, and such. The
>> problem is with the flow module and where routing decisions take
>> place.
>>
>> It will work if the both destination interfaces are in the same zone
>> and you're using basic security policies. If you require any form of
>> NAT (which is typical with two ISP links) then this will not load
>> balance across the two paths.
>>
>> I've tested this in my lab and it's a known limitation within Juniper.
>> The forwarding table shows both routes (creating two static default
>> routes will do the trick) then enabling layer 3 load balancing but the
>> routing table will always prefer one route and send traffic down only
>> that route.
>>
>> There are hacks (and not very clean ones to be honest) involving
>> multiple routers one to terminate the inbound traffic and nat it, then
>> the second to do the ECMP. This is not ideal and I wouldn't ever
>> recommend it for a customer environment.
>>
>> Best of luck. I hope the branch guys can get this fixed. ScreenOS has
>> been able to do this for a while. I'm told this may get addressed in
>> 12.1 but nothing is official.
>> -Tim Eberhard
>>
>>
>>
>> On Fri, Aug 26, 2011 at 10:33 AM, Daniel M Daloia Jr
>> wrote:
>>> Thanks Ben. This would be the case with two separate virtual routers since
>>> they would have to be in different security zones which why I didn't think
>>> that would work. I would like to keep the firewall in flow mode.
>>>
>>>
>>> I found some information on multipath which I am going to lab up soon. I
>>> can keep the interfaces in the same security zone if that is the case and
>>> create a peer group for the two neighbours.
>>>
>>>
>>> http://www.juniper.net/techpubs/en_US/junos10.4/topics/reference/configuration-statement/multipath-edit-protocols-bgp.html
>>>
>>> Thanks!
>>>
>>>
>>>
>>>
>>>
>>> From: Ben Boyd
>>> To: Daniel M Daloia Jr
>>> Cc: "juniper-nsp@puck.nether.net"
>>> Sent: Friday, August 26, 2011 10:44 AM
>>> Subject: Re: [j-nsp] Multihome SRX650 2 default routes
>>>
>>>
>>> If you install both routes in the forwarding table you'll probably end up
>>> dropping a lot of your traffic.
>>>
>>> The SRX is a stateful firewall, so if you sent traffic to one provider and
>>> got it back on another it would drop the traffic.
>>>
>>> It would be best to do this in a router or to load balance per prefix with
>>> as path prepending going out and local pref coming in.
>>>
>>> Anyway, here's how you would do it, but be careful.
>>> root# show
>>> policy-statement TestLBOut {
>>> then {
>>> load-balance per-packet;
>>> }
>>> }
>>>
>>> lroot# show routing-options
>>> forwarding-table {
>>> export TestLBOut;
>>> }
>>>
>>>
>>>
>>> Thanks,
>>> Ben Boyd
>>> --
>>> Sent from my iPhone
>>>
>>> On Aug 25, 2011, at 11:09, Daniel M Daloia Jr
>>> wrote:
>>>
>>>
>>> Hi Folks,
>>>>
>>>> Is it possible to install 2 BGP default routes from 2 ISPs to provide load
>>>> balancing with an SRX650 cluster? Both ISPs are same speed. I was thinking
>>>> this may be possible with importing the routes into inet.0 from separate
>>>> virtual routers which have the interfaces facing the 2 ISPs in them, but
>>>> the ISP interfaces would have to be in separate security zones which
>>>> wouldn't agree with the security policy and NAT. Anyone have any ideas or
>>>> can point me to some documentation that will help? I suppose I can buy a
>>>> separate set of routers to run BGP and use an IGP to load balance, but
>>>> doing it with the single cluster would be nice.
>>>>
>>>> Thanks!
>>>> ___
>>>> 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
Re: [j-nsp] Multihome SRX650 2 default routes
ECMP doesn't work as of today in branch series SRX's if "advanced"
security features are enabled such as NAT, IDP, ALG's, and such. The
problem is with the flow module and where routing decisions take
place.
It will work if the both destination interfaces are in the same zone
and you're using basic security policies. If you require any form of
NAT (which is typical with two ISP links) then this will not load
balance across the two paths.
I've tested this in my lab and it's a known limitation within Juniper.
The forwarding table shows both routes (creating two static default
routes will do the trick) then enabling layer 3 load balancing but the
routing table will always prefer one route and send traffic down only
that route.
There are hacks (and not very clean ones to be honest) involving
multiple routers one to terminate the inbound traffic and nat it, then
the second to do the ECMP. This is not ideal and I wouldn't ever
recommend it for a customer environment.
Best of luck. I hope the branch guys can get this fixed. ScreenOS has
been able to do this for a while. I'm told this may get addressed in
12.1 but nothing is official.
-Tim Eberhard
On Fri, Aug 26, 2011 at 10:33 AM, Daniel M Daloia Jr
wrote:
> Thanks Ben. This would be the case with two separate virtual routers since
> they would have to be in different security zones which why I didn't think
> that would work. I would like to keep the firewall in flow mode.
>
>
> I found some information on multipath which I am going to lab up soon. I can
> keep the interfaces in the same security zone if that is the case and create
> a peer group for the two neighbours.
>
>
> http://www.juniper.net/techpubs/en_US/junos10.4/topics/reference/configuration-statement/multipath-edit-protocols-bgp.html
>
> Thanks!
>
>
>
>
>
> From: Ben Boyd
> To: Daniel M Daloia Jr
> Cc: "juniper-nsp@puck.nether.net"
> Sent: Friday, August 26, 2011 10:44 AM
> Subject: Re: [j-nsp] Multihome SRX650 2 default routes
>
>
> If you install both routes in the forwarding table you'll probably end up
> dropping a lot of your traffic.
>
> The SRX is a stateful firewall, so if you sent traffic to one provider and
> got it back on another it would drop the traffic.
>
> It would be best to do this in a router or to load balance per prefix with as
> path prepending going out and local pref coming in.
>
> Anyway, here's how you would do it, but be careful.
> root# show
> policy-statement TestLBOut {
> then {
> load-balance per-packet;
> }
> }
>
> lroot# show routing-options
> forwarding-table {
> export TestLBOut;
> }
>
>
>
> Thanks,
> Ben Boyd
> --
> Sent from my iPhone
>
> On Aug 25, 2011, at 11:09, Daniel M Daloia Jr wrote:
>
>
> Hi Folks,
>>
>>Is it possible to install 2 BGP default routes from 2 ISPs to provide load
>>balancing with an SRX650 cluster? Both ISPs are same speed. I was thinking
>>this may be possible with importing the routes into inet.0 from separate
>>virtual routers which have the interfaces facing the 2 ISPs in them, but the
>>ISP interfaces would have to be in separate security zones which wouldn't
>>agree with the security policy and NAT. Anyone have any ideas or can point me
>>to some documentation that will help? I suppose I can buy a separate set of
>>routers to run BGP and use an IGP to load balance, but doing it with the
>>single cluster would be nice.
>>
>>Thanks!
>>___
>>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
Re: [j-nsp] Offline config verification
Olives are great for these types of scripts. An olive vmware machine can be hosted on anything and just be used for config verification. Hope this helps, -Tim Eberhard On Jan 14, 2011, at 3:40 PM, Nvvk Brnn wrote: > Hi: > > I have some perl scripts that generate Juniper configs. > I need to verify that these configs are Juniper compatible (as there could > be bugs in my scripts) > > I have 2 options. > 1) Copy the generated config to a juniper router, load merge config and then > commit to see if there are errors. > (We will actually see errors while doing a load merge) > > 2) This is the option that I want to pursue (in the interest of time as I > have lots of verification to do) > An offline config parser that will tell me if I have a valid Juniper config. > Do we know which daemon in juniper does > this config parsing? > > I could start a shell on the juniper and copy the binaries to a remote > machine and start playing with them, but wanted to see if > someone has any similar experience. > > Thanks, > > N > ___ > 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
Re: [j-nsp] netscree
You can change the admin user "netscreen" to anything you want. On Tue, Jan 4, 2011 at 3:46 PM, Deric Kwok wrote: > Hi > > ls it possible to change / delete the default logon: netscree? > > If yes, pls let me know > > thanks > ___ > 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
Re: [j-nsp] Data Plane Memory in JUNOS 10.3R1.9
Any change after disabling IDP all together? set system processes idp-policy disable -Tim Eberhard On Sun, Nov 21, 2010 at 7:14 PM, Lawrence Wong wrote: > Hi everyone, > > I'm currently testing out a J4350 in my lab and it's running on the latest > 10.3R1.9. > > I noticed that after even I've configured the J4350 to run in Packet Mode > (Security deleted and MPLS enabled and configured), the IDP modules seems to > be > taking up between 31MB - 204MB of data plane memory. > > root> show security idp status > State of IDP: Disabled, > > Packets/second: 0 Peak: 0 > KBits/second : 0 Peak: 0 > Latency (microseconds): [min: 0] [max: 0] [avg: 0] > > Packet Statistics: > [ICMP: 0] [TCP: 0] [UDP: 0] [Other: 0] > > Flow Statistics: > ICMP: [Current: 0] [Max: 0 ] > TCP: [Current: 0] [Max: 0 ] > UDP: [Current: 0] [Max: 0 ] > Other: [Current: 0] [Max: 0 ] > > Session Statistics: > [ICMP: 0] [TCP: 0] [UDP: 0] [Other: 0] > Policy Name : none > > root> show security idp memory > > > IDP data plane memory statistics: > > Total IDP data plane memory : 204 MB > Used : 31 MB ( 31744 KB ) ( 15.20%) > Available : 173 MB ( 177152 KB ) ( 84.80%) > > > Does anyone know how I can really "remove" the IDP modules and free up data > plane memory? > > > At the same time, I also noticed that the data plane memory is currently set > at > 576MB unlike earlier JUNOS (non-ES) 9.3 versions whereby memory was > reported/used as a lump sum and not specifically broken down. > > Routing Engine status: > Temperature 26 degrees C / 78 degrees F > CPU temperature 41 degrees C / 105 degrees F > Total memory 2048 MB Max 1434 MB used ( 70 percent) > Control plane memory 1472 MB Max 927 MB used ( 63 percent) > Data plane memory 576 MB Max 507 MB used ( 88 percent) > > > > Would it be possible to increase the amount of data plane memory allocated? > > > TIA! > > > > > ___ > 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
Re: [j-nsp] SRX for MPLS
I don't believe that's the case. You can do MPLS (I can't say I've ever done
it, but I know the config is possible) the major catch with that is the SRX
will be switched to packet mode (vs flow) and you loose the flow
capabilities of the SRX platform. Basically you can turn the SRX into a
branch router and do MPLS but the MPLS router+firewall isn't possible.
security {
forwarding-options {
family {
mpls {
mode packet-based;
}
}
}
}
Hope this clears things up,
-Tim Eberhard
On Thu, Oct 21, 2010 at 9:59 PM, Jai Chandra Gundapaneni <
jaichan...@juniper.net> wrote:
> At least not yet I should say.
>
> Thanks & Regards,
> Jai
>
> - Original Message -
> From: Jai Chandra Gundapaneni
> To: 'giulian...@uol.com.br' ; '
> juniper-nsp@puck.nether.net'
> Sent: Thu Oct 21 19:57:52 2010
> Subject: Re: [j-nsp] SRX for MPLS
>
> Hi Giuliano,
>
> We do not support MPLS on SRX platforms.
>
>
>
> Thanks & Regards,
> Jai
>
> - Original Message -
> From: juniper-nsp-boun...@puck.nether.net <
> juniper-nsp-boun...@puck.nether.net>
> To: juniper-nsp@puck.nether.net
> Sent: Thu Oct 21 19:48:46 2010
> Subject: [j-nsp] SRX for MPLS
>
> People,
>
> Does anyone uses SRX routers for MPLS (VPLS) Transport ?
>
> We are thinking about the use of SRX220 under some conditions:
>
> - Use it in a not a good environment without air conditioning and a lot
> of dust ... external box temperature rises from 35 to 42 Celsius.
> - Be the point to interconnect POPs using point to point radios
> (100~1000 Mbps)
> - Using it to provide a VPLS infrastructure for L2 transport and client
> isolation until the start of the backbone (M7i and MX80 Routers)
> - SRX220 to provide OSPFv2 and OSPFv3 L3 gateway for some routed clients.
>
> The figure showed at the following link tries to resume it at all:
>
> http://www.wztech.com.br/JUNIPER/Topology.png
>
> It is possible to use this box in a such project ? Do you have any
> experience using it to do this type of topology ?
>
> Is is possible that SRX220 can work fine under so strength environment
> conditions ? Could it blow up or goes down ?
>
> If someone has implemented this kind of environment can please share the
> experiences ?
>
> Thanks a lot,
>
> Giuliano
>
>
>
>
>
>
>
> ___
> 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
Re: [j-nsp] st0 speeds
Nick, A secure tunnel interface is only as fast the entire network path end to end. You can have a ST interface configured on a 100meg link but if the VPN is over the internet and your internet connection is only 10meg... If the secure tunnel (VPN tunnel) Isn't on your local lan and you're not 100% on the health of the entire network path end to end (or these are not cabled back to back with a VPN tunnel running over them). I would take a look at configuring juniper RPM over the IPSEC tunnel. That will tell you the latency, jitter and packet loss over that VPN tunnel. Additionally speeds will never be as good through a vpn tunnel as not. With IPSEC comes additional over head and packets in many cases will need to be fragmented or the MTU made smaller. This is just a draw back of using an IPSEC VPN. I hope this helps, -Tim Eberhard On Wed, Sep 15, 2010 at 12:44 PM, Nick Ryce wrote: > Hi Guys, > > Is there a set speed for the st0 interface. The physical line is 100meg > that the st0 is bound to but I only seem to get 10meg out of it. > > Any help appreciated. > > Nick > > > > -- > > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the sender. Any > offers or quotation of service are subject to formal specification. > Errors and omissions excepted. Please note that any views or opinions > presented in this email are solely those of the author and do not > necessarily represent those of Lumison. > Finally, the recipient should check this email and any attachments for the > presence of viruses. Lumison accept no liability for any > damage caused by any virus transmitted by this email. > ___ > 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
Re: [j-nsp] Stable Junos
It's always a wise choice to go with Jtacs recommended version of junos for your platform. -Tim Eberhard On Aug 31, 2010, at 2:11 AM, Salik Mobin wrote: > Dear Fellows, > > Can anyone suggest a stable Junos from 10.x trail? > > TIA > > > > > ___ > 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
Re: [j-nsp] SRX SNMP trending, current sessions & connection rate?
Co-current sessions are 1.3.6.1.4.1.2636.3.39.1.12.1.2.0 As far as I know there is no OID for session set up rate or ramp rate. Hope this helps, -Tim Eberhard On Sun, Aug 29, 2010 at 11:04 PM, matthew zeier wrote: > Having trouble finding the OIDs to trend concurrent sessions and new > session setup rate (which I suppose could be pulled from the same OID). > > jtac pointed me at > > > http://www.juniper.net/techpubs/en_US/junos10.1/information-products/topic-collections/config-guide-network-mgm/mib-jnx-js-policy.txt > > but I must be glossing over it. > > Looking for an OID or a pre-canned cacti template. > ___ > 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
Re: [j-nsp] IPSEC VPN Issues on SRX3600
Muhammad, When asking for help it would be worth while to give as much information as possible. What type of tunnel? What is the far end of the VPN? What code version? Have to searched the PR's for this type of issue? I will say if it's pre 10.0 I have seen *lots* of ipsec issues and behaviors like you are describing. In 10.0 Juniper did a revamp of the vpn code/design and things are greatly improved (but by no means bug free). -Tim Eberhard On Wed, Aug 18, 2010 at 10:34 AM, Fahad Khan wrote: > Dear Folks, > > I am running various IPSEC VPN tunnels on SRX, but seeing a strange > behavior > with 1 or 2 tunnels suddenly, that is the tunnel remains up, but traffic > stops passing. > > has any one experienced this ever?? please share > > regards, > > Muhammad Fahad Khan > JNCIP - M/T # 834 > IT Specialist > Global Technology Services, IBM > fa...@pk.ibm.com > +92-301-8247638 > Skype: fahad-ibm > http://pk.linkedin.com/in/muhammadfahadkhan > ___ > 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
Re: [j-nsp] IDP8200 Issue -
IP monitoring is only available at this time on the high end series SRX's. It might be in the 3600 depending on the code version. I would test and see. IP monitoring is track-ip for Junos. If IP monitoring is not available on your platform or code version there are event scripts that mimic the track-ip functionality that you can download from juniper's website. For the event script track-ip see the following document: http://www.juniper.net/us/en/local/pdf/app-notes/3500168-en.pdf For IP monitoring configuration this should help: http://www.juniper.net/techpubs/software/junos-security/junos-security10.1/junos-security-swconfig-security/topic-43676.html Hopefully this helps, -Tim Eberhard On Wed, May 26, 2010 at 7:27 AM, Fahad Khan wrote: > Ah! great... IP monitoring will work, I ll test it and see.. > > > Thanks Scott. > > Tim, can you explain how can we do Track-IP on SRX?? or u meant the same > thing as scott?? > > regards, > > Muhammad Fahad Khan > JNCIP - M/T # 834 > IT Specialist > Global Technology Services, IBM > fa...@pk.ibm.com > +92-321-2370510 > +92-301-8247638 > Skype: fahad-ibm > http://www.linkedin.com/in/muhammadfahadkhan > http://fahad-internetworker.blogspot.com > http://www.visualcv.com/g46ptnd > > > On Wed, May 26, 2010 at 4:53 PM, Scott T. Cameron >wrote: > > > set chassis cluster redundancy-group # ip-monitoring > > > > As with all things, YMMV. > > > > > > On Wed, May 26, 2010 at 7:40 AM, Tim Eberhard wrote: > > > > > You could always run trackip on the SRX to monitor the path to the > > switch. > > > Pinging a L3 interface on the core switch itself. > > > > > > Hope this helps > > > > > > -Tim Eberhard > > > > > > > > > On May 26, 2010, at 6:27 AM, Fahad Khan wrote: > > > > > > Dear Folks, > > >> > > >> I am just shocked to know that IDP8200 does not support Peer Port > > >> Modulation > > >> for 10 gig links. > > >> > > >> Does any one know, how can I failover my Firewall properly if the link > > >> between Core Switch and IDP is down > > >> > > >> the diagram is > > >> > > >> SRX3600---HA---SRX3600 > > >> | | > > >>IDP8200IDP8200 > > >> | | > > >> --Core -Switch-- > > >> > > >> > > >> Awaiting for quick response > > >> > > >> Muhammad Fahad Khan > > >> JNCIP - M/T # 834 > > >> IT Specialist > > >> Global Technology Services, IBM > > >> fa...@pk.ibm.com > > >> +92-321-2370510 > > >> +92-301-8247638 > > >> Skype: fahad-ibm > > >> http://www.linkedin.com/in/muhammadfahadkhan > > >> http://fahad-internetworker.blogspot.com > > >> http://www.visualcv.com/g46ptnd > > >> ___ > > >> 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 > > > ___ > 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
Re: [j-nsp] IDP8200 Issue -
You could always run trackip on the SRX to monitor the path to the switch. Pinging a L3 interface on the core switch itself. Hope this helps -Tim Eberhard On May 26, 2010, at 6:27 AM, Fahad Khan wrote: Dear Folks, I am just shocked to know that IDP8200 does not support Peer Port Modulation for 10 gig links. Does any one know, how can I failover my Firewall properly if the link between Core Switch and IDP is down the diagram is SRX3600---HA---SRX3600 | | IDP8200IDP8200 | | --Core -Switch-- Awaiting for quick response Muhammad Fahad Khan JNCIP - M/T # 834 IT Specialist Global Technology Services, IBM fa...@pk.ibm.com +92-321-2370510 +92-301-8247638 Skype: fahad-ibm http://www.linkedin.com/in/muhammadfahadkhan http://fahad-internetworker.blogspot.com http://www.visualcv.com/g46ptnd ___ 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
Re: [j-nsp] sessions ISG 2000
Those are the number of sessions built, not the number of co-current sessions. To see the total number of co-current sessions you can do a "get session info". How is it possible that 1477066 sessions were built in an hour? Sessions are often built and torn down very quickly, case in point DNS or HTTP. A session is built as the initial DNS request is sent, after a reply is seen the session is torn down. The total duration is very very quick and the session doesn't stay in the session table very long. Without knowing your traffic type I cannot tell you if this is normal or high. You can use a tool to analyze your session table that I wrote that will tell you what kind of traffic you have passing through your firewall. The tool is called NSSA (Netscreen Session Analyzer). Hope this clears things up, -Tim Eberhard On Wed, Mar 24, 2010 at 7:53 AM, Ibariouen Khalid < ibariouen.kha...@ericsson.com> wrote: > Thanks for ure feed-back > > But how comes that I have 1477066 were built in the last hour and the > license is limited to 500064 sessions ? > > Waiting for your feed-back. > > BR/ > > > -- > > *From:* Tim Eberhard [mailto:xmi...@gmail.com] > *Sent:* mercredi 24 mars 2010 15:51 > *To:* Ibariouen Khalid > *Cc:* juniper-nsp@puck.nether.net > *Subject:* Re: [j-nsp] sessions ISG 2000 > > > > That is the number of sessions built per second, minute and then hour. > > Starting off.. > Last 60 seconds: > 0: 818 1: 711 2: 723 3: 753 4: 697 5: > 712 > > That is the last 60 seconds, so 818 sessions were built 1 second ago. > > Last 24 hours: > 0: 1477066 > > 1477066 were built in the last hour. > > > These are permitted connections. > > Hope this helps, > -Tim Eberhard > > On Wed, Mar 24, 2010 at 7:39 AM, Ibariouen Khalid < > ibariouen.kha...@ericsson.com> wrote: > > Hi all > Can someone tell me what's the meaning of the following output ? > > Is it the number of sessions ?? > > > > GURGiFW:GURGiFW01(M)-> get performance session detail > Last 60 seconds: > 0: 818 1: 711 2: 723 3: 753 4: 697 5: > 712 > 6: 703 7: 720 8: 706 9: 722 10: 754 11: > 737 > 12: 810 13: 717 14: 818 15: 794 16: 711 17: > 732 > 18: 739 19: 789 20: 712 21: 756 22: 633 23: > 687 > 24: 704 25: 776 26: 714 27: 649 28: 720 29: > 635 > 30: 682 31: 748 32: 773 33: 723 34: 678 35: > 836 > 36: 760 37: 752 38: 754 39: 748 40: 829 41: > 709 > 42: 745 43: 720 44: 624 45: 689 46: 767 47: > 748 > 48: 703 49: 687 50: 683 51: 723 52: 758 53: > 753 > 54: 781 55: 753 56: 748 57: 796 58: 759 59: > 719 > > Last 60 minutes: > 0:43182 1:43062 2:42270 3:42092 4:42182 5: > 41452 > 6:43388 7:42766 8:41878 9:43618 10:41223 11: > 43629 > 12:43512 13:42015 14:41240 15:41713 16:42376 17: > 41089 > 18:40845 19:41254 20:41706 21:43379 22:44066 23: > 42946 > 24:41307 25:40752 26:42202 27:42116 28:42065 29: > 42664 > 30:42105 31:41580 32:40966 33:42879 34:41547 35: > 41210 > 36:41028 37:42219 38:42228 39:39627 40:39858 41: > 40927 > 42:39653 43:39048 44:38701 45:40059 46:39197 47: > 38769 > 48:37620 49:40328 50:41233 51:42655 52:40946 53: > 41503 > 54:40446 55:38491 56:39515 57:39991 58:39151 59: > 39603 > > Last 24 hours: > 0: 1477066 1: 2344774 2: 2073201 3: 1925822 4: 1787530 5: > 1609260 > 6: 1383548 7: 1040609 8: 809206 9: 696466 10: 671836 11: > 845894 > 12: 1267113 13: 1939370 14: 2627395 15: 3258609 16: 3606961 17: > 3573903 > 18: 3318069 19: 3093698 20: 2457813 21: 2331525 22: 2296393 23: > 2455807 > ___ > 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
Re: [j-nsp] sessions ISG 2000
That is the number of sessions built per second, minute and then hour. Starting off.. Last 60 seconds: 0: 818 1: 711 2: 723 3: 753 4: 697 5: 712 That is the last 60 seconds, so 818 sessions were built 1 second ago. Last 24 hours: 0: 1477066 1477066 were built in the last hour. These are permitted connections. Hope this helps, -Tim Eberhard On Wed, Mar 24, 2010 at 7:39 AM, Ibariouen Khalid < ibariouen.kha...@ericsson.com> wrote: > Hi all > Can someone tell me what's the meaning of the following output ? > > Is it the number of sessions ?? > > > > GURGiFW:GURGiFW01(M)-> get performance session detail > Last 60 seconds: > 0: 818 1: 711 2: 723 3: 753 4: 697 5: > 712 > 6: 703 7: 720 8: 706 9: 722 10: 754 11: > 737 > 12: 810 13: 717 14: 818 15: 794 16: 711 17: > 732 > 18: 739 19: 789 20: 712 21: 756 22: 633 23: > 687 > 24: 704 25: 776 26: 714 27: 649 28: 720 29: > 635 > 30: 682 31: 748 32: 773 33: 723 34: 678 35: > 836 > 36: 760 37: 752 38: 754 39: 748 40: 829 41: > 709 > 42: 745 43: 720 44: 624 45: 689 46: 767 47: > 748 > 48: 703 49: 687 50: 683 51: 723 52: 758 53: > 753 > 54: 781 55: 753 56: 748 57: 796 58: 759 59: > 719 > > Last 60 minutes: > 0:43182 1:43062 2:42270 3:42092 4:42182 5: > 41452 > 6:43388 7:42766 8:41878 9:43618 10:41223 11: > 43629 > 12:43512 13:42015 14:41240 15:41713 16:42376 17: > 41089 > 18:40845 19:41254 20:41706 21:43379 22:44066 23: > 42946 > 24:41307 25:40752 26:42202 27:42116 28:42065 29: > 42664 > 30:42105 31:41580 32:40966 33:42879 34:41547 35: > 41210 > 36:41028 37:42219 38:42228 39:39627 40:39858 41: > 40927 > 42:39653 43:39048 44:38701 45:40059 46:39197 47: > 38769 > 48:37620 49:40328 50:41233 51:42655 52:40946 53: > 41503 > 54:40446 55:38491 56:39515 57:39991 58:39151 59: > 39603 > > Last 24 hours: > 0: 1477066 1: 2344774 2: 2073201 3: 1925822 4: 1787530 5: > 1609260 > 6: 1383548 7: 1040609 8: 809206 9: 696466 10: 671836 11: > 845894 > 12: 1267113 13: 1939370 14: 2627395 15: 3258609 16: 3606961 17: > 3573903 > 18: 3318069 19: 3093698 20: 2457813 21: 2331525 22: 2296393 23: > 2455807 > ___ > 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
Re: [j-nsp] SRX deployment / issues
I know there was/is an issue on the older code versions of sessions being built with the incorrect time out (if I recall correctly it was 48 hours). It's easy to see though all one would have to do is look at a type of session that you know would have a short duration time (such as ICMP or UDP) and if you see a extremely large number then you've got an issue. In the past on the netscreen platform I've seen various issues with the NATAGER process (the process responsible for session table clean up) but so far at least in my experience I haven't ran into an like that on the SRX platform. -Tim Eberhard On Tue, Mar 23, 2010 at 7:21 AM, Fahad Khan wrote: > Seems to be looking some thing wrong with session table?? > > any one faced same thing with SRX650?? > > regards, > Muhammad Fahad Khan > JNCIP - M/T # 834 > IT Specialist > Global Technology Services, IBM > fa...@pk.ibm.com > +92-321-2370510 > +92-301-8247638 > Skype: fahad-ibm > http://www.linkedin.com/in/muhammadfahadkhan > http://fahad-internetworker.blogspot.com > http://www.visualcv.com/g46ptnd > > > On Tue, Mar 23, 2010 at 5:10 PM, Michael Dale wrote: > > > I've had some serious issues with both my SRX 210 and 2x240s. > > > > The SRX210 I have here at home was having all kinds of issues > reconnecting > > if there was an ADSL drop. A restart routing command would fix this. This > > issue seems to have been mostly fixed in 10.0R2 and 10.1R1. > > > > The pair of SRX240s on the other hand are still having issues. I recently > > setup a cluster with 10.1R1 which was all working fine in the lab, but > after > > 10 ours of production all traffic simply stopped. I've logged into the > > devices via the console and cannot find any errors. No idea what is going > on > > here. Not to mention the issues with ethernet switching and clustering... > > > > Oh and no support for packet based traffic in clusters, so no IPv6 at > all. > > > > The older SSG line will have to keep me going until juniper fix some of > > these issues! > > > > Michael. > > > > - Original Message - > > From: Hoogen [mailto:hooge...@gmail.com] > > To: > > juniper-nsp@puck.nether.net > > Sent: Tue, 23 Mar 2010 04:05:46 +1100 > > Subject: > > [j-nsp] SRX deployment / issues > > > > > > > I think the EX thread was really good and the feedback was awesome. I > > would > > > like hear about similar experiences while deploying SRX Series > gateways, > > I > > > am assuming I would hear a lot on the branch boxes SRX 210,240,650 I > > would > > > also love to hear feedback on SRX 3000/5000 if people have been using > it > > in > > > their setup, problems that their facing, improvements and general > > deployment > > > scenario that have been used. > > > > > > -Hoogen > > > ___ > > > 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 > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] completely disable session (flow) in netscreen
To deal with asymmetric routing problems you can disable tcp-syn-checking. That will disable the stateful enforcement (and greatly weaken security of the box). I'd also ensure you disable syn-checking in the tunnel (since you're using ipsec tunnels). Beyond that, write your policy bi-directionally ensuring any side can create the session and that should fit your needs. Even if the session times out with syn-checking disabled and it's permitted by policy it will be instantly recreated with the next packet. Hope this helps, -Tim Eberhard On Sat, Mar 6, 2010 at 3:34 AM, Michel de Nostredame wrote: > Hi, > > The problem I encountered is that I am doing many route-based tunnels > on many NetScreen boxes, and sometimes there will be asymmetric routes > over tunnels and physical interfaces. > > Asymmetric paths in traditional routers / L3-switches will not be a > problem, but in NetScreen that will cause session drops and/or > traceroute timeouts, in my case. > > I am wondering if there is any way to *completely* disable the > concepts of session (or flow ...) in a NetScreen to make it acts like > a "router". > > Thanks in advance. > -- > Michel~ > ___ > 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
Re: [j-nsp] Juniper.net website problems?
I just tried to update a JTAC case and I'm getting the same problem. So not just your issue Paul. Hopefully it's resolved soon. -Tim Eberhard On Thu, Feb 25, 2010 at 8:04 AM, Paul Stewart wrote: > Hi folks - am I the only person having issues with Juniper's website this > morning? > > > > Doing a site search and get a "We are sorry. the page or service you are > trying to access" > > > > Can login but as soon as I try to access any software I get the same error > page.. anyone else having this issue or is it just special to me? ;) > > > > 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
Re: [j-nsp] JUNOS vulnerability with malformed TCP packets
Jonas, Correct firewall filters *will* block it as the firewall filter will keep the tcp port even responding. However if your router has a tcp port open to a specific subnet IP's on that subnet will be able to exploit. In other words there is no specific firewall filter that can be put in place to completely protect the router from this attack (i.e. don't accept a tcp packet with these flags). Best practices are obviously to configure firewall filters to only allow trusted networks to access the router via telnet/ssh/etc and only trusted hosts to connect via BGP. If those are in place your router is much less vulnerable. While it is a major issue it is one that should not be a problem if you have your firewall filters locked down properly. Just my 2 cents. -Tim Eberhard On Tue, Jan 12, 2010 at 11:22 AM, Jonas Frey wrote: > Hello, > > i have tried exploiting this on various junos version (8.2, 8.5, 9.2), > all of them crashed immediatly at tcp_input() and rebooted after dumping > the core. > > However 7.4 seems to be not vulnerable. Atleast the version i have here > (7.4I20071211_1225_pgoyette) is not affected. Therefor i guess > everything below this (atleast) is not vulnerable...that would explain > why juniper had 6.x removed from the advisory on vulnerable releases. > (But 7.x is still listed...). > I still have 6.x somewhere...if anyone is interessted i can try this on > a spare unit. > > One more thing: I was able to firewall this on all releases. So ACL's do > work for some extend. Also you need an open port for this to work (BGP > etc). > > Regards, > Jonas Frey > > On Fri, 2010-01-08 at 17:41, Florian Weimer wrote: > > * Barry Greene: > > > > > The information is in the security advisory. > > > > Are the PSNs the security advisory you are referring to? > > > > I didn't see a security advisory as such, and I'm wondering if I'm > > missing anything. > > > ___ > 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
Re: [j-nsp] Routing issues with SRX210
The first thing I would check is the logs. Do you see a rdp deamon problem or anything along those lines? On Mon, Oct 5, 2009 at 2:21 AM, Michael Dale wrote: > Hi All, > > I'm having some issues with my SRX210 running JunOS 9.6 > > I'm using an SSG 20 ADSL mini-pim (which could be my problem as it isn't > supported). > > Basically what happens is the ADSL connection seems to drop out; yet I am > still able to ping the ISP gateway address. > > If I run "restart routing" on the SRX it fixes the problem, but the problem > comes back every week or so. > > The routing table looks okay and I can ping the ISP gateway from devices > behind the SRX but nothing else. > > Does anyone have any ideas on how to track this problem down? > > Thanks, > Michael. > ___ > 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
Re: [j-nsp] JNCIE-FWV
As far as I know, no.. It was created and even beta tested. There are a couple of juniper (and former juniper) employees walking around with the title but last I heard it is not available to the public. Without any inside knowledge I would attribute this to the SRX platform and the Junos Security line up that was released. The JNCIE-FWV did not cover that in any form. I assume they are going to integrate the new OS and platform into the test and then release it.. at least I hope they release it. Sorry I couldn't give you a decisive answer but hopefully this helps, -Tim Eberhard On Fri, Aug 7, 2009 at 8:27 PM, Fahad Khan wrote: > Dear Folks, > > Has this certification been launched??? can any one provide the > outline/Info > for this please. > > Thanks in advance, > > regards, > > -- > Muhammad Fahad Khan > IT Specialist > Global Technology Services, IBM > fa...@pk.ibm.com > +92-321-2370510 > +92-301-8247638 > http://www.linkedin.com/in/muhammadfahadkhan > http://fahad-internetworker.blogspot.com > ___ > 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
Re: [j-nsp] How to upgrade junos 5.0.0r8.1
The bin file is within the ZIP. You will load the bin to the firewall. I would highly recommend against using anything but juniper.net to download your netscreen software. Never ever get your images from any where but directly from Juniper. The firewall images could contain back doors, root kits or other such harmful things when using an external source such as gegereka. -Tim Eberhard On Wed, Jul 15, 2009 at 3:48 AM, George wrote: > Hello again. > > Just to confirm the steps if they are correct: > 1. download the firmware I want to upgrade to ie 5.2.0r2.0 (Do i get the > zip file or the bin, or is the bin file contained in the zip file) > 2. From the Juniper GUI browse and load the Image to be upgraded. > 3. Once loaded reboot the juniper for the changes to take effect. > > Problem here again, I have been re-tryin to download the zip file from > www.gegereka.com even after getting the access code, what and where is the > easiet URL to download the update? > > Regards > George > > > > On Wed, 2009-07-15 at 09:29 +0300, George wrote: > > Thanks Guys, atleast that gives a success rate guarantee of around 90%, > better than some of those Vaccine drugs in the market. > > Cheerz > > On Mon, 2009-07-13 at 15:42 -0500, Tim Eberhard wrote: > > You configuration will remain after the upgrade/reboot. > > Downgrading is the same process as upgrading as long as you're going from > say 5.2 to 5.0. Just load the 5.0 image and reboot. The 5.0 image is blown > away when you load the newer screenOS. > > Good luck, > -Tim Eberhard > > On Mon, Jul 13, 2009 at 11:04 AM, George wrote: > > Thanks Guys, > > Sure I had planned to upgrade to above 5.2 , are these firmwares available > for download? > > So the next question is really about the configs, Once a reboot is done all > the previous setting take in effect, is that so? And for a rollback the do I > just scroll for the image? > > Regards > George > > > > > On Mon, 2009-07-13 at 17:39 +0300, Humair Ali wrote: > > Hi Georges > > Tim is absolutely correct, and since you are using the 2 netscreens as a > standalone, you are bound to have downtime. > > One other , I believe (needs to verify) you can't go straight from 5.0 to > 6.x, you need to upgrade through an intermediary such as 5.4 then upgrade > 6.x so that is added downtime since again code needs to be reloaded after > upgrade to 5.4 and then to 6.0 > > HTH > > > > 2009/7/13 Tim Eberhard > > George, > > It's not possible to preform any kind of hitless upgrade.. > > The Netscreen must reboot once the new code is loaded. So you must factor > in > the time it will take for the firewall to reload in addition to the hit it > will take when the wall comes back online and the traffic starts to flood > back. Depending on the size of your network/amount of VPN tunnels it could > take a couple of minutes for everything to ramp back up. > > Downgrading code is possible depending what code version you're going to. > It > can be a bit problematic if say you go to 6.X code from 5.0 but if you had > planned on going from 5.0 to 5.4 going back shouldn't be much of a problem. > > Good luck, > > -Tim Eberhard > > > > On Mon, Jul 13, 2009 at 7:12 AM, George wrote: > > > Sorry guys, > > > > The two firewalls are in completely two different networks and in no way > > work together. The reason I mentioned the two is because I tried the > > same VPN on the other Firewall with a higher firmware and it worked > > within minutes of set-up. So i really want to upgrade this firewall. > > > > Thanks > > George > > > > On Mon, 2009-07-13 at 17:17 +0500, mas...@nexlinx.net.pk wrote: > > > > > Are you using both of the firewalls as n active/active or > active/passive; > > > if yes thn you can try upgrading one of them while the other will take > > > care of your production services. > > > > > > Regards, > > > Masood > > > > > > > Hi there, > > > > > > > > I have two juniper netscreens one is Firmware 5.0.0r8.1 . Now I have > > > > encountered a problem when setting up a VPN on this one due to > firmware > > > > version thus I need to upgrade it. > > > > > > > > The question is how do I upgrade this firmware, challenge being that > it > > > > is running live services and if the upgrade fails how do I roll-back. > > > > Guess the thing is I have to be 100% sure the upgrade will not affect > > > > anything. > > > > > > > > Cheers. > > > > George >
Re: [j-nsp] Virtual Firewall Security Appliances
The NS5400 can do 300 or vsys' I am unsure how many the ISG/SSG will do. The ASA's context modes are limited and have multiple "gotchas" once you start using them. I've found no such limitations on the 6.X line of ScreenOS. Using Virtual Systems you can do everything that you wanted to do and have it completely segmented. I am by no means a Vsys expert although I do have a a couple of 5400's that have 300 or so on each. I can say I'm pretty happy with their capabilities over all. Good luck, -Tim Eberhard On Tue, Jul 14, 2009 at 9:09 PM, Clue Store wrote: > Hi List, > > My team and I have been quite attched to our C ASA/PIX boxen up until this > past week. My VP of Ops purchased a shiny new ASA 5550 with 50 context > licenses. As I am reading up on the configuration of the multiple context > mode, I discover that "wow, NO VPN SUPPORT in MULTIPLE CONTEXT MODE?!?!". > Needless to say, I was very dissappointed to find out that we not have a > huge slightly more sofisticated packet filter that can do ACL's. This does > me no good. My questions do any of the Juniper SSG, ISG, Netscreen boxes > support VPN's on each virtual firewall?? If so, whch models are comprable > to > the 5550 in pps, amount of tunnels, etc?? Off-list is fine. I will repost > my > findings if anyone cares to know as well. > > TIA, > Clue > ___ > 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
Re: [j-nsp] How to upgrade junos 5.0.0r8.1
You configuration will remain after the upgrade/reboot. Downgrading is the same process as upgrading as long as you're going from say 5.2 to 5.0. Just load the 5.0 image and reboot. The 5.0 image is blown away when you load the newer screenOS. Good luck, -Tim Eberhard On Mon, Jul 13, 2009 at 11:04 AM, George wrote: > Thanks Guys, > > Sure I had planned to upgrade to above 5.2 , are these firmwares available > for download? > > So the next question is really about the configs, Once a reboot is done all > the previous setting take in effect, is that so? And for a rollback the do I > just scroll for the image? > > Regards > George > > > > On Mon, 2009-07-13 at 17:39 +0300, Humair Ali wrote: > > Hi Georges > > Tim is absolutely correct, and since you are using the 2 netscreens as a > standalone, you are bound to have downtime. > > One other , I believe (needs to verify) you can't go straight from 5.0 to > 6.x, you need to upgrade through an intermediary such as 5.4 then upgrade > 6.x so that is added downtime since again code needs to be reloaded after > upgrade to 5.4 and then to 6.0 > > HTH > > > > 2009/7/13 Tim Eberhard > > George, > > It's not possible to preform any kind of hitless upgrade.. > > The Netscreen must reboot once the new code is loaded. So you must factor > in > the time it will take for the firewall to reload in addition to the hit it > will take when the wall comes back online and the traffic starts to flood > back. Depending on the size of your network/amount of VPN tunnels it could > take a couple of minutes for everything to ramp back up. > > Downgrading code is possible depending what code version you're going to. > It > can be a bit problematic if say you go to 6.X code from 5.0 but if you had > planned on going from 5.0 to 5.4 going back shouldn't be much of a problem. > > Good luck, > > -Tim Eberhard > > > > > On Mon, Jul 13, 2009 at 7:12 AM, George wrote: > > > Sorry guys, > > > > The two firewalls are in completely two different networks and in no way > > work together. The reason I mentioned the two is because I tried the > > same VPN on the other Firewall with a higher firmware and it worked > > within minutes of set-up. So i really want to upgrade this firewall. > > > > Thanks > > George > > > > On Mon, 2009-07-13 at 17:17 +0500, mas...@nexlinx.net.pk wrote: > > > > > Are you using both of the firewalls as n active/active or > active/passive; > > > if yes thn you can try upgrading one of them while the other will take > > > care of your production services. > > > > > > Regards, > > > Masood > > > > > > > Hi there, > > > > > > > > I have two juniper netscreens one is Firmware 5.0.0r8.1 . Now I have > > > > encountered a problem when setting up a VPN on this one due to > firmware > > > > version thus I need to upgrade it. > > > > > > > > The question is how do I upgrade this firmware, challenge being that > it > > > > is running live services and if the upgrade fails how do I roll-back. > > > > Guess the thing is I have to be 100% sure the upgrade will not affect > > > > anything. > > > > > > > > Cheers. > > > > George > > > > ___ > > > > 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 > > > > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] How to upgrade junos 5.0.0r8.1
George, It's not possible to preform any kind of hitless upgrade.. The Netscreen must reboot once the new code is loaded. So you must factor in the time it will take for the firewall to reload in addition to the hit it will take when the wall comes back online and the traffic starts to flood back. Depending on the size of your network/amount of VPN tunnels it could take a couple of minutes for everything to ramp back up. Downgrading code is possible depending what code version you're going to. It can be a bit problematic if say you go to 6.X code from 5.0 but if you had planned on going from 5.0 to 5.4 going back shouldn't be much of a problem. Good luck, -Tim Eberhard On Mon, Jul 13, 2009 at 7:12 AM, George wrote: > Sorry guys, > > The two firewalls are in completely two different networks and in no way > work together. The reason I mentioned the two is because I tried the > same VPN on the other Firewall with a higher firmware and it worked > within minutes of set-up. So i really want to upgrade this firewall. > > Thanks > George > > On Mon, 2009-07-13 at 17:17 +0500, mas...@nexlinx.net.pk wrote: > > > Are you using both of the firewalls as n active/active or active/passive; > > if yes thn you can try upgrading one of them while the other will take > > care of your production services. > > > > Regards, > > Masood > > > > > Hi there, > > > > > > I have two juniper netscreens one is Firmware 5.0.0r8.1 . Now I have > > > encountered a problem when setting up a VPN on this one due to firmware > > > version thus I need to upgrade it. > > > > > > The question is how do I upgrade this firmware, challenge being that it > > > is running live services and if the upgrade fails how do I roll-back. > > > Guess the thing is I have to be 100% sure the upgrade will not affect > > > anything. > > > > > > Cheers. > > > George > > > ___ > > > 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
Re: [j-nsp] Bulk updates to Netscreen 5400
I would not suggest playing with that fire... My personal suggestion to make "bulk" updates or update many configuration items at once would be to create the list of changes to a file and then tftp merge it into the configuration. It will go very fast and you can tell if anything errored out instantly. merging part 1000 lines via tftp takes just 10-15 seconds. Good luck, -Tim Eberhard On Fri, Jun 26, 2009 at 6:52 AM, Phil Mayers wrote: > All, > > We have a (quite busy) netscreen 5400, which we occasionally need to make > big policy updates to. It goes very slow if we paste in changes via the CLI, > and we're not inclined to buy Netscreen Security Manager (or whatever it's > called these days) because our reseller stiffed us on a promised upgrade, > and the demo we had was anyway pretty underwhelming. > > However - I have it on good authority that NSM merely uses a hidden CLI > command to start & commit bulk updates "all at once", a bit like SQL > > e.g. > > set mode bulk > set address Trust ... > ...100 more lines > set mode bulk-commit > > ...or something like that. Does anyone know what those magic commands are, > if they really exist? Are there any caveats to using them? > ___ > 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
Re: [j-nsp] nsrp ha link over ex4200
Silly question... Why would you not just cable the firewalls directly into each other? What is the point of adding a couple of additional points of failure if you don't have to? Unless you're working with two firewalls at two physical geographic locations I see no reason to have a switch in between the two firewalls. Perhaps I don't clearly understand what your goals and reasons for using the switches are. -Tim Eberhard On Tue, Apr 28, 2009 at 3:17 AM, Yordan Boikov wrote: > Hi, > > we have two SSG 520M firewalls and two ex4200 switches > > > [ SSG520M fw1 ][eth1/7] - [ge-0/0/3][ ex4200 sw1 > ][ge-0/1/2]===trunk===[ge-0/1/2][ ex4200 sw2 ][ge-0/0/3] [eth1/7][ > SSG520M fw2 ] > > I want to configure HA between fw1 and fw2 > the problem is that sw2 doesn't see fw1 > > sw1>show ethernet-switching table vlan ha-vlan > Ethernet-switching table: 2 unicast entries > VLAN MAC address Type Age Interfaces > ha-vlan * Flood - All-members > ha-vlan 00:22:83:88:38:15 Learn 0 ge-0/0/3.0 > ha-vlan 00:22:83:88:3f:15 Learn 0 ge-0/1/2.0 > > sw2> show ethernet-switching table vlan ha-vlan > Ethernet-switching table: 1 unicast entries > VLAN MAC address Type Age Interfaces > ha-vlan * Flood - All-members > ha-vlan 00:22:83:88:3f:15 Learn 0 ge-0/0/3.0 > > > both switches have same config and same junos version. > IGMP snooping is disable for all VLANs > > > > -- > Yordan Boikov > :wq > > ___ > 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
Re: [j-nsp] Sample configuration: security {}
That KB is to turn Junos-ES into a router device..
the first part:
no-syn-check;
no-syn-check-in-tunnel;
no-sequence-check;
Basically turns off *all* state full tcp. At that point you might as well be
using stateless acl's.
The next portion is to disable the ALG's (application layer gateways). Again
if the end goal here is to use this device as a router, I agree with it.
If you're trying to use the security{} options as a firewall then do *not*
follow that KB.
Good luck,
-Tim Eberhard
On Mon, Apr 6, 2009 at 1:37 AM, wrote:
>
>
> KB11963 recommends also add
> flow (
> allow-dns-reply;
> tcp-session (
> no-syn-check;
> no-syn-check-in-tunnel;
> no-sequence-check;
> )
> )
>
> and
>
> alg (
> dns disable;
> ftp disable;
> h323 disable;
> mgcp disable;
> real disable;
> rsh disable;
> rtsp disable;
> sccp disable;
> sip disable;
> sql disable;
> talk disable;
> tftp disable;
> pptp disable;
> msrpc disable;
> sunrpc disable;
> )
>
> as well as
> zones (
> security-zone trust (
> tcp-rst;
>
> Is there a meaning to make these changes?
>
>
>
>
> On Fri, 03 Apr 2009 15:04:58 +0200, Tomasz Klicki
> wrote:
> > t...@osystems.ru pisze:
> >> Please give me a sample configuration, security {} for the JUNOS
> Software
> >> Release [9.4R1.8] (Export edition) Enhanced Services for the BGP router
> >> (border router).
> >
> > Here you are:
> >
> > security {
> > zones {
> > security-zone zone_default {
> > host-inbound-traffic {
> > system-services {
> > all;
> > }
> > protocols {
> > all;
> > }
> > }
> > interfaces {
> > all;
> > }
> > }
> > }
> > policies {
> > default-policy {
> > permit-all;
> > }
> > }
> > }
> ___
> 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
Re: [j-nsp] transfer between 2 ns2000's is slow
Can you debug the traffic and send me the output? 'debug tag info' is sufficient. On Wed, Feb 11, 2009 at 5:20 PM, Leslie wrote: > It's always the flow cpu that spikes up > > Tim Eberhard wrote: > >> Leslie, >> >> please issue the "get perf cpu all detail" command to see if which CPU is >> going up. I suspect you're hitting an ALG or this is going to CPU for some >> odd reason. >> >> -Tim Eberhard >> >> On Tue, Feb 10, 2009 at 1:46 PM, Leslie > les...@craigslist.org>> wrote: >> >>I'm having a strange problem that I haven't been able to fix after >>much studying -- >> >>Basically my setup is host 1 - fw1 - dedicated 1gige link (~25ms >>lag) - router2 - fw2 - host 2 >> >>I can blast udp across this pipe without a problem, but tcp traffic >>seems to be limited to about 3 mbyte/s -- I can make multiple >>sessions that are all transferring at this speed, but no individual >>session will go over that "limit" >> >>Another thing that makes me extremely suspicious is occasionally >>when I start a transfer I'll see a brief cpu spike -- like shown below >> >> get perf cpu detail >>Average System Utilization: 21% >>Last 60 seconds: >>59: 3758: 3457: 3856: 2755: 3954: 38 >>53: 81** 52: 76** 51: 81** 50: 77** 49: 82** 48: 62* >>47: 3646: 3745: 3544: 3643: 3642: 35 >>41: 3240: 3739: 3338: 3737: 3436: 39 >>35: 3334: 3833: 3332: 3931: 3330: 39 >>29: 3128: 4027: 2926: 4225: 3524: 41 >>23: 3522: 3821: 3120: 3519: 3218: 41 >>17: 3516: 3815: 3414: 3913: 3512: 40 >>11: 3310: 40 9: 32 8: 39 7: 45 6: 39 >> 5: 34 4: 40 3: 35 2: 42 1: 36 0: 39 >> >> >>I've obviously spent hours and hours on the phone/email with tac >>without much help. Does anyone have any ideas of what could be >>doing this? Any troubleshooting tips? >> >>Thank you >> >>Leslie >>___ >>juniper-nsp mailing list juniper-nsp@puck.nether.net >><mailto: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
Re: [j-nsp] transfer between 2 ns2000's is slow
Leslie, please issue the "get perf cpu all detail" command to see if which CPU is going up. I suspect you're hitting an ALG or this is going to CPU for some odd reason. -Tim Eberhard On Tue, Feb 10, 2009 at 1:46 PM, Leslie wrote: > I'm having a strange problem that I haven't been able to fix after much > studying -- > > Basically my setup is host 1 - fw1 - dedicated 1gige link (~25ms lag) - > router2 - fw2 - host 2 > > I can blast udp across this pipe without a problem, but tcp traffic seems > to be limited to about 3 mbyte/s -- I can make multiple sessions that are > all transferring at this speed, but no individual session will go over that > "limit" > > Another thing that makes me extremely suspicious is occasionally when I > start a transfer I'll see a brief cpu spike -- like shown below > > get perf cpu detail > Average System Utilization: 21% > Last 60 seconds: > 59: 3758: 3457: 3856: 2755: 3954: 38 > 53: 81** 52: 76** 51: 81** 50: 77** 49: 82** 48: 62* > 47: 3646: 3745: 3544: 3643: 3642: 35 > 41: 3240: 3739: 3338: 3737: 3436: 39 > 35: 3334: 3833: 3332: 3931: 3330: 39 > 29: 3128: 4027: 2926: 4225: 3524: 41 > 23: 3522: 3821: 3120: 3519: 3218: 41 > 17: 3516: 3815: 3414: 3913: 3512: 40 > 11: 3310: 40 9: 32 8: 39 7: 45 6: 39 > 5: 34 4: 40 3: 35 2: 42 1: 36 0: 39 > > > I've obviously spent hours and hours on the phone/email with tac without > much help. Does anyone have any ideas of what could be doing this? Any > troubleshooting tips? > > Thank you > > Leslie > ___ > 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
Re: [j-nsp] Control Plane Protection
There is an excellent book out that you should read. JUNOS Enterprise Routing. Here is what you're looking for: http://books.google.com/books?id=UI2ZwjIgBwwC&pg=PA307&lpg=PA307&dq=control+plane+firewall+filters+junos&source=web&ots=oIrptUEjBt&sig=UeATL7Uf1NjUNBQYb3HRPe7HQr4&hl=en&sa=X&oi=book_result&resnum=1&ct=result Good luck, -Tim Eberhard On Tue, Jan 27, 2009 at 4:40 PM, Andrew Jimmy wrote: > > > You are concerned about DoS attacks against a key perimeter router in your > company. Configure router so that it limits the aggregate rate of ARP > traffic toward the route processor to 75 packets per second. Routing > control > traffic marked with an IP Precedence value of 6 should be limited to 100 > packets per second. How do you do this in JUNOS? > > > > Here is the way you do on Cisco router: > > > > class-map match-all RP > match ip precedence 6 > class-map match-all ARP > match protocol arp > ! > ! > policy-map CoPP > class ARP > police rate 75 pps > class RP > police rate 100 pps > ! > control-plane > ! > service-policy input CoPP > > ___ > 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
Re: [j-nsp] Junos sticker
I've also seen "I wish this ran JunOS" bumper sticker. That one was made by a Juniper employee and the marketing dept made a few runs of those as well. . -Tim Eberhard On Wed, Dec 10, 2008 at 6:28 PM, Aviva Garrett <[EMAIL PROTECTED]> wrote: > Juniper Marketing made them a while ago, so they should be floating around > various places. > > Aviva > > In message <[EMAIL PROTECTED]>you > write: > > Has anybody seen these? > > http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=180313229707 > > or > > http://tinyurl.com/5wemy5 > > > > I guess there is a video on youtube of they guy who created it, just > > sure if that's a spoof or not. > > ___ > > 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
Re: [j-nsp] Screenos interface
Just as important.. To do a no shut on that port.. unset interface eth0/0 phy link-down On Mon, Nov 10, 2008 at 4:23 AM, GIULIANO (UOL) <[EMAIL PROTECTED]>wrote: > For ethernet interfaces: > > set interface eth0/0 phy link-down > > > > Hello is it possible to shutdown an interface in screenos? > > i have seen the "exec interface" command but nothing comes out. > > thank you > > ___ > > 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
Re: [j-nsp] Netscreen mailing list?
Sorry there is also the nn list but it's not very chatty. http://www.compsoc.com/cgi-bin/mailman/listinfo/nn On Mon, Oct 13, 2008 at 6:39 PM, Tim Eberhard <[EMAIL PROTECTED]> wrote: > Juniperforum.com is a decent place to chat it up with other netscreen > users. > > -Tim Eberhard > > > On Mon, Oct 13, 2008 at 6:35 PM, Janet Sullivan <[EMAIL PROTECTED]> wrote: > >> It seems the old qorbit nn list is no more. Where do all the netscreen >> types hang out these days? I don't see a netscreen specific list on puck. >> ___ >> 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
Re: [j-nsp] Netscreen mailing list?
Juniperforum.com is a decent place to chat it up with other netscreen users. -Tim Eberhard On Mon, Oct 13, 2008 at 6:35 PM, Janet Sullivan <[EMAIL PROTECTED]> wrote: > It seems the old qorbit nn list is no more. Where do all the netscreen > types hang out these days? I don't see a netscreen specific list on puck. > ___ > 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
Re: [j-nsp] In case you missed it...
I've been playing with it for a while now. Looks sweet.. There are some JunOS-ES stuff I am not a fan of (The policy system needs a *LOT* of work) however over all the product is there. I would love to hear from others as they test/deploy it now that NDA is finally lifted.. -Tim Eberhard On Mon, Sep 15, 2008 at 12:08 PM, Stefan Fouant <[EMAIL PROTECTED]> wrote: > Juniper just released the SRX platform. 120 Gbps / 15Mpps of > firewalling, 30 Gbps of IPS, and 4 Million concurrent sessions! Holy > crap - this box looks sweet. I've wanted to talk about this box for > so long but was restricted due to NDA. Can't wait to take a more > detailed look under the hood. > > http://www.juniper.net/products/srx/dsheet/100254.pdf > > -- > Stefan Fouant > Principal Network Engineer > NeuStar, Inc. - http://www.neustar.biz > GPG Key ID: 0xB5E3803D > ___ > 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
Re: [j-nsp] SRX-series Services Gateways?
JunOS-ES is their new firewall platform. One could safely assume that this is their new firewall platform (It'll be officially out next month). Until the SRX all JunOS-ES firewalls have ran on lower end software based devices (SSG-550M, J routers, etc) Hope this clears it up slightly. -Tim Eberhard On Sat, Aug 23, 2008 at 8:07 AM, Nahrux M <[EMAIL PROTECTED]> wrote: > Greetings, > > I came across this document > > > > http://www.juniper.net/techpubs/software/junos-es/junos-es92/junos-es-swconfig-security/overview-of-srx-series-services-gateways-running-junos-software.html > > Is this a new product? I do not see any product documentation on their web > site. > > Regards > ___ > 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
