SRX

Hello,

i have a SRX1500 with Junos 15.1X49-D75.5. I created a security policy like this:

policy pol_DMZ-MDM_to_Untrust-ISP1_Apple_feedback {
match {
source-address H_Airwatch-MDM_10.39.198.2;
destination-address H_feedback.push.apple.com;
application S_TCP_2196;
}
then {
permit;
}
}

The connection doesn't work.When i set the destination adress to "any", the connection works fine. The SRX resolves the fqdn periodically:

Policy: pol_DMZ-MDM_to_Untrust-ISP1_Apple_feedback, action-type: permit, State: enabled, Index: 24, Scope Policy: 0
Policy Type: Configured
Sequence number: 1
From zone: DMZ-MDM, To zone: Untrust-ISP1
Source addresses:
H_Airwatch-MDM_10.39.198.2: 10.39.198.2/32
Destination addresses:
H_feedback.push.apple.com: 17.188.161.75/32
H_feedback.push.apple.com: 17.188.164.13/32
H_feedback.push.apple.com: 17.188.166.143/32
H_feedback.push.apple.com: 17.188.162.137/32
H_feedback.push.apple.com: 17.188.167.200/32
H_feedback.push.apple.com: 17.188.160.76/32
H_feedback.push.apple.com: 17.188.168.12/32
H_feedback.push.apple.com: 17.188.166.90/32
Application: S_TCP_2196
IP protocol: tcp, ALG: 0, Inactivity timeout: 1800
Source port range: [0-0]
Destination port range: [2196-2196]
Per policy TCP Options: SYN check: No, SEQ check: No, Window scale: No

{primary:node0}
admin@FW> show security policies policy-name pol_DMZ-MDM_to_Untrust-ISP1_Apple_feedback detail
node0:
--------------------------------------------------------------------------
Policy: pol_DMZ-MDM_to_Untrust-ISP1_Apple_feedback, action-type: permit, State: enabled, Index: 24, Scope Policy: 0
Policy Type: Configured
Sequence number: 1
From zone: DMZ-MDM, To zone: Untrust-ISP1
Source addresses:
H_Airwatch-MDM_10.39.198.2: 10.39.198.2/32
Destination addresses:
H_feedback.push.apple.com: 17.188.129.159/32
H_feedback.push.apple.com: 17.188.131.27/32
H_feedback.push.apple.com: 17.188.141.26/32
H_feedback.push.apple.com: 17.188.139.156/32
H_feedback.push.apple.com: 17.188.129.153/32
H_feedback.push.apple.com: 17.188.128.157/32
H_feedback.push.apple.com: 17.188.137.28/32
H_feedback.push.apple.com: 17.188.128.154/32
Application: S_TCP_2196
IP protocol: tcp, ALG: 0, Inactivity timeout: 1800
Source port range: [0-0]
Destination port range: [2196-2196]
Per policy TCP Options: SYN check: No, SEQ check: No, Window scale: No

Does anybody know what's the problem is? 

bye,

steffi

Hello,

This indicates that the application configured (S_TCP_2196) is not completely matching the traffic flow that needs to be permitted.

Can you provide configuration of the application S_TCP_2196 (I see it in the policy output but would like to check configuration)?

Also can you explain what traffic needs to be permitted?

Regards,

Rushi

When you have the policy set to any destination, what ip addresses do the policy logs show as being used by the clients?

It sounds like there is an addition destination(s) that need to be added to the rule.

Hello,

thank's for the reply. 

The IPs from the fqdns changes every few minutes, that's why we want to work with the fqdn. I did a conncection with telnet and port 2196. The destination in the security policy is any.  That's the output from the SRX session flow:

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

Session ID: 79791, Policy name: pol_DMZ-MDM_to_Untrust-ISP1_Apple_feedback/24, State: Active, Timeout: 1796, Valid
In: 10.39.198.2/50344 --> 17.188.148.37/2196;tcp, Conn Tag: 0x0, If: reth1.198, Pkts: 2, Bytes: 92,
Out: 17.188.148.37/2196 --> 185.46.137.110/59780;tcp, Conn Tag: 0x0, If: reth0.2001, Pkts: 1, Bytes: 52,
Total sessions: 1

Then i put the host object with the fqdn as destination in the policy and tried again:

show security flow session source-prefix 10.39.198.2
node0:
--------------------------------------------------------------------------
Total sessions: 0

 That's the address book entry:

address H_feedback.push.apple.com {
dns-name feedback.push.apple.com;
}

That's the application: 

}
application S_TCP_2196 {
protocol tcp;
destination-port 2196;
}

bye,

steffi

With the FQDN policy setup use this to see what addresses the SRX is including in the policy.

show security policies policy-name NAME detail

Is the SRX using the same DNS resolution as your clients so that the lists will match?

 It's not so easy to figure it out, because the IP's changes really often. In my test, i had different IPs. I only see the address, when the fqdn object is in the policy. Between both commands are approximately 30 seconds. So, I'm not sure whether i am to slowly or the SRX resolution list is false. It seems like the SRX dns resolution list...

 show security flow session source-prefix 10.39.198.2
node0:
--------------------------------------------------------------------------

Session ID: 939274, Policy name: pol_DMZ-MDM_to_Untrust-ISP1_Apple_feedback/24, State: Active, Timeout: 1794, Valid
In: 10.39.198.2/51393 --> 17.188.135.152/2196;tcp, Conn Tag: 0x0, If: reth1.198, Pkts: 2, Bytes: 92,
Out: 17.188.135.152/2196 --> 185.46.137.110/55929;tcp, Conn Tag: 0x0, If: reth0.2001, Pkts: 1, Bytes: 52,
Total sessions: 1

show security policies policy-name pol_DMZ-MDM_to_Untrust-ISP1_Apple_feedback detail
node0:
--------------------------------------------------------------------------
Policy: pol_DMZ-MDM_to_Untrust-ISP1_Apple_feedback, action-type: permit, State: enabled, Index: 24, Scope Policy: 0
Policy Type: Configured
Sequence number: 1
From zone: DMZ-MDM, To zone: Untrust-ISP1
Source addresses:
H_Airwatch-MDM_10.39.198.2: 10.39.198.2/32
Destination addresses:
H_feedback.push.apple.com: 17.188.142.26/32
H_feedback.push.apple.com: 17.188.129.25/32
H_feedback.push.apple.com: 17.188.131.27/32
H_feedback.push.apple.com: 17.188.142.27/32
H_feedback.push.apple.com: 17.188.133.149/32
H_feedback.push.apple.com: 17.188.135.22/32
H_feedback.push.apple.com: 17.188.139.28/32
H_feedback.push.apple.com: 17.188.132.25/32
Application: S_TCP_2196
IP protocol: tcp, ALG: 0, Inactivity timeout: 1800
Source port range: [0-0]
Destination port range: [2196-2196]
Per policy TCP Options: SYN check: No, SEQ check: No, Window scale: No

best,

steffi

So this does look like the FQDN policy is working for that session and showing a new looup when you check it live.

So there are two possibilities I see:

1-there is some other request ip address that comes after this first one that prevents the session from working.

To test this you can leave this rule in place then put the "any" rule right after this with logging.  See what the ip addresses are and if they are from the same general range or seem to be from some other area.  In this case you need to add something to the rule.  Maybe your DNS server logs may help identify what the other request is.

2-the changes in resolution are so rapid that this just can't work.  The difference in time between the SRX and the client is enough to get occassionally different results.

Here I would also confirm that the SRX uses the same DNS server as the clients to be sure there is no other variable.