[j-nsp] SRX ignores "then routing-instance" firewall action

[Martin T]

As a workaround, I configured a static route to inet.0 table which
will route traffic addressed to 104.236.80.115/32 over reth2.28
interface. Probably this option based on source-NAT and virtual-router
routing-instance would work as well:
kb.juniper.net/InfoCenter/index?page=content&id=KB21363

However, I'm still puzzled why is my "fallback-to-nat" filter ignored?
Or I just don't understand how exactly the packet flow for return
traffic in SRX works..


Martin

On 4/10/15, Martin T <m4rtntns at gmail.com> wrote:
> Per,
>
> thank you for your reply! Actually the outbound IFL in case of
> DIA.inet.0 is reth2.28, i.e. the same interface and thus the same
> security zone where the original packet came in from. Without input
> filter on reth1.901 the response packet would use inet.0 routing table
> and thus the reth2.128 IFL. With input filter I try to force it to use
> DIA.inet.0 table and thus interface reth2.28.
>
>
> Martin
>
> On 4/10/15, Per Westerlund <p1 at westerlund.se> wrote:
>> What are you trying to accomplish with the input filter on reth1.901?
>>
>> The response packet is actually routed by DIA.inet.0, but then the flow
>> logic kicks in and notices that the new outbound IFL is in another
>> security
>> zone than the initial packet was received from. This is not allowed, so
>> the
>> packet is dropped.
>>
>> /Per
>>
>> PS: sorry to be terse, only have iPad right now.
>>
>>> 9 apr 2015 kl. 15:16 skrev Martin T <m4rtntns at gmail.com>:
>>>
>>> Hi,
>>>
>>> I have a Juniper SRX firewall cluster with interface reth2.28 facing
>>> primary Internet connection, interface reth2.128 facing secondary
>>> Internet connection and reth1.901 is facing LAN. Incoming traffic uses
>>> reth2.28 interface. There is a static NAT configuration applied which
>>> will change the destination IP address to 10.70.50.201 if destination
>>> port is 515:
>>>
>>> static {
>>>    rule-set nat {
>>>        from interface reth2.28;
>>>        rule nat {
>>>            match {
>>>                destination-address 192.0.2.1/32
>>>                destination-port 515;
>>>            }
>>>            then {
>>>                static-nat {
>>>                    prefix {
>>>                        10.70.50.201/32;
>>>                        mapped-port 515;
>>>                    }
>>>                }
>>>            }
>>>        }
>>>    }
>>> }
>>>
>>> Now host with IP address 10.70.50.201 will send a reply(for example
>>> TCP SYN+ACK) and SRX receives it on reth1.901 interface. I have an
>>> input filter configured to reth1.901 which should force this traffic
>>> to use routing instance DIA:
>>>
>>> firewall {
>>>    filter fallback-to-nat {
>>>        term nat {
>>>            from {
>>>                destination-address {
>>>                    104.236.80.115/32;
>>>                }
>>>                protocol tcp;
>>>                source-port 515;
>>>            }
>>>            then {
>>>                routing-instance DIA;
>>>            }
>>>        }
>>>
>>> However, according to flow traceoptions the router still uses inet.0
>>> RIB for routing decisions and not the DIA.inet.0 RIB:
>>>
>>> Apr  9 13:29:18 13:29:21.392241:CID-1:RT:
>>> reth1.901:10.70.50.201/515->104.236.80.115/56022, tcp, flag 12 syn ack
>>> Apr  9 13:29:18 13:29:21.392241:CID-1:RT: find flow: table 0x5115c900,
>>> hash 9435(0xffff), sa 10.70.50.201, da 104.236.80.115, sp 515, dp
>>> 56022, proto 6, tok 9
>>> Apr  9 13:29:18 13:29:21.392241:CID-1:RT:  flow got session.
>>> Apr  9 13:29:18 13:29:21.392241:CID-1:RT:  flow session id 132067
>>> Apr  9 13:29:18 13:29:21.392241:CID-1:RT:  route lookup failed:
>>> dest-ip 104.236.80.115 orig ifp reth2.28 output_ifp reth2.128 fto
>>> 0x48bf7b50 orig-zone 7 out-zone 8 vsd 2
>>> Apr  9 13:29:18 13:29:21.392241:CID-1:RT:  packet dropped,   pak
>>> dropped since re-route failed
>>>
>>>
>>> In case of DIA.inet.0 the interface for 104.236.80.115 would be
>>> reth2.28.
>>>
>>> Any ideas what might cause such behavior?
>>>
>>>
>>>
>>> thanks,
>>> Martin
>>> _______________________________________________
>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>