Routing
Reply
Visitor
KSluchanko
Posts: 4
Registered: ‎05-15-2012
0

Filter-based forwarding problem

[ Edited ]

Hello,

 

I have to use filter-based forwarding on SRX-100 due to logical topology of data routes. Network topology can be seen on the scheme.

 

Network topology

 

Required data flow between LAN and WAN shown with green arrows. Flows between LAN and DMZ2 and between DMZ1 and WAN are direct routing.

 

OK, I've configured SRX-100 this way:



interfaces {
    fe-0/0/3 {
        description LAN;
        unit 0 {
            family inet {
                filter {
                    input FW_ROUTING;
                }
                address 192.168.1.20/22;
            }
        }
    }
}

 

routing-options {
    interface-routes {
        rib-group inet RT_LAN;
    }
    static {
        route 0.0.0.0/0 next-hop D.E.F.241;
        route 192.168.10.0/24 next-hop 172.16.0.10;
        route 10.7.78.0/24 next-hop 172.16.0.14;

    }

 

// 192.168.10.0/24 and 10.7.78.0/24 are networks over site-to-site VPNs - does not matter now.

 

    rib-groups {

        RT_LAN {
            import-rib [ inet.0 RI_LAN.inet.0 ];
        }
    }
}

 

firewall {
    filter FW_ROUTING {
        term FW_ROUTING_TERM1 {
            from {
                source-address {
                    192.168.0.0/22;
                }
                destination-address {
                    192.168.0.0/22 except;
                }

 

// I cannot connect to SRX-100 itself via SSH without the 'except' condition shown above - I'm curious of it, but it is not a problem now.

 

            }
            then {
                routing-instance RI_LAN;
            }
        }
        term FW_ROUTING_TERM2 {
            then accept;
        }
    }
}

 

routing-instances {
    RI_LAN {
        instance-type forwarding;
        routing-options {
            static {
                route 0.0.0.0/0 next-hop 172.16.255.2;
            }
        }
    }
}

 

No luck. Traffic from LAN that is directed to WAN or DMZ1 does not reach ISA, though other things works fine and I can reach ISA itself from LAN, ISA can reach Internet hosts and Internet hosts can reach internal servers published on ISA. Well, let's try virtual router:

 

routing-instances {
    RI_LAN {
        instance-type virtual-router;
        interface fe-0/0/2.0;
        interface fe-0/0/3.0;
        routing-options {
            static {
                route 0.0.0.0/0 next-hop 172.16.255.2;
            }
        }
    }
}

 

Again no luck with FBF. What can be the problem?

 

Best regards,

Cyril

Trusted Contributor
acecanal
Posts: 149
Registered: ‎07-05-2011
0

Re: Filter-based forwarding problem

 

 Hi Cyril.

 

 About your ssh problem, on routers this is because the lo0 interface dont belong to the routing-instance RI_LAN. Your FBF configuration match the management traffic and forward this to that VR.

 

 About the rest, your configuration dont looks like right. It will be good if you could add your interface names.

 

 If you want to see some FBF example look at the following posts,

 

http://forums.juniper.net/t5/IOS-to-Junos-I2J-Tips-Contest/FW-traffic-load-balancing-with-session-pe...

http://forums.juniper.net/t5/IOS-to-Junos-I2J-Tips-Contest/Policy-Based-Routing-Filter-Based-Forward...

 

 

 Doubts :

 

 You add two interfaces under the VR RI_LAN. I think these are be the LAN and the ISA interfaces in DMZ1.

 Under the inet.0 table you should have the DMZ2 and WAN interfaces. In this table, you should have a static route to the LAN network pointing through the ISA interface in DMZ2, return traffic route. And a default route to the WAN.

  But under this configuration you dont need FBF, ISA will be always in middle of the path.

 

  If both belongs to the ISA, DMZ1, and DMZ2 then you have a routing loop, because the default route points to the ISA and traffic will never exit through the wan. In this case you need more FBF filters.

 

  If interfaces are the ISA DMZ2 and WAN interfaces, you have a similar case to the first one.

 

 

  If you need the FBF filter because you have more interfaces, dmz, or not all traffic should go through the ISA, or anything else, then need two VR. VR-DMZ1 with ISA DMZ1 interface. VR-DMZ2, with ISA DMZ2 interface. Will need four FBF filters.

 

   LAN and WAN under inet.0 table. Default route through WAN interface.

 

   LAN

      FBF, input traffic from LAN, match souce LAN traffic, then routing instance VR-DMZ1.

      Any other traffic route in inet.0 table, accept.

 

    VR-DMZ1.

       default route ISA DMZ1.

       FBF, input traffic from ISA then routing instance LAN or table inet.0

 

    VR-DMZ2.

       default route ISA DMZ2.

       FBF, input traffic from ISA then routing instance WAN or table inet.0

 

     WAN.

       default route to WAN interface.

       FBF, input traffic from WAN, match destination LAN traffic then routing instance VR-DMZ2.

       Any other traffic route in inet.0 table, accept.

 

   

  Other option using VR.

 

   LAN and DMZ1 in VR-LAN. Default route to ISA interface DMZ1.

   WAN and DMZ2 in VR-WAN. Default route to WAN. LAN network route to ISA DMZ2 interface.

 

   LAN

     No need FBF, will route traffic to ISA.      

 

   WAN.

     No need FBF, will route traffic.

 

   If you have more traffic than dont need to go through the ISA, then will have FBF as in the first option, to get this to other VR.

 

 

 

Br
Alex

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If you want to say thanks, the word is Kudos!!.

Thx.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

JNCIA-JUNOS, JNCIS-ENT, JNCIS-SP, JNCIP-SP.
CCNA, CCNP, Written CCIE.
Visitor
KSluchanko
Posts: 4
Registered: ‎05-15-2012
0

Re: Filter-based forwarding problem

[ Edited ]

Hi Alex,

 

Thank You for the explanation of the SSH problem - I was suspicious of something like that.

 

As for the lack of information - yes, You are right, I have forgot some things. First of all, interfaces in use are configured as follows:

 

interfaces {

    fe-0/0/0 {
        description WAN;
        unit 0 {
            family inet {
                address D.E.F.242/28;
            }
        }
    }
    fe-0/0/1 {
        description DMZ1;
        unit 0 {
            family inet {
                address A.B.C.1/24;
            }
        }
    }
    fe-0/0/2 {

        description DMZ2;
        unit 0 {
            family inet {
                address 172.16.255.1/24;
            }
        }
    }
    fe-0/0/3 {
        description LAN;
        unit 0 {
            family inet {
                filter {
                    input FW_ROUTING;
                }
                address 192.168.1.20/22;
            }
        }
    }
}

 

Second (and more important, I suppose) - I have missed the fact that ISA performs NAT. This way, I see no any possible routing loop. More of this - as I said in initial message, all but FBF works fine; it was not all the truth (again, I have had to include it in first message) - I also have had access to Internet with directly assigned proxy server in browser, pointing to ISA. I think it confirms that there are no actual routing loops with my configuration. This, in turn, shows us that we don't need any additional virtual routers for any purposes - do You agree? If no - please, point me to wrong conclusions.

 

And remember, I've said that I see no incoming traffic from LAN on ISA internal interface - except directly addressed to ISA one. Looks like FBF does absolutely nothing.

 

Best regards,

Cyril

Trusted Contributor
acecanal
Posts: 149
Registered: ‎07-05-2011
0

Re: Filter-based forwarding problem

 

  Of course your FBF do nothing, but you need at least one VR if want to allow traffic directly to the wan interface, redirect this to the isa interface, or only allow traffic through isa.

 

  If you use the fe-0/0/3 and fe-0/0/2 in the VR RI_LAN, LAN and ISA DMZ2, your FBF is not going to do nothing.You use a then routing-instance RI_LAN, but both interface are in the same VR. This way your FBF is doing nothing because put traffic in the same instance. You only need FBF and a then routing-instance if the incoming instance is other than the destination instance.

 

  You have to delete the fe-0/0/3 from the VR RI_LAN if want to use FBF. If not delete the FBF and will work as you expect.

  Im not sure but i think when the FBF accept traffic, this will not be routed in the same source table. Only if you put this in other table.

 

   What i talk about the routing loops was about the VR fe interfaces if these was the DMZ1 and DMZ2. As you clarify with your interface descriptions this is not the case.

 

   The ISA DMZ2 interface is in the inet.0 table, the default route is the d.e.f.242 address. ok.

 

   I suppose the ISA use its own address for the nat translations, so this is a directly connected route in the wan side. No need static routes on that side for return traffic.

 

 

 

 

 

Br
Alex

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If you want to say thanks, the word is Kudos!!.

Thx.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

JNCIA-JUNOS, JNCIS-ENT, JNCIS-SP, JNCIP-SP.
CCNA, CCNP, Written CCIE.
Visitor
KSluchanko
Posts: 4
Registered: ‎05-15-2012
0

Re: Filter-based forwarding problem

Alex,

 

OK, let's step aside. As I see, You are talking of virtual-router routing instance - right? However, it was a try after forwarding routing instance has failed to do what I need it to - and I still think that forwarding routing instance (that is not bound to interfaces, right?) is enough for my goal.

 

I understand the way forwarding routing instance works this way:

 

1. Packet from LAN, addressed to WAN, reaches fe-0/0/3.0;

2. Filter FW_ROUTING bound to interface fe-0/0/3.0 catches the packet and finds that it is the case for FW_ROUTING_TERM1 term;

3. Then FBF passes packet to RI_LAN routing instance (of forwarding type, as in first configuration example);

4. Routing instance forwards packet to 172.16.255.2 instead of default route D.E.F.241.

 

As I see from articles I have used as a starting point (these, for example: http://kb.juniper.net/InfoCenter/index?page=content&id=KB17223&actp=RSS&smlogin=truehttp://jsrx.juniperwiki.com/index.php?title=Filter_Based_Forwarding), no additional conditions on interfaces' membersip in routing instance have to be met.

 

Where I am wrong? Maybe (if it not take You to much time) You can point me to good in-depth documentation on FBF?

 

Best regards,

Cyril

Trusted Contributor
acecanal
Posts: 149
Registered: ‎07-05-2011
0

Re: Filter-based forwarding problem

 

 

  Hi Cyril.

 

  You are right.

 

   A forwarding instance type is only other forwarding table.

   A virtual router instance type, is like its name a virtual router, so have isolated interfaces from the other routing instances and tables.

 

  You could use what you prefer, depending on your security concerns, topology, etc.

 

  In your case, if you dont want to never allow traffic directly to the WAN, or from the WAN to LAN, will be better to configure Virtual router. You FBF will allow this traffic when needed.

 

  If you dont need to isolate lan from wan, then could use instance type forwarding.

 

  Your mistake was only using the VR, adding both LAN and DMZ2 to the VR, this is what i said you about your configuration was wrong.

 

  But your forwarding configuration looks like right for me. What make believe your ISA is not working in transparent mode.

 

  If you want to check if your isa works in transparent mode, disable the FBF filter, configure a VRF with LAN and DMZ2 interface, use default routing in that VR with next hop ISA DMZ2. Create other VR or use inet.0 table, for DMZ1 and WAN interfaces. Use default route with next hop WAN.

 This way your SRX will be configured as two SRX instances, connected through the ISA. If under configuration dont work, your problem is not the FBF, the problem is that the ISA is not transparent. This is why works when you configure this as proxy server in your browser.

 

 

 

  These are simple examples of FBF, there is more on the juniper web site. Documentation is not always good, because have few examples. These are two examples using vr and forwarding instances.

 

http://www.juniper.net/techpubs/en_US/junos11.3/topics/example/filter-based-forwarding-with-firewall...

 

http://www.juniper.net/techpubs/en_US/junos12.1/topics/task/configuration/ipsec-filter-based-forward...

Br
Alex

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If you want to say thanks, the word is Kudos!!.

Thx.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

JNCIA-JUNOS, JNCIS-ENT, JNCIS-SP, JNCIP-SP.
CCNA, CCNP, Written CCIE.
Visitor
KSluchanko
Posts: 4
Registered: ‎05-15-2012
0

Re: Filter-based forwarding problem

Hi Alex,

 

Thank You, now I see the problem with virtual-router instance.

 

As for problem with forwarding instance, Your conclusion about ISA is not correct. It take it's place for years and works just as planned. I once again take Your attention to the fact that there is no incoming traffic directed from LAN to WAN on ISA's internal interface. This 'no' means just 'no'. No any single packet. These packets enter SRX's LAN interface - but does not leave SRX's DMZ2 interface. ISA works fine (at this moment too - I've dismounted SRX and placed back Cisco router configured with the same logic) - but with SRX it has nothing to work with. 

 

Best regards,

Cyril

Trusted Contributor
acecanal
Posts: 149
Registered: ‎07-05-2011
0

Re: Filter-based forwarding problem

[ Edited ]

 

Buff, i did some tests that work, and i see i miss something from you configuration....

 

destination-address {
                    192.168.0.0/22 except;
                }

 

You have to configure except this way :

 

                destination-address {
                    0.0.0.0/0;

                    192.168.0.0/22 except;
 
                }

 

 

  You cant leave except alone, if you wants to means everything but except this network you have to configure this way.

If you only configure a except, then will not match everything else. You have to configure the 0.0.0.0 or a 192.168.0.0/16, or somethiing like will include the except. This means, except this small range from the other range.

 

 

 This configuration works, if you ping from RI1 loopback address 10.1.0.0/16 to RI3 loopback address in 10.3.0.0/16 space, icmp will be routed through forwarding ISA and interfaces em5 and em4, except, for destination address 10.3.2.0/24 that will be routed in RI2 forwarding table directly to interface em3.

 

 RI1, em7 ---- em6, RI2 , em3 --- em2, RI3
                             |       |
                     em5 |       | em4
                             |       |
                              -------

                               ISA


interfaces {


    em2 {
        description R3-linkto-R2;
        unit 0 {
            family inet {
                address 34.34.34.4/24;
            }
        }
    }
    em3 {
        description R2-linkto-R3;
        unit 0 {
            family inet {
                address 34.34.34.3/24;
            }
        }
    }
    em4 {
        description R2-DMZ1;
        unit 0 {
            family inet {
                address 23.23.23.3/24;
            }
        }
    }
    em5 {
        description R2-DMZ2;
        unit 0 {
            family inet {
                address 23.23.23.2/24;
            }
        }
    }
    em6 {
        description R2-linkto-R1;
        unit 0 {
            family inet {
                filter {
                    input REDIR;
                }
                address 12.12.12.2/24;
            }
            family inet6;
        }
    }
    em7 {
        description R1-linkto-R2;
        unit 0 {
            family inet {
                address 12.12.12.1/24;
            }
            family inet6;
        }
    }

 

    lo0 {
        unit 1 {
            family inet {
                address 10.1.1.1/24;
                address 10.1.2.1/24;
                address 10.1.3.1/24;
                address 10.1.4.1/24;
            }
        }
        unit 3 {
            family inet {
                address 10.3.4.3/24;
                address 10.3.1.3/24;
                address 10.3.3.3/24;
                address 10.3.2.3/24;
            }
        }

}


routing-options {
    rib-groups {
        RT {
            import-rib [ RI2.inet.0 ISA.inet.0 ];
        }
    }
}


firewall {
    filter REDIR {
        term Net10 {
            from {
                source-address {
                    10.1.0.0/16;
                }
                destination-address {
                    0.0.0.0/0;
                    10.3.2.0/24 except;
                }
            }
            then {
                routing-instance ISA;
            }
        }
        term accept {
            then accept;
        }
    }
}

 

routing-instances {

    ISA {
        instance-type forwarding;
        routing-options {
            static {
                route 10.3.0.0/16 next-hop 23.23.23.3;
            }
        }
    }

    RI1 {
        instance-type virtual-router;
        interface em7.0;
        interface lo0.1;
        routing-options {
            static {
                route 10.3.0.0/16 next-hop 12.12.12.2;
            }

        }
    }

    RI2 {
        instance-type virtual-router;
        interface em3.0;
        interface em4.0;
        interface em5.0;
        interface em6.0;
        interface lo0.2;
        routing-options {
            interface-routes {
                rib-group inet RT;
            }
            static {
                route 10.1.0.0/16 next-hop 12.12.12.1;
                route 10.3.0.0/16 next-hop 34.34.34.4;
            }

        }
    }
    RI3 {
        instance-type virtual-router;
        interface em2.0;
        interface lo0.3;
        routing-options {
            static {
                route 10.1.0.0/16 next-hop 34.34.34.3;
            }

        }
    }
}

 

 


admin@MX> monitor traffic interface em4
verbose output suppressed, use <detail> or <extensive> for full protocol decode
Address resolution is ON. Use <no-resolve> to avoid any reverse lookup delay.
Address resolution timeout is 4s.
Listening on em4, capture size 96 bytes

Reverse lookup for 10.3.1.3 failed (check DNS reachability).
Other reverse lookup failures will not be reported.
Use <no-resolve> to avoid reverse lookups on IP addresses.

17:13:30.096299  In IP truncated-ip - 24 bytes missing! 10.1.1.1 > 10.3.1.3: ICMP echo request, id 45111, seq 0, length 64
17:13:31.099595  In IP truncated-ip - 24 bytes missing! 10.1.1.1 > 10.3.1.3: ICMP echo request, id 45111, seq 1, length 64
17:13:36.202508  In IP truncated-ip - 24 bytes missing! 10.1.1.1 > 10.3.3.3: ICMP echo request, id 45623, seq 0, length 64

Br
Alex

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If you want to say thanks, the word is Kudos!!.

Thx.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

JNCIA-JUNOS, JNCIS-ENT, JNCIS-SP, JNCIP-SP.
CCNA, CCNP, Written CCIE.
Copyright© 1999-2013 Juniper Networks, Inc. All rights reserved.