SRX

Greetings to the community!

 

I've just managed to migrate a ScreenOS based NS-208 firewall config into Junos format and loaded it on SRX240. Apart from standard issues with static/destination/source NAT everything seems to function alright, except for one thing.

 

Namely the security policy has number of rules that use domain name as a destination, instead of IP address. This means that the SRX has to perform a name lookup for these rules, which fails. The DNS lookup belongs to the system services, originating from the security gateway, like NTP, syslog and others. I didn't test other system services yet, just DNS which doesn't work. The name servers have been specified (2 of them), domain name configured etc.

 

I'm starting to believe I know where the issue lies but would like to have a second opinion from someone on this forum, and possible hint or  a resolution.

 

The out-of-band management interface fxp0 isn't connected to any networks, simply because NS-208 didn't have it and the customer was keen on keeping the same interface count as on Netscreen and unchanged IP addressing and network environment. Do you believe the outbound DNS lookup would be sent by default from 'management' interface fxp0?

 

Also, the firewall uses a default virtual router trust-vr, the one that got converted during migration, and all the routes/static NATs etc belong to that VR routing-instance. The redundant chassis cluster has been configured and functions as expected. The Junos version loaded is 10.0r3.1.

 

What am I doing wrong? There's almost nothing in the documentation that points to the fix, the only thing I found was that the outbound traffic for IP services like DNS, NTP etc could be "forced" by a specific Junos command, although I'm not sure it would work.

 

Thanks for any guidance and commentary, in advance.

GOING OUT ON A LIMB HERE...  JUST TYRING TO GET INTEGRATED INTO THE COMMUNITY

 

I suspect... 

 

DNS-Query functions against policy are probably handled by the interface in the zone with which the address book entry exists...  So... 

 

This would obviously point to host-inbound-traffic system-service dns under that zone right?  BUT...  You mentioned something that is exactly similar to what I saw with these aforementioned services on interfaces that are a part of a VR. 

 

You can not terminate traffic TO the srx when it's in a virtual router instance. 

 

NOW…  I don’t know if your interfaces live in the virtual router instance or if you are using a “filter input” under your family inet of the interface but…  Let’s assume the latter…

 

You would need to put up a firewall fiter with term 1 statements to accept these destination addresses into inet.0, and another term 2 for sending the rest of your traffic to the routing-instance.  Just Vice Versa your firewall filter if your interfaces actually live in the virtual router.  LIKE, your term 1 would actually be then routing-instance inet.0 and term 2 then accept.  

I.E.

 

firewall {
    filter trust-vr-filter {
        term 1 {
            from {
                destination-address {  <- this would be the IP of the interface
                    10.0.99.1/32;
                }
            }
            then accept;
        }
        term 2 {
            then {
                routing-instance trust-vr;
            }
        }
    }
}
routing-instances {
    trust-vr {
        instance-type virtual-router;
        routing-options {
            static {
                route 0.0.0.0/0 {
                    next-hop X.X.X.X;
                }
            }
        }
    }
}

Hi colemtb, thanks for your elaborate reply, really apreciate the effort and time you put into it.

 

I believe however, thet the issue isn't so much related to the traffic directed towards the SRX but generated by it towards the outside (Internet).

 

Most of the stuff works well, the only issue I have is the name lookup performed by the firewall itself towards the DNS servers located on the Internet, isn't working.

 

Not sure if the fxp0 out-of-band mgmt interface should be connected to the network (as I believe this is the interface DNS lookup queries are being generated from SRX) or not.

 

Has anyone else had the same issue? I expected many others would have hit the same problem after migrating from Netscree/SSG ScereenOS platforms to an SRX gateway?

 

Is there something obvious I missed, do you think?

 

thanks!

Just curious, can you ping the DNS servers?

 

Does the "show route DNSSERVERIP" return your egress interface?

 

Can a PC on the internet ping / ssh / https / any host-inbound-traffic system-service to your firewall?

 

Is your egress interface in a routing instance? 

 

Thanks.

Hi colemtb,

to answer th equestions:

 

Just curious, can you ping the DNS servers?

- yes I can ping both DNS servers IP address

 

Does the "show route DNSSERVERIP" return your egress interface?

- yes it does

 

Can a PC on the internet ping / ssh / https / any host-inbound-traffic system-service to your firewall?

- shouldn't those services be disabled by default on Untrust interface, for security reason being one?

BTW, I also tried using internal DNS servers (Trust zone) and the behaviour and issue are the same.

 

Is your egress interface in a routing instance? 

- yes Untrust-VR

 

thanks,

b

 

Sorry, meant to say Trust-VR not Untrust VR:

 

Is your egress interface in a routing instance? 

- yes Trust-VR

Can a PC on the internet ping / ssh / https / any host-inbound-traffic system-service to your firewall?

- shouldn't those services be disabled by default on Untrust interface, for security reason being one?

BTW, I also tried using internal DNS servers (Trust zone) and the behaviour and issue are the same.

Depends really, I usually have IKE, SSH, and PING allowed on mine for IPSEC, Management, and troublehsooting...  I know ping is a no no and not really desirable, however; I don't really have too much context sensative data.

Just for troubleshooting if your interested, and so I can leave you alone 😉 , I would enable SSH and try to remotely connect to the box...  Curiosity on my part at this point really. 

 

 Thanks, GL.

Hi babola

 

Can you try to disable DNS ALG

set security alg dns disable

Thanks guys (sshssh and colemtb) that's exactly what the J-Tac support person suggested today. It's Sunday here, so wil try this first thing tomorrow morning when on site.

 

He also suggested to enable 'host inbound traffic' on the Untrust interface, as a possibility but he wasn't sure.

 

Will post an update if this fixes it or not.

 

@Colemtb, sorry my friend but the firewalls are sitting in pre-prod environment with simulated Internet, so no connection option to it from the outside.

So I hate to beat a dead-horse but...  Actually no I don't.  😉

 

I understand there are certain services that always use inet.0 for their routing table.   I.E. syslog always sent through the data plane on inet.0 unless otherwise specificed with a "source-address". 

 

Now, I don't see this source-address option under "system name-server ?" stanza so I don't know if this is one of "these services" / road-map / whatever but...  If you had a VR instance with all your interfaces; in the case of syslog you would need to...

 

NOTE: Incase I lose you before the end I would probably ditch the vr and test.

 

after specifying the syslog server with a destination of I.E. 10.2.1.1

 

Setup syslogging from....

 

set system syslog source-address 10.1.1.1

 

Create a Loopback interface with the address we sourced the syslog from.  I.E.  10.1.1.1

 

interfaces {
    lo0 {
        unit 0 {
            family inet {
                filter {
                    input trust-vr-filter;
                }
                address 10.1.1.1/32;
            }
        }

 

IF and only IF you had interfaces outside your VR, which you don't, make the VR aware with rib-group combos.

 

routing-options {
    interface-routes { 
        rib-group inet trust-vr;
    }

 

   rib-groups {
           trust-vr {
               import-rib [ inet.0 trust-vr.inet.0 ];
           }
       }

 

CALL your filter specified under the interface

 

firewall {
    filter trust-vr-filter {
        term 1 {
            then {
                routing-instance trust-vr;
            }
        }
    }
}

 

Setup your routing instance

 

routing-instances {
    trust-vr {
        instance-type virtual-router;
        routing-options {
            static {
                route 0.0.0.0 next-hop X.X.X.X;
            }
        }
    }
}

 

Setup your static route with a next-table entry

 

set routing-options static route 10.2.1.1/32 next-table trust-vr.inet.0

 

OR, much thanks to "instance-import" available to the SRX you can accomplish the same thing by...

 

specify the syslog server with a destination of I.E. 10.2.1.1 having a souce address of a loopback lo.0.

 

set system syslog source-address 10.1.1.1

 

Create a Loopback interface  I.E. 10.1.1.1

 

interfaces {
    lo0 {
        unit 0 {
            family inet {
                filter {
                    input trust-vr-filter;
                }
                address 10.1.1.1/32;
            }
        }

 

Setup your static route with a next-table entry

 

set routing-options static route 10.2.1.1/32 next-table trust-vr.inet.0

 

Setup VR

 

set routing-instance trust-vr instance-type virtual-router

 

set routing-instance trust-vr routing-options instance-import [ trust-vr-imp ]

 

set policy-options policy-statement trust-vr-imp term allow from instance master route-filter 10.1.1.1/32 exact

 

set policy-options policy-statement trust-vr-imp term allow then accept

 

set policy-options policy-statement trust-vr-imp term allow from instance master

 

set policy-options policy-statement trust-vr-imp term allow then reject

 

NOTE: be careful or you could import ALL ROUTES!

The suggested fixes by J-Tac didn't yield the expected results.

 

Another suggestion was to use a loopback interface for this, so will try this next.

 

Colemtb...I'll give your suggestions a though, thanks mate, let us try the next suggestion from J-Tac first.

 

 

The issue has now been fixed.

 

Basically, I removed the Reth interfaces from the Trust-VR routing instance (remnant from an original Netscreen config), as well as moved all static routes from Trust-VR to the default routing instance inet.0.

 

The lesson I learned here is not to trust the ScreeOS to Junos migration tool too much, I guess.

 

Thanks all!

I actually got the same issue as or similar.

 

The DNS we want to use is in the trust-vr (not the default VR).

Right now the first issue is getting the route into the trust-vr as the default vr already routes to the dns servers using the trust-vr table.

 

As you suggested I have also considered moving it all back to the default vr, but I would actually like to try to nail this one.

 

I managed to solve an issue where the DNS server was external and there was default vr and an untrust-vr defined but using the import policy for the untrust-vr matching the interface of the srx in the default vr.

 

The current situation there are several interfaces in the default.

A guest zone.

The fxp interaces and a lo0 interface i defined.

 

# show routing-options

static {

    route 0.0.0.0/0 next-table untrust-vr.inet.0;

    route 10.23.0.0/16 next-table trust-vr.inet.0;

# show routing-instances

trust-vr {

    instance-type virtual-router;

    interface reth1.2;

    interface reth1.3;

    interface reth1.4;

    interface reth1.6;

    interface reth1.7;

    interface reth1.16;

    interface reth1.255;

    interface reth2.2572;

    interface reth2.2573;

    interface reth2.2574;

    interface reth2.2575;

    interface reth3.0;

    interface reth4.30;

    routing-options {

        static {

            route 10.32.0.0/16 next-hop 10.32.7.1;

            route 10.33.0.0/16 next-hop 10.33.7.1;

            route 10.34.0.0/16 next-hop 10.34.7.1;

            route 10.35.0.0/16 next-hop 10.35.7.1;

            route 0.0.0.0/0 {

                next-table untrust-vr.inet.0;

                preference 20;

            }

            route 10.0.0.0/8 next-hop [ 10.24.255.254 10.24.254.254 ];

            route 192.168.3.0/24 next-hop 10.24.255.254;

            route 10.213.5.34/32 next-hop 10.34.7.1;

        }

        instance-import imp-lo0;

        auto-export {

            disable;

        }

    }

    protocols {

        pim {

            rp {

                static {

                    address 10.24.239.254;

                }

            }

            interface reth3.0;

            interface reth4.30;

        }

    }

}

# run show route

 

inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

 

0.0.0.0/0          *[Static/5] 06:06:36

                      to table untrust-vr.inet.0

10.23.0.0/16       *[Static/5] 06:06:36

                      to table trust-vr.inet.0

10.24.0.3/32       *[Direct/0] 06:06:36

                    > via lo0.0

10.24.250.0/24     *[Direct/0] 06:06:36

                    > via fxp0.0

10.24.250.3/32     *[Local/0] 06:06:36

                      Local via fxp0.0

172.16.64.0/24     *[Direct/0] 06:00:21

                    > via reth1.64

172.16.64.1/32     *[Local/0] 06:06:36

                      Local via reth1.64

224.0.0.22/32      *[IGMP/0] 06:06:35

                      MultiRecv

 

trust-vr.inet.0: 44 destinations, 45 routes (44 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

 

0.0.0.0/0          *[Static/20] 06:06:36

                      to table untrust-vr.inet.0

10.0.0.0/8         *[Static/5] 06:00:21

                      to 10.24.254.254 via reth3.0

                    > to 10.24.255.254 via reth1.255

10.24.254.0/24     *[Direct/0] 05:57:35

                    > via reth3.0

10.24.254.4/32     *[Local/0] 06:06:35

                      Local via reth3.0

10.24.255.0/24     *[Direct/0] 06:00:21

                    > via reth1.255

10.24.255.3/32     *[Local/0] 06:06:35

                      Local via reth1.255

10.32.0.0/16       *[Static/5] 06:04:02

                    > to 10.32.7.1 via reth2.2572

10.32.7.0/24       *[Direct/0] 06:04:02

                    > via reth2.2572

10.32.7.5/32       *[Local/0] 06:06:35

                      Local via reth2.2572

10.32.7.22/32      *[Static/1] 06:06:32

                      Discard

10.32.7.23/32      *[Static/1] 06:06:32

                      Discard

10.32.7.24/32      *[Static/1] 06:06:32

                      Discard

10.32.7.100/32     *[Static/1] 06:06:32

                      Discard

10.32.7.121/32     *[Static/1] 06:06:32

                      Discard

10.33.0.0/16       *[Static/5] 06:04:02

                    > to 10.33.7.1 via reth2.2573

10.33.7.0/24       *[Direct/0] 06:04:02

                    > via reth2.2573

10.33.7.5/32       *[Local/0] 06:06:35

                      Local via reth2.2573

10.33.7.100/31     *[Static/1] 06:06:32

                      Discard

10.33.7.121/32     *[Static/1] 06:06:32

                      Discard

10.34.0.0/16       *[Static/5] 06:04:02

                    > to 10.34.7.1 via reth2.2574

10.34.7.0/24       *[Direct/0] 06:04:02

                    > via reth2.2574

10.34.7.5/32       *[Local/0] 06:06:35

                      Local via reth2.2574

10.34.7.254/32     *[Static/1] 06:06:32

                      Discard

10.35.0.0/16       *[Static/5] 06:04:02

                    > to 10.35.7.1 via reth2.2575

10.35.7.0/24       *[Direct/0] 06:04:02

                    > via reth2.2575

10.35.7.5/32       *[Local/0] 06:06:35

                      Local via reth2.2575

10.213.5.34/32     *[Static/5] 06:04:02

                    > to 10.34.7.1 via reth2.2574

172.16.1.0/24      *[Direct/0] 06:00:21

                    > via reth1.16

172.16.1.1/32      *[Local/0] 06:06:35

                      Local via reth1.16

172.16.2.0/29      *[Direct/0] 06:00:21

                    > via reth1.2

172.16.2.1/32      *[Local/0] 06:06:35

                      Local via reth1.2

172.16.2.8/29      *[Direct/0] 06:00:21

                    > via reth1.3

172.16.2.9/32      *[Local/0] 06:06:35

                      Local via reth1.3

172.16.2.16/29     *[Direct/0] 06:00:21

                    > via reth1.4

172.16.2.17/32     *[Local/0] 06:06:35

                      Local via reth1.4

172.16.2.32/27     *[Direct/0] 06:00:21

                    > via reth1.6

172.16.2.33/32     *[Local/0] 06:06:35

                      Local via reth1.6

172.16.2.64/29     *[Direct/0] 06:00:21

                    > via reth1.7

172.16.2.65/32     *[Local/0] 06:06:35

                      Local via reth1.7

192.168.3.0/24     *[Direct/0] 06:03:54

                    > via reth4.30

                    [Static/5] 06:00:21

                    > to 10.24.255.254 via reth1.255

192.168.3.2/32     *[Local/0] 06:06:35

                      Local via reth4.30

224.0.0.2/32       *[PIM/0] 06:06:37

                      MultiRecv

224.0.0.13/32      *[PIM/0] 06:06:37

                      MultiRecv

224.0.0.22/32      *[IGMP/0] 06:03:54

                      MultiRecv

 

---------------------------

 

Any hints of there to resolved DNS from the default vr to untrust-vr ? 🙂

 

The DNS server are in 10.23.0.0/24 network

 

Cheers