SRX

Expand all | Collapse all

Using fully qualified domain names in security policies - traffic will be drop

  • 1.  Using fully qualified domain names in security policies - traffic will be drop

    Posted 06-27-2017 05:18

    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

     



  • 2.  RE: Using fully qualified domain names in security policies - traffic will be drop

     
    Posted 06-27-2017 05:53

    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



  • 3.  RE: Using fully qualified domain names in security policies - traffic will be drop

     
    Posted 07-02-2017 09:23

    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.



  • 4.  RE: Using fully qualified domain names in security policies - traffic will be drop

    Posted 07-04-2017 02:23

    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

     

     



  • 5.  RE: Using fully qualified domain names in security policies - traffic will be drop

     
    Posted 07-04-2017 04:45

    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?



  • 6.  RE: Using fully qualified domain names in security policies - traffic will be drop

    Posted 07-05-2017 04:57

     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



  • 7.  RE: Using fully qualified domain names in security policies - traffic will be drop

     
    Posted 07-05-2017 06:48

    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.