Juniper ScreenOS vs Cisco IOS CLI

Hi,

JunOS and ScreenOS resemble a lot. You can check out the below comparison;

http://www.networkworld.com/news/2008/041708-cisco-juniper-operating-systems.html

although you said you dont want to use web ui i think you should give it a go, its way better that the UI on cisco devices and you can do alot with it. i have used many ssg's in the past and very rerely needed the cli, where it did come handy was when i needed to bulk edit access rules than i would use notepad and paste in to cli.

Give it a go..

I do not know of any 1-by-1 transfer guide for Cisco and Juniper. It's a bit difficult as a block of IOS commands resemble to one single ScreenOS line. However, when thinking in command blocks, it should be easier then by many other devices to translate the command set to ScreenOS CLI.

Mysidia,
thorough explanation. I have to agree in all points stated, but in "cryptic". The question mark and the tab keystroke are your friends in CLI, providing you with step by step syntax info.

That said, it can be a pain indeed to use a line 200 chars long to change just a single VPN setting ...

I'm using CLI for automation (enabling of VPN policies on demand), and for initial VPN tunnel setup. Fine tuning or minimal changes are done by WebUI, as it is more intuitive and does all the work ... So the normal practise is to use WebUI in most cases, and CLI for the more advanced or structured jobs.

Mysidia:
Thanks for this comprehensive answer which covered almost everything.  
Why use CLI as opposed to Web Front-End? The choice for CLI is for automation purpose. We have about 18,000 sites at the moments running Cisco platforms and we do have some automation in place. I am not saying that we are planning to migrate all 18,000 Cisco sites to ScreenOS, but ideally, when we do introduce the ScreenOS platforms, we would expect them to be treated the same way. Obviously, the Web front-end will help but as designers, we want to focus on the CLI side so that we can generate standard configuration templates.
Management: anything to do with management, is currently done via interface loopback 10, which should be classified as untrust zone in this case.  So we use loopback 10 for tacacs source, ip tftp or ftp source, snmp source, etc. That does not seem to be impacted very much.
SNMP: this is a little problematic. Our current design for Cisco IOS, has two separate communities: a read-only community and a write community.  We also explicitly define the traps for the agent (CPE router) and these have to match with the traps enabled on the SNMP server otherwise, the trap is simply thrown away by the server. In our design, the agent is added to the host and we have a primary and secondary host. I have noticed with ScreenOS that you have to assign the host on the community basis.  Below is the Cisco IOS version:
------------------Cisco version below----
snmp-server community myReadOnlyCommunity RO 10
snmp-server community myWriteCommunity RW 10
snmp-server community SNMP RO 5
snmp-server community AnotherReadOnlyCommunity RO 5
snmp-server ifindex persist
snmp-server trap-source Loopback10
snmp-server enable traps snmp authentication linkdown linkup coldstart warmstart
snmp-server enable traps envmon
snmp-server enable traps hsrp
snmp-server enable traps config
no snmp-server enable traps tty
snmp-server host Primary_Host_IP version 2c Agent_Hostname
snmp-server host Secondary_Host_IP version 2c Agent_Hostname
--------------------------------------------------------------------------------------  
In ScreenOS, it is not possible to explicitly define the traps as we have done with Cisco. Also when I tried to add the host command, ScreenOS forced me to specify the community and when I tried to use the same host for another community, it would not let me do that. Our platform offers local resilience at every component level and we need to be able to build this into the design.  
The question, is, how to make all the communities (it does not matter how many), use the same host and repeat the same config for the backup host.  
I have managed to achieve the config below but that is only a single point of failure for each community and as such does not reflect our platform:
----------ScreenOS SNMP config----------
set interface loopback.10 manage snmp
set snmp contact MyContact
set snmp name MyName
set snmp location AgentLocation
set snmp port listen 161
set snmp port trap 162
set snmp auth-trap enable
set snmp community myReadOnlyCommunity Read-Only Trap-on traffic version v2c
set snmp community myWriteCommunity  Read-Write Trap-on traffic version v2c
set snmp host myReadOnlyCommunity 10.1.1.1/32 src-interface loopback.10 trap v2
set snmp host myWriteCommunity 10.1.2.1/32 src-interface loopback.10 trap v2
-----------------------------------------------------------------
As you can see here, the second IP (10.1.2.1/32) should be the backup but I am now using it for the second community (write) because when I tried to use the same IP as I used for the read-only community, I get the "Host 10.1.1.1 already exists" error.
As I go through our current Cisco design, I will come across various other bits with which I will need some help. So if it is OK with you, I will leave the question open for now.
I appreciate your contribution here. I must admit it is very good. If you have any other information that could help, I am very grateful.

Yes, unfortunately, you don't have explicit control of all the traps.
IOS allows you more explicit control of SNMP.

In ScreenOS, 'trap-on'  is used to designate a community used for sending traps

set snmp community myReadOnlyCommunity read-only  trap-on version any
set snmp auth-trap enable

When you specify a host for trap sending, the traps can only be sent with one community, the SNMP protocol doesn't let you send a trap packet with two communities on it.

For simple query access, you should be able to issue things like

set snmp host myOtherReadOnlyCommunity 10.1.1.1/24  trap v2

I do not have any problems defining two SNMP trap targets:

set snmp host myReadOnlyCommunity 10.1.1.1/32 src-interface loopback.10 trap v2
set snmp host myReadOnlyCommunity 10.1.2.1/32 src-interface loopback.10 trap v2

Qlemo:
You are right, if you only have one community. In our Cisco, we have two communities, one is read-only and the other is write.  If you only have one community then, there is no issue. However, if you have two, then ScreenOS does not allow you to repeat the same host, e.g. if you try the following command, it will fail:
set snmp host myWriteCommunity 10.1.1.1/32 src-interface loopback.10 trap v2
The reason of the failure would be because 10.1.1.1/32  was already used for the myReadOnlyCommunity community. If this works on your device, please let me know.
Many thanks.

Forgive my ignorance, but what are different snmp trap communities for?

Qlemo:
You have asked a very important question.  
I am only following a design whereby we have a read-only community and a write community and both communities are served by the same host as defined using the "snmp-server host" command in Cisco IOS.
Now that it looks like we cannot use the same host for more than one community, I have been thinking about a change of design to have a single community for read-write.  But before I do that, I need to discuss with my colleagues designers to understand why we have 2 different communities in the first place. I am sure there is a very good reason for the current design.
In any ways, it looks like we have to adopt a separate design for the SSG-20 box since we cannot use our Cisco IOS design for it.
When I find any further info on why we are using two different communities, I will get back to  you.
Thanks.

I think having multiple snmp communities for different actions is ok. However, for SNMP Traps one community (maybe even a different one) is enough. You can't do anything with the community in traps but use it for reporting.

What does Cisco use as an community with SNMP Traps? Does it send two traps, one for each assigned community?

Qlemo:
I don't think Cisco sends two traps. I think it sends only one trap per configured traps. My understanding is that the read-only community is for users and systems with read-only access and the read-write community, is for users and systems with read and write access.
I don't have the details of what or who those users and systems are. But I checked with a colleague today and he confirmed that both communities are required for the design.  
It is a shame that the host is tied to the community...  If it was mapped to the SNMP agent (router), then one could configure as many communities as needed and they will be using the same host.
I also sense that the SSG-20 box is mainly firewall and vpn box and may not be adequate for what we are trying to do.  But that is another story. For now, I will try my best to see how far I can take it.
Thanks.

Unfortunately, you can't do that bit, at least not according to Juniper...
http://kb.juniper.net/index?page=content&id=KB5087
I wonder if you set a community string by 'subnet',  the host would still be allowed to use it

set snmp community queryCommunity Read-Only Trap-off traffic version v2c
set snmp host queryCommunity 0.0.0.0/0 src-interface loopback.10 trap v2

Traps won't be generated for subnet community strings.
However,  the more-specific 'host community' string may override.

From a security POV, it may be best to avoid using read-write community strings;  SNMP is not a particularly secure protocol, in version 2, the community strings were sent in cleartext,  and it would be trivial for a sophisticated attacker to generate a  'snmp set'  packet with a spoofed source address,  if they had any manner of guessing the SNMP management station's address

(not hard, if they sniff the LAN and see traps or SNMP management traffic going across).

Mysidia:
Thanks for this.  I need to investiage a little bit more around the communities.
For both read-only and read & write communities, we use access list as addional security mechanism.  This is shown in the SNMP sample configuration above.  In the access lists, we permit the host IP addresses and deny anything else.  For example, if I use a new SNMP host without changing the access-lists, that host will never be permitted. In addition to that, we deploy another access-list on the customer LAN interface where we also apply a firewall configuration because the traffic from the customer network cannot be trusted.
So we have the security aspects of the SNMP covered. However, I will still investigate and see if there could be some vulnerability. I will let you  know.
Thanks.

As Mysidia told us, IP spoofing is no hard job. That would circumvent the access list.

Qlemo:
OK thanks. I will investiage this.

Thanks to Mysidia for taking time to help with this question and for the comprehensive answer.

My conclusion is that a lot of work is required to master the ScreenOS environment in order to get the best out of the SSG devices. Unfortunately, I don't have much time although I am not giving up on this.  

The way forward is that, I will be exploring the J-Series platform which runs on JunOS as I believe that may offer more flexibility than ScreenOS. Since the SSG-20 device is a firewall and VPN device, it may not be the best choice for what we are trying to do.

Thanks very much for Qlemo, for contributing to this question. I award the full point to Mysidia who provided the best answer.