Juniper is also big on naming things, in JUNOS everything has a name, the Filter Lists have names, the terms in the Filter Lists have names, and even the address’s you are matching on have names. This is a big concept in JUNOS because it allows you to write snippets of Filter-Lists and use them for many different Filter Lists. JUNOS also supports grouping Filter Lists and applying an entire group of filter to an interface. If you apply Filter groups to a JUNOS interface they individual Filter Lists are evaluated in order sequentially.

To facilitate out discussion of Filter-Lists let’s take a look at a standard anti-spoofing access list which would be applied to most edge routers. First let’s talk about what a vanilla anti-spoofing ACL should contain! A standard ACL at a minimum should block all RFC-1918 address space from the internet, it should also block undesirable types of ICMP traffic, and depending on the setup should block packets with illegal combinations of TCP flags set, for example packets with the SYN-FIN flag set at the same time or FIN-URG-PSH or URG-ACK-PSH-RST-SYN-FIN at the same time. All of these combinations of TCP flags are illegal and should never be together as part of a legitimate packet. So without further ado lets talk about Filter Lists.
Filter Lists are defined under the Firewall section of the JUNOS configuration. Prefix Lists which are groups of networks, IP address ranges, or single hosts such as 1.1.1.1/32 are defined in these lists. These lists can later be used in as many Filter Lists as you define.

Below I will show you the actual Filter Lists as it looks in the configuration and some of the commands to create the list. For brevity I have opted to only show some of the commands used in creating the list as they are basically repetitive. The important thing to remember is that like all Access-Lists the terms in the Filter List are evaluated from top to bottom so it is important that the last term be an allow all statement otherwise the anti-spoofing filter will block all communication even legitimate communication.

[edit]
john#set policy-options prefix-list rfc1918-prefix-list 192.168.0.0/16

[edit]
john#set policy-options prefix-list rfc1918-prefix-list 172.16.0.0/12

[edit]
john#set policy-options prefix-list rfc1918-prefix-list 10.0.0.0/8

[edit]
john# edit firewall

[edit firewall]
john# edit filter anti-spoofing

[edit firewall filter anti-spoofing]
john# edit term block-rfc1918

[edit firewall filter anti-spoofing term block-rfc1918]
john# set from source-prefix-list rfc1918-prefix-list

[edit firewall filter anti-spoofing term block-rfc1918]
john# set then log discard

[edit]
john# show policy-options

prefix-list rfc1918-prefix-list {
    10.0.0.0/8;
    172.16.0.0/12;
    192.168.0.0/16;
}

[edit firewall]
john# show

filter anti-spoofing {
    term block-rfc1918 {
        from {
            source-prefix-list {
                rfc1918-prefix-list; ## 'rfc1918-prefix-list' is not defined
            }
        }
        then {
            log;
            discard;
        }
    }
    term block-fin-urg-psh {
        from {
            protocol tcp;
            tcp-flags fin,psh,urg;
        }
        then {
            log;
            discard;
        }
    }
    term block-syn-fin {
        from {
            protocol tcp;
            tcp-flags fin,syn;
        }
        then {
            log;
            discard;
        }
    }
    term block-urg-ack-syn-fin-rst-psh {
        from {
            protocol tcp;
            tcp-flags urg,ack,psh,rst,fin,syn;
        }
        then {
            log;
            discard;
        }
    }
    term block-icmp {
        from {
            protocol icmp;
            icmp-type-except echo-reply,unreachable,source-quench,time-exceeded;
        }
        then {
            log;
            discard;
        }
    }
    term accept-all {
        then accept;
    }
}

Remember to apply the Filter-List to the interface with the following command:

[edit]
john#set interfaces fe-0/0/0.0 family inet filter input anti-spoofing

Here is a related Article on ACL’s

Until Next time

Now I thought this would be an easy job, configure the Juniper to connect to our checkpoint r55 box the same as the pix had done before! Man was I surprised to realize that the Juniper did not like the r55. The r55 sends proxy id’s through the tunnel for every device connecting. Now the interesting this is that the r55 uses the supernet for the address requesting access through the vpn. On the cisco pix and asa devices, this does not much matter. So for instance if you hav 10.0.0.0/24, 172.16.2.0/23 and 192.168.0.0/24 on 1 side all trying to access a remote site through the Juniper, the checkpoint send the juniper proxy id’s for each of those networks. Now like I said the cisco determines what traffic matches the tunnel with access-lists and doesn’t much care what the proxy ID says. The juniper on the other hand does! If it sees a proxy id for say a host that is not part of the tunnel, it will tear down the tunnel!!!!  

You can imagine this is a big problem. So what has to be done is that you have to go to autoike and add a gateway for each network that is on the other side. Make sure you also go to advanced and select the checkbox for proxy ID. Once this box is checked enter the information for source and destination. the best way to do this is to check the event logs on the junipers and put in exactly what it says the received proxy ID is.

Once you do this the tunnel will come up. the only other issue is to go to the network –> routing __> destination tab and add a route for each network that you need to go to the tunnel interface.

Thats it, 6 hours of work and the answer was very simple once you figure it out.