SRX

Hi all.  New to JunOS and experimenting on an SRX100 in prep for full layer 3 transition to JunOS/SRX in the coming months.  Having a bit of a problem with FBF, and I'm stumped.

I'm trying to force route an internal subnet across the tunnel using FBF.  Outbound traffic sourced locally and its' inbound response traffic flows fine.

Traffic initiated from the far side of the tunnel breaks though.  The traffic makes it in ok and is routed properly to the internal host, but the response traffic is not getting filtered into the routing instance that would send it to the tunnel.  Instead it's attempting to take the master 0.0.0.0/0 route and is failing because it came in the tunnel interface and is trying to leave the untrust interface.

I can't figure out how to fix this async route, or how to force traffic sourced from the far side into the custom FBF routing instance.

I've included relevant config bits below and attached a flowtrace showing what's happening.  st0.1 is bound to a route based VPN that works fine if all the traffic is static routed.

Any assistance/guidance/insight greatly appreciated, thanks!

The attached flow trace is for a session initated from 10.152.172.34 (on the far side of the tunnel) to the local host 10.252.252.100, tcp 445.

It shows a proper inbound route:

routed (x_dst_ip 10.252.252.100) from vpn (st0.1 in 0) to vlan.0, Next-hop: 10.252.252.100

But then the reverse route for that session hits the master default route and gets rejected:

route lookup: dest-ip 10.152.172.34 orig ifp st0.1 output_ifp fe-0/0/0.0 orig-zone 9 out-zone 7 vsd 0
Reject route in make_nsp_ready_no_resolve. zone mismatch

##Interfaces:

vlan {
    unit 0 {
        family inet {
            filter {
                input fbf-vpn;
            }
            address 10.252.252.1/24;
        }
    }
}

st0 {
    unit 1 {
        family inet;
    }
}

##Filter:

filter fbf-vpn {
    term from-10.252.252.0/24 {
        from {
            source-address {
                10.252.252.0/24;
            }
        }
        then {
            routing-instance fbf-st0.1;
        }
    }
    term allow {
        then accept;
    }
}

##Routing instance setup:

fbf-st0.1 {
    instance-type forwarding;
    routing-options {
        static {
            route 0.0.0.0/0 next-hop st0.1;
        }
    }
}

##Routing options:

interface-routes {
    rib-group inet common;
}
rib-groups {
    common {
        import-rib [ inet.0 fbf-st0.1.inet.0 ];
    }
}

Attachment(s)

flowtrace.txt   6 KB 1 version

In order to use FBF, the vlan.0 and st0.1 interfaces would need to be in separate routing-instances of their own. Perhaps you can have one interface in default instance and other be in separate instance. Here is a KB article example which is similar to what you are trying to do.

http://kb.juniper.net/KB15545

-Richard

rkim - thank you so much, I appreciate the response.

It took me a while to pick the interesting bits out of that article and relate it to my setup, they seem to be trying to accomplish a good deal more than the basic routing.

Anyway, I changed my forwarding instance to a virtual routing instance and attached it to st0.1 with a next-hop of st0.1 for 0.0.0.0/0 and the traffic flow is now working when traffic is initiated from the far side.

I guess I'm still having trouble fully understanding the underlying mechanics causing it to fail previously - is it because without binding st0.1 to a specific instance, it was part of the default instance, and when the session ingress and egress interfaces were both in the same instance the filter to push the response packets into the forwarding instance wasn't taking place... ?

Would the FBF setup I was using previously work properly if the alternate gateway or next-hop was external to the SRX rather than being a local virtual interface?

Thanks again for the help, much appreciated !

Best regards,

Hi Chris,

Are you able to post your configs in the end. I am in a similar situation as you. I have read through the KB above but my situation is not quite the same. I have external NAT devices that hold the actual public IP address for the second ISP.

One of my ISP is pppoe that terminates on the SRX210 which is fine. The secondary is another ISP terminating on another router that is performing that NAT.

My problem is similar to yours in that when a destination NAT from ISP2 router comes in, the return traffic is pushed out the pppoe interface on inet.0 routing-instance. Rather than the second ISP routing instance.

Apologies, I don't have that config in place or saved any longer.

The key for me however was to change from a forwarding instance (which only worked for locally initiated traffic; responses to remotely initiated traffic failed) to a full VR instance containing the egress interface.

How are you matching traffic to push into the ISP2 routing instance locally?

If you could post relevant parts of your config it might help in narrowing down the problem.

Cheers,

Thanks very much for clue, now it works.

I hade to upgrade junos to 10.1R2.8, then i made virtual router:

route-to-st0_50 {
    instance-type virtual-router;
    interface st0.50;
    routing-options {
        static {
            route 0.0.0.0/0 next-hop st0.50;
        }

andi made new zone for strange vpn, i put them st0.50 + new policy

i catch packets by filter:

term testo {
    from {
        source-address {
            10.255.0.11/32;
        }
        destination-address {
            88.0.109.77/32;
        }
    }
    then {
        count route-testo-to-88.0.109.77;
        routing-instance route-to-st0_50;
    }
}

btw

before i had 10.1R1.8 and after added st0.50 to virtual router the cluster hung up with core dump...