SRX

Hi,

I have just come across a very big problem on the SRX. I have configured zones with Logical Tunnels between the Zones (lt interfaces).

I really locked down the SRX and was informed that the DNS resolutions on the anycast no longer function. Here is the route taken:

Customer-VR - lt-0/0/1 - lt-0/0/2 - test-dns:

So, normally I would expect 4 policies to be in place for this as follows:

Customer-VR to Customer-VR (ae1 interface to lt-0/0/1)

Customer-VR to test-dns VR (lt-0/0/1 to lt-0/0/2)

test-dns VR to test-dns VR (lt-0/0/2 - ge-0/0/6)

test-dns VR to Customer-VR (lt-0/0/2 to lt-0/0/1)

The only one of these policies that seems to do anything is: test-dns VR to test-dns VR.

But that is not the main issue. I can deal with that. I supplied this information to give you an overview:

I am testing anycast where 2 addresses are for subscribes from the LNS and the other 2 for everyone, including the outside.

So, I removed all the configuration for test-dns to test-dns and replaced with an "any any any permit" and the whole anycast started working again. To complete the test I then changed the applicatin to be "junos-dns-udp" and it still worked. Then I placed an implicit deny as follows "any any any deny". So the rule base would look like this for the policy:

from test-dns to test-dns match source any

from test-dns to test-dns match destination any

from test-dns to test-dns match application any

from test-dns to test-dns then permit

from test-dns to test-dns1 match source any

from test-dns to test-dns1 match destination any

from test-dns to test-dns1 match application any

from test-dns to test-dns1 then deny

And everything stopped working again. This does not seem right to me. Surely the packets hit the first rule and should be accepted without even touching the second rule? This will be a really big issue if the packets are not going through the rules in a correct order.

Has anyone seen this behaviour before?

I hope you have inserted the deny policy after permit policy manually, by deafult the latest policy comes on top.

If you have done this already, can you run "show security policy hit-count" during the issue and check if its actually hitting the deny policy or dropped by some other reason.

Hi Suraj,

Yes. As per my statement above, the permit is first then the deny. So, it seems to be ignoring the permit and going straight to deny. When I get to work tomorrow I will have a look at the policy hot count and see what is happening.

As for the other part where only one policy seems to be working, that is correct behaviour with lt tunnles as they are point-to-point. So, only INTRA zone policies are required and not INTER zone.

Thanks

Sorry Suraj.

I've just re-read your post. What do you mean the latest policy comes on top? That, from a troubleshooting perspective is simply not good. A security policy should always read from the top down, not the bottom up. So, with my example from my original question above, you ar telling me that although it is written and shown as "Permit" first and then "deny", the actual SRX completes the "deny" first and then the "permit"?

That seems very counter-intuitive to me. Having to read the list from the bottom up.

I can give it a test and see what the results are.

Hi Suraj,

So, I tried what you stated and ended up with the following configuration (as per mine above):

set security policies from-zone ninegroup-dns to-zone ninegroup-dns policy to-thwdns-other-anycast3 match source-address any
set security policies from-zone ninegroup-dns to-zone ninegroup-dns policy to-thwdns-other-anycast3 match destination-address any
set security policies from-zone ninegroup-dns to-zone ninegroup-dns policy to-thwdns-other-anycast3 match application any
set security policies from-zone ninegroup-dns to-zone ninegroup-dns policy to-thwdns-other-anycast3 then permit
set security policies from-zone ninegroup-dns to-zone ninegroup-dns policy to-thwdns-other-anycast3 then log session-init
set security policies from-zone ninegroup-dns to-zone ninegroup-dns policy to-thwdns-other-anycast4 match source-address any
set security policies from-zone ninegroup-dns to-zone ninegroup-dns policy to-thwdns-other-anycast4 match destination-address any
set security policies from-zone ninegroup-dns to-zone ninegroup-dns policy to-thwdns-other-anycast4 match application any
set security policies from-zone ninegroup-dns to-zone ninegroup-dns policy to-thwdns-other-anycast4 then deny
set security policies from-zone ninegroup-dns to-zone ninegroup-dns policy to-thwdns-other-anycast4 then log session-init

Now, this is exactly the same as I did before but this time it works.

So, the strange thing here is that if I have configured a full policy statement and forgot to add the deny, or wanted to change it, I would have to rewrite the whole policy? That can't be right.

The only difference between the two is that the one that did not work I added the explicit deny after a few days and this time I did them both at the same time. That is strange behaviour.

Hi Suraj,

Last question to explain everything please:

If I write a policy and further down the road we add new equipment to the network and that policy needs updating. Let's say I add a new DNS server and want to add that in to the existing policy. So, I create a new address and I create a new rule within the policy because I only want certain systems added. Let's take the following as an example:

I want the whole internet to be able to access anycast 1 and 2 but not 3 and 4 and I want subscribers to be able to access all 4 addresses. So I write the following:

set security address-book global address anycast1 192.168.10.1/32

set security address-book global address anycast2 192.168.10.2/32

set security address-book global address anycast3 192.168.10.3/32

set security address-book global address anycast4 192.168.10.4/32

set security address-book global address customers 192.168.100.0/24

set security address-book global address-set anyone  address anycast1

set security address-book global address-set anyone address anycast 2

set security address-book global address-set subscribers address anycast1

set security address-book global address-set subscribers address anycast2

set security address-book global address-set subscribers address anycast3

set security address-book global address-set subscribers address anycast4

So, I complete the following policy based on the above:

[edit security policies from-zone dns to-zone dns policy anycast-subscriber]

set match source-address Customers

set match destination-address subscribers

set match application junos-dns-udp

set then permit

set then log session-init

[edit security policies from-zone dns to-zone dns policy anycast-subscriber-1]

set match source-address subscribers

set match destination-address Customers

set match application junos-dns-udp

set then permit

set then log session-init

[edit security policies from-zone dns to-zone dns policy anycast-subscriber-2]

set match source-address any

set match destination-address any

set match application any

set then deny

set then log session-init

Okay, so that should work for the subscribers. But then I notice that I have forgotten to add the internet queries that could occur from any source. So, if I add them in and I want a readable order in the policy, I then insert them where they need to be inserted so that they become readable and the packets are queried when they should be there are two possible results according to the statment you made:

1: It does not matter where I insert the new section of the policy as it will always be executed first?

2: It does insert where you want it to and it will be read within the policy in the correct, logical, order?

Thanks

I will close this as resolved.

After testing it would seem that the following occurs:

When writing the policy, make sure you write the deny and then do not touch it again. As long as you make no changes on the deny (which you should not need to if it is an "any, any, any, deny) then all works okay. Changes to the policy can be made and things moved around as long as you do not touch the deny.

Thank Suraj. Much appreciated.