PIX 501 Firewall and NTP?

Discussion in 'Cisco' started by Josh T, Apr 14, 2004.

  1. Josh T

    Josh T Guest

    Hello,

    I have a PIX 501 Firewall running version 6.3. I'm trying to get it to
    sync time with public time servers, so I issue the following to set it up:

    clock timezone EST -5
    clock summer-time EDT recurring
    clock set <to current time>
    ntp server 192.43.244.18 source outside
    ntp server 131.107.1.10 source outside
    ntp server 129.6.15.29 source outside
    ntp server 129.6.15.28 source outside

    This doesn't work, it doesn't sync, and it logs lines like:
    %PIX-2-106006: Deny inbound UDP from 192.43.244.18/123 to *.*.12.8/123
    on interface outside

    How do I work around this? I already have a config like this:

    static (inside,outside) *.*.12.8 192.168.1.2 netmask 255.255.255.255 0 0
    conduit permit icmp host *.*.12.8 any echo-reply
    <snip most conduit statements>

    But if I issue this command (for each time server), it's going to
    forward ntp to 192.168.1.2, not the pix itself, right?

    conduit permit udp host *.*.12.8 eq ntp host 192.43.244.18 eq ntp

    Thanks for any help,
    Josh
    Josh T, Apr 14, 2004
    #1
    1. Advertising

  2. Josh T

    Chad Mahoney Guest

    Josh T wrote:

    > Hello,
    >
    > I have a PIX 501 Firewall running version 6.3. I'm trying to get it to
    > sync time with public time servers, so I issue the following to set it up:
    >
    > clock timezone EST -5
    > clock summer-time EDT recurring
    > clock set <to current time>
    > ntp server 192.43.244.18 source outside
    > ntp server 131.107.1.10 source outside
    > ntp server 129.6.15.29 source outside
    > ntp server 129.6.15.28 source outside
    >
    > This doesn't work, it doesn't sync, and it logs lines like:
    > %PIX-2-106006: Deny inbound UDP from 192.43.244.18/123 to *.*.12.8/123
    > on interface outside
    >
    > How do I work around this? I already have a config like this:
    >
    > static (inside,outside) *.*.12.8 192.168.1.2 netmask 255.255.255.255 0 0
    > conduit permit icmp host *.*.12.8 any echo-reply
    > <snip most conduit statements>
    >
    > But if I issue this command (for each time server), it's going to
    > forward ntp to 192.168.1.2, not the pix itself, right?
    >
    > conduit permit udp host *.*.12.8 eq ntp host 192.43.244.18 eq ntp
    >
    > Thanks for any help,
    > Josh



    Josh,

    First I would scrap the conduits and use access-list.

    but conduit permit udp host 192.43.244.18 host *.*.12.8 eq ntp

    Not sure on the conduit format.


    Chad
    Chad Mahoney, Apr 14, 2004
    #2
    1. Advertising

  3. Josh T

    Josh T Guest

    Chad Mahoney wrote:
    > First I would scrap the conduits and use access-list.
    >


    Been meaning to do that for awhile, I suppose now would be a good time...

    > but conduit permit udp host 192.43.244.18 host *.*.12.8 eq ntp
    >
    > Not sure on the conduit format.
    >


    I believe conduits use "local addr" "foreign address" order, rather that
    "source" "destination" order, as I have other conduits that have the
    local address first that work. Either way, conduit or ACL, does this
    not just forward the packets to an internal server rather than the PIX?

    Thanks,
    Josh
    Josh T, Apr 15, 2004
    #3
  4. Josh T

    mh Guest

    configure:

    ntp server 192.43.244.18 source outside
    ntp server 131.107.1.10 source outside
    ntp server 129.6.15.29 source outside
    ntp server 129.6.15.28 source outside

    access-list INBOUND permit udp host 192.43.244.18 any eq ntp
    access-list INBOUND permit udp host 131.107.1.10 any eq ntp
    access-list INBOUND permit udp host 129.6.15.29 any eq ntp
    access-list INBOUND permit udp host 129.6.15.28 any eq ntp

    access-group INBOUND in interface outside
    mh, Apr 17, 2004
    #4
  5. In article <>,
    mh <> wrote:
    :configure:

    ;ntp server 192.43.244.18 source outside
    ;ntp server 131.107.1.10 source outside
    ;ntp server 129.6.15.29 source outside
    ;ntp server 129.6.15.28 source outside

    :access-list INBOUND permit udp host 192.43.244.18 any eq ntp
    :access-list INBOUND permit udp host 131.107.1.10 any eq ntp
    :access-list INBOUND permit udp host 129.6.15.29 any eq ntp
    :access-list INBOUND permit udp host 129.6.15.28 any eq ntp

    :access-group INBOUND in interface outside

    No, access-list controls traffic -through- the PIX, and ntp traffic
    is traffic *to* the PIX. Nothing you put in your outside access list
    would affect ntp traffic to the PIX.


    I know that the original posting -appears- to show access-list blocking
    of the ntp traffic, but there were some details left out -- details
    such as the outside address and possible static or nat entries that might
    be affecting the flow.

    --
    Caution: A subset of the statements in this message may be
    tautologically true.
    Walter Roberson, Apr 17, 2004
    #5
  6. Josh T

    Josh T Guest

    Walter Roberson wrote:
    > No, access-list controls traffic -through- the PIX, and ntp traffic
    > is traffic *to* the PIX. Nothing you put in your outside access list
    > would affect ntp traffic to the PIX.
    >


    That's what I had originally thought...

    > I know that the original posting -appears- to show access-list blocking
    > of the ntp traffic, but there were some details left out -- details
    > such as the outside address and possible static or nat entries that might
    > be affecting the flow.
    >


    Here's the snippets from the config - Pretend 10.1.12.8 is a real,
    non-private ip address provided by my ISP.

    ip address outside 10.1.12.8 255.255.255.248
    ip address inside 192.168.1.1 255.255.255.0
    global (outside) 1 interface
    nat (inside) 1 0.0.0.0 0.0.0.0 0 0
    static (inside,outside) 10.1.12.8 192.168.1.2 netmask 255.255.255.255 0 0

    Thanks,
    Josh
    Josh T, Apr 20, 2004
    #6
  7. In article <Lz8hc.68069$>,
    Josh T <> wrote:
    :Here's the snippets from the config - Pretend 10.1.12.8 is a real,
    :non-private ip address provided by my ISP.

    :ip address outside 10.1.12.8 255.255.255.248
    :ip address inside 192.168.1.1 255.255.255.0
    :global (outside) 1 interface
    :nat (inside) 1 0.0.0.0 0.0.0.0 0 0
    :static (inside,outside) 10.1.12.8 192.168.1.2 netmask 255.255.255.255 0 0

    If the 10.1.12.8 in your static command is your outside IP address,
    the same one in your "ip address outside" command, then you have
    a problem.

    On the PIX, in any version that supports real traffic directed
    to the outside IP address (earlier versions did not, you always
    needed a minimum of 2 IPs before), you never directly refer to the
    outside IP address in any 'static' or access-list statement. Instead,
    you have to use a placeholder for the interface address. For 'static'
    statements, the placeholder is the word 'interface'. For PIX 6.2 through
    to 6.3(1) [I think it was], in access-lists, the placeholder was again
    the word 'interface'. Starting in 6.3(2), in access-lists the placeholder
    became the word 'interface' followed by the interface name. For example,

    access-list out2in permit tcp any interface outside eq smtp


    Secondly, you have the problem that you are trying to static the
    *entire* outside interface traffic. Recall that static'd addresses
    preserve port numbers, so that logically conflicts with having
    a 'global (outside) 1 interface' statement, which needs free ports
    to work with. But even if 192.168.1.2 is your only inside host,
    you could not solve the problem by just removing the 'global':
    the PIX reserves some ports (such as telnet) with regards to the
    outside interface IP, so you simply are not allowed to static
    the entire outside IP.

    What you will have to do is convert that 'static' command into
    a series of "extended static" commands that match -just- the traffic
    that needs to go to particular ports on 192.168.1.2 . For example,

    static (inside, outside) tcp interface smtp 192.168.1.2 smtp netmask 255.255.255.255 0 0
    static (inside, outside) udp interface 123 192.168.1.2 123 netmask 255.255.255.255 0 0

    There is a restriction, though, that you cannot map the outside
    interface telnet port through this mechanism (and there's one other
    port in the 1700 range you cannot map either.)
    --
    I've been working on a kernel
    All the livelong night.
    I've been working on a kernel
    And it still won't work quite right. -- J. Benson & J. Doll
    Walter Roberson, Apr 20, 2004
    #7
  8. Josh T

    Josh T Guest

    Walter, thank you very much for your help. I'll be experimenting with
    this as soon as I finish another project.

    Josh
    Josh T, Apr 22, 2004
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jyri Korhonen

    Pix 501, VPN and NTP

    Jyri Korhonen, Feb 10, 2004, in forum: Cisco
    Replies:
    1
    Views:
    748
    Walter Roberson
    Feb 10, 2004
  2. Gianlu
    Replies:
    0
    Views:
    630
    Gianlu
    Jul 2, 2004
  3. Scott Crabb

    ntp from ntp.org

    Scott Crabb, Aug 5, 2004, in forum: Cisco
    Replies:
    5
    Views:
    3,664
  4. Andre
    Replies:
    7
    Views:
    710
    Andre
    Feb 20, 2005
  5. Tiaan van Aardt

    allow NTP to synch through a PIX

    Tiaan van Aardt, Oct 6, 2006, in forum: Cisco
    Replies:
    1
    Views:
    2,663
Loading...

Share This Page