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

[Martin T]

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
>