Screen OS

last person joined: 8 months ago 

This is a legacy community with limited Juniper monitoring.
  • 1.  Inbound WAN Security

    Posted 03-11-2013 13:25

    Hello all. I have recently finished wading through the config of a Netscreen 5GT. It has been interesting. I now have a sucessful VPN tunnel to my HUB Cisco 1841, and am almost ready to deploy. However, I have one fundamental question. On most of my Cisco and Vyatta routers, I implement an inbound WAN ACL to prevent RFC1918 traffic and other traffic that should, under no circumstances, be getting in my network. Example below: (This is just a snip of the full ACL)

     

     deny   ip 10.0.0.0 0.255.255.255 any
     deny   ip 172.16.0.0 0.15.255.255 any
     deny   ip 192.168.0.0 0.0.255.255 any
     deny   ip 127.0.0.0 0.255.255.255 any
     deny   ip 169.254.0.0 0.0.0.255 any

     permit udp host <remote> eq isakmp host <local> eq isakmp
     permit esp host <remote> host <local>

     

    What is the best way to do this in screenOS? Should I be utilizing both untrust-vr and trust-vr? Thanks for the insights!



  • 2.  RE: Inbound WAN Security
    Best Answer

    Posted 03-11-2013 18:39

    Hi,

     

    You can look at zone level policies to achieve this.
    First find out the zone that you want to protect (trust zone) and then the zone from where you want to block traffic (untrust zone)
    Set up a policy from untrust to trust zone add you can add the source ip subnets, destination subnets and services.
    If no policy exists between 2 zones then the default action is to block.

    Hope this helps.

     

    Thanks.
    Hardeep



  • 3.  RE: Inbound WAN Security

    Posted 03-12-2013 12:54

     

    Exactly the information I am looking for. Many thanks to you!



  • 4.  RE: Inbound WAN Security

    Posted 03-12-2013 14:04

    I typically stick to a "allow what's necessary, deny all else" model.

     

    By allowing what's necessary, for example, you can allow source addresses from your known networks only in the outbound direction.  All else, including the RFC1918 space, will be denied.

     

    For incoming, a packet would obviously have to be spoofed (or you have some seriously whacked-out routing from your ISP!) in order for packets to come in with sources in the RFC1918 space -- this is a good time to look at the IP spoofing screen option.