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

Per Westerlund p1 at westerlund.se
Thu Apr 9 18:21:45 EDT 2015


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


More information about the juniper-nsp mailing list