Re: Firewall list recommendations (config conversion options)
The firewall mailing lists tend to be pretty dead now a days. Your best bet is probably writing a python script to convert the rules/objects over. You may have some luck asking the vendors professional services group to do it. Depending on the size of the order perhaps you can toss it in or just add the hours to the PO. Most PS groups have scripts already written to convert from other vendors configs to their platform. Good luck, -Tim Eberhard On Sun, Apr 24, 2016 at 6:59 PM, b f <freetexwat...@gmail.com> wrote: > Hi list, > > Could any one recommend any firewall related mailing lists? > > Looking for options on converting a large amount of Fortinet rules to > Checkpoint. Ultimately converting the entire configuration to Checkpoint > would be nice. > > Thank you for any advice you can provide. > > Respectfully, > > Ed >
Fw: new message
Hey! New message, please read <http://doctorcatherinebarry.com/getting.php?li> Tim Eberhard
Re: Cheap Juniper Gear for Lab
I find it humorous that you think J/SRX junos isn't real junos. So what makes it not real junos? The fact it has a flowd process? Lets technically talk about this for a moment. Realistically one of the only differences between flow based junos and the legacy packet based junos is the flowd process. Which can be easily bypassed by issuing a couple of configuration commands. So what exactly makes this platform/code so horrible and not real junos? If anything to me it's a better platform to deploy and learn on. It's more flexible as it comes with more advanced flow based features but they are optional. There are certain limitations as mentioned previously around the switching and class of service however these same feature limitations were also in the real junos low end devices. If there are other differences that I am unaware of then by all means feel free to educate me. I am well aware that branch devices don't have the capabilities of the MX/M series in regards to ATM and other such specific platforms, but you called this not real junos. So lets keep any responses limited to that aspect. -Tim Eberhard On Tue, Apr 10, 2012 at 1:33 PM, Owen DeLong o...@delong.com wrote: If you want real JunOS, avoid SRX or J series at all costs. Juniper do have a bunch more lines, but those are the most common (there's also the E/ERX BRAS boxes and ScreenOS firewalls, but both are not long for this world). Don't forget their SSL VPN boxes which are an acquired doesn't behave at all like a Juniper device line of products. If you just want one box to get to know the OS an SRX2X0 (or possibly a 100) is by far the most flexible way, and can be had for $500 used). With the caveat about Services JunOS above. Owen
Re: Cheap Juniper Gear for Lab
Owen, While I know you are a smart engineer and obviously have been working with this gear for a long time you're really not adding anything or backing up your argument besides saying yet again the packet forwarding is different. While this maybe true..It's my understanding that enabling packet mode does turn it into a normal packet based junos. Admittedly I have limited experience with turning these branch devices into pure packet mode so instead of repeating the same thing over and over why not provide links and other documentation showing the difference? On Tue, Apr 10, 2012 at 8:23 PM, Owen DeLong o...@delong.com wrote: On Apr 10, 2012, at 4:05 PM, Jimmy Hess wrote: On Tue, Apr 10, 2012 at 9:24 AM, Tim Eberhard xmi...@gmail.com wrote: I find it humorous that you think J/SRX junos isn't real junos. If it runs JunOS, then yeah, it's real JunOS. It might not have the feature you're looking for, but that's something different. No, it's not. Flow mode is NOT packet mode and it doesn't really ever run packet mode in the current version. This has fundamental and significant impacts on the way packets are handled when being forwarded through the box which come with side-effects that cannot be overcome by mere configuration changes. The Juniper ERX edge routers are what isn't real JunOS. It's as if they were trying to make a clone of the IOS CLI: Those are not JunOS at all. They don't really try to pretend to be. The SRX and J-Series Services routers, OTOH, are most definitely pretending to be JunOS while not behaving like JunOS at certain fundamental levels. Owen
Re: Internet Edge and Defense in Depth
To echo what James has already said.. I would say it's possible on the low/medium size enterprise network market. With that stated 70-80% of the time it's not designed correctly or a vendor issue pops up causing them to disable the feature. Careful planning must be done ahead of time. When looking at the spec sheets you can't look at the numbers and take them for face value. In most cases those numbers were achieved when *only* running that specific feature. So if a vendor claims 90meg of IPS throughput, 500meg of firewall throughput and 100meg of UTM. Chances are that 90meg of IPS traffic will take the box to it's knees. So if you're planning using the data sheet numbers you've most likely already failed. Plan carefully, test throughly, and in the end..you still may hit a bug or unexpected show stopper. I'd rather use the best tool for the job rather than jam everything into once box so I can share a chassis... Just my two cents, -Tim Eberhard On Tue, Dec 6, 2011 at 3:32 PM, JAMES MCMURRY j...@miltonsecurity.com wrote: I have seen at quite a few of our customers locations, starting out with a lofty goal of putting everything in a single box (UTM) and turning every single option on. In ~ 30% of the firms who do so it works out ok (not great, but it works). In the majority, the customer winds up turning features off one by one, and moving those to another system. Jim On Dec 6, 2011, at 1:25 PM, -Hammer- wrote: I personally have not seen it done in large environments. Hardware isn't there yet. I've seen it done in small business environments. Not a fan of the idea. -Hammer- I was a normal American nerd -Jack Herer On 12/06/2011 03:16 PM, Holmes,David A wrote: Some firewall vendors are proposing to collapse all Internet edge functions into a single device (border router, firewall, IPS, caching engine, proxy, etc.). A general Internet edge design principle has been the defense in depth concept. Is anyone collapsing all Internet edge functions into one device? Regards, David This communication, together with any attachments or embedded links, is for the sole use of the intended recipient(s) and may contain information that is confidential or legally protected. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, dissemination, distribution or use of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by return e-mail message and delete the original and all copies of the communication, along with any attachments or embedded links, from your system.
Re: OOB
In my experience having your management run over product via VPN is not a great idea. If possible separate the two. Having been in Ops for many many years and having worked on both a well built nationwide network with a dedicated management/oob infrastructure that is completely separate from the CDN and working on a not so well built nationwide network that is built as cheap as possible with VPN's running over the production CDN.. I would highly recommend separating the two. No amount of policies or procedures will prevent your management network from going down during critical times. In my experience both MTTR and the over all sanity of anyone working on that network starts to go down the drain as they are always worried about impacting management and isolating themselves, or during an outage unable to fix the problems at hand in a reasonable amount of time. I understand not everyone can spend the money to have a dedicated management infrastructure, but it's well worth every penny when done correctly. Just my 2 copper. -Tim Eberhard On Tue, Jul 26, 2011 at 8:57 AM, harbor235 harbor...@gmail.com wrote: My question is, is it best practice to extend an inband VPN throughout for device management functions as well? And are all management services performed OOB, e.g network management, some monitoring, logging, authentication, flowdata, etc . If a management VPN is used is it also extended to managed customer devices?
Re: Troubleshooting TCP performance tutorial
To add on to that. Recently Wireshark Network Analysis was released. It's an excellent book covering wireshark and reading packet captures in general by Laura Chappell. I just finished reading it and I have to say it's an excellent book. Highly recommended. Between those two books I think you'll be very close to being a wireshark/packet capture guru. I hope this helps, -Tim Eberhard On Fri, Sep 17, 2010 at 7:33 PM, Joe Hamelin j...@nethead.com wrote: In a situation like yours I found Internet Core Protocols: The Definitive Guide by Eric Hall an easy to read guide to insuring that what you are seeing via wireshark. I was able to find an issue with the DF bit in a load balancer that was causing confounding headaches in a network using wireshark and this book. Walk it through the syn-ack dance and don't trust that the devices are handling it correctly. Start at one end and work your way through and insure to YOUR satisfaction that every device proscribes to the protocol. Don't rush, don't jump to conclusions. Just follow the packet. That's the best advice I can give you. http://oreilly.com/catalog/9781565925724/ -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 On Fri, Sep 17, 2010 at 5:06 PM, Abel Alejandro aalejan...@worldnetpr.com wrote: Greetings, This past week I have been trying to find the root cause of tcp performance problems of a few clients that are using a third party metro Ethernet for transport. RFC2544 tests (Layer 2) and iperf using UDP give good symmetric performance almost 100% the speed of the circuit. However all kind of TCP tests result in some kind of asymmetrical deficiency, either the upstream or downstream of the client is hugely different. The latency is not a huge factor since all the metro Ethernet connections have less than 2 ms. So the question basically if is there a good tutorial or white paper for troubleshooting tcp with emphasis of using tools like Wireshark to debug and track this kind of problems. Regards, Abel.
Re: D/DoS mitigation hardware/software needed.
Kinda funny you state that Roland. I know of at least two very large carriers that uses Netscreens (and soon SRX's) for their DoS/DDoS mitigation. State table exhaustion on the netscreen platform is something that is very easy to protect against with some protections and hasn't been a problem for years. If you can fill up a session table on a higher end SRX then I would be very very impressed. I would argue that firewalls place is in fact directly infront of servers and load balancers to protect them. On Mon, Jan 4, 2010 at 8:04 PM, Dobbins, Roland rdobb...@arbor.net wrote: On Jan 5, 2010, at 4:25 AM, Jeffrey Lyon wrote: Use a robust firewall such as a Netscreen in front of your mitigation tool. Absolutely not - the firewall will fall over due to state-table exhaustion before the mitigation system will. Firewalls (which have no place in front of servers in the first place), load-balancers, and any other stateful devices should be southbound of the mitigation system. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: 97.128.0.0/9 allocation to verizon wireless
Any cell phone that uses data service to download a ringtone, wallpaper, picature, use their TV/radio webcast service, or their walkie talkie feature will use an IP address. In addition to that Verizon wireless sells their EVDO aircards for laptops. Given the size of their customer base it is not shocking that they have 27 million IP addresses in their pool. ARIN doesn't just give them away it would be up to Verizon to prove that they are utilizing 90+% before they could be alloted any additional IP's. Hope this helps explain things a little bit. -Tim Eberhard Sure, smart phones are becoming more popular. It's reasonable to assume that virtually all cell phones will eventually have an IP address almost all the time. But that isn't the case right now, and the ARIN is in the business of supplying its members with six months worth of addresses. If everyone is expected to run out and buy a new phone and start using the Google right away, and stay on it all the time, maybe cellular operators really need a lot more IP addresses. If not, why does Verizon Wireless have 27 million IPs when the above comment indicates they need only a tenth of that? - j
Re: flattengraph.pl
I would suggest looking at Killspike. Works wonders in Cacti (A mtrg based app) Good luck, -Tim Eberhard On Wed, Jan 14, 2009 at 10:37 AM, Gregory Edigarov g...@bestnet.kharkov.uawrote: Hello, I have some problems with peaks on my mrtg, therefore I went to list archives on mrtg,org, and saw what's available. Then I found out that there is some script called flattengraph.pl, which I believe could help me with the situation. However this program is not available anymore and I cannot find and download it anywhere. So if some good soul will give me a link, or send me the file, I will be really grateful. Thanks a lot in advance. -- With best regards, Gregory Edigarov
Re: flattengraph.pl
My apologies you are correct. AFAIK killspike only works on rrdtool based set ups. If you have to use the old mrtg log system then it wouldn't help you in this case. If you were using MRTG with rrdtool you wouldn't have any issues however. Not sure if it's possible in your deployment but this might help you. http://oss.oetiker.ch/mrtg/doc/mrtg-rrd.en.html Good luck, sorry to lead you astray. -Tim Eberhard On Wed, Jan 14, 2009 at 11:12 AM, Gregory Edigarov g...@bestnet.kharkov.uawrote: Tim, Forgive me if I'm mistaken, but AFAIR killspike works with rrdtool, while i need to do magic on an old mrtg log format. -- With best regards, Gregory Edigarov Tim Eberhard wrote: I would suggest looking at Killspike. Works wonders in Cacti (A mtrg based app) Good luck, -Tim Eberhard On Wed, Jan 14, 2009 at 10:37 AM, Gregory Edigarov g...@bestnet.kharkov.ua mailto:g...@bestnet.kharkov.ua wrote: Hello, I have some problems with peaks on my mrtg, therefore I went to list archives on mrtg,org, and saw what's available. Then I found out that there is some script called flattengraph.pl, which I believe could help me with the situation. However this program is not available anymore and I cannot find and download it anywhere. So if some good soul will give me a link, or send me the file, I will be really grateful. Thanks a lot in advance. --With best regards, Gregory Edigarov
Re: Analysing traces for performance bottlenecks
One potentially useful piece of software that is a work in progress is called Pcapdiff. (http://www.eff.org/testyourisp/pcapdiff/) Written by Seth Schoen and Steven Lucy it's a pretty useful piece of software. While still in a relative infant stage I think it could mature into a very useful tool to troubleshoot network connectivity. Pcapdiff was originally written to find out if your ISP was toying with you P2P packets (comcast) and injecting resets. I have worked with the authors a bit and found it highly useful to take two packet captures on my network and use it to verify A) All packets sent are recieved B) They are in their original state. Again the features of pcapdiff are pretty limited but I love the idea of the program and I really think it could grow into an excellent tool to analyze packet captures with just a few additional features (a few listed below) -Tim Eberhard On Tue, Jul 15, 2008 at 5:05 AM, Sam Stickland [EMAIL PROTECTED] wrote: Hi, Are there any packages (or Wireshark options that I've missed) that can follow a TCP stream and determine the limiting factor on throughput. E.g Latency, packet loss, out of sequence packets, window size, or even just the senders rate onto the wire. I know how to analyse a trace by hand for performance issues, but it's relatively time consuming. Googling for variations on Analyse TCP stream limit throughput didn't find anything. Sam
Re: [Nanog] VoIP over Asymmetric routing
If there are any firewalls in the path they tend to dislike asymmetric routing(just standing the obvious).. It tends to play hell on the VoIP ALG's and can cause them to eat CPU/Hang/Crash depending on what vendor you have. This assumes that you have a firewall in the network path. Other items that would concern me is link utilization (What if one network link became completely saturated?) From a application stand point most VoIP systems will do ok with asymmetric routing RTP doesn't *need* to be symmetric but I would have concerns of designing it to be asymmetric out of the gates. Just my 2 copper. Tim Eberhard On Mon, Apr 21, 2008 at 1:34 AM, Kim Onnel [EMAIL PROTECTED] wrote: Hello, We are going to roll out a network to carry VoIP only, between the P routers, there will be 3xOC3 links. Each site has 2xPEs, PE1 is connected to the P router in the local premises with 10GE and PE2 is connected with 2xOC3s to remote P sites for backup incase local P fails. VoIP is going to be generated by Ericsson Media Gateways and the network designers are suggesting to take traffic in the outgoing direction through the PE1 path and come back through the PE2 path (if that makes sense), so traffic will take a different link for outgoing over incoming. From your experiences, I am wondering what are future unforeseen pitfalls we can get into? Regards, KO ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
