CPUG: The Check Point User Group

Resources for the Check Point Community, by the Check Point Community.


Tim Hall has done it again! He has just released the 2nd edition of "Max Power".
Rather than get into details here, I urge you to check out this announcement post.
It's a massive upgrade, and well worth checking out. -E

 

Results 1 to 7 of 7

Thread: NAT assistance

  1. #1
    Join Date
    2006-09-26
    Posts
    3,193
    Rep Power
    16

    Default NAT assistance

    environment: checkpoint R77.30 with HFA_216 on clusterXL H/A. There is NO NAT in this environment, only routing.

    - NTP servers sitting on DMZ: 192.168.1.1/24, 192.168.1.2/24 and 192.168.1.3/24. Firewall IP addresses is 192.168.1.252/24, 192.168.1.253/24 and ClusterXL IP is 192.168.1.254

    - Linux/Windows hosts from the Internal network is 10.0.1.1-240/24. Firewall IP addresses is 10.0.1.252/24, 10.0.1.253/24 and ClusterXL IP is 10.0.1.254

    - There is firewall rules to allow host 10.0.1.0/24 to access NTP servers in the DMZ on UDP port 123 and everything works
    without any issues.


    Problems: Due to cost, we're going to eliminate NTP servers 192.168.1.2 and 192.168.1.3 and leave only NTP server 192.168.1.1/24. We do not want to make massive change to the linux/windows clients. Therefore, we do this with the NAT
    rule:

    source: 10.0.1.0/24
    Destination: 192.168.1.2
    translated source: Original
    translated destinaton: 192.168.1.1


    source: 10.0.1.0/24
    Destination: 192.168.1.3
    translated source: Original
    translated destinaton: 192.168.1.1

    On the Linux client 10.0.1.1, I tried:

    ntpdate 192.168.1.1 ---> worked
    ntpdate 192.168.1.2 ---> failed
    ntpdate 192.168.1.3 ---> failed

    Wait one minute later:
    ntpdate 192.168.1.2 ---> worked
    ntpdate 192.168.1.1 ---> failed
    ntpdate 192.168.1.3 ---> failed

    wait one minute later:
    ntpdate 192.168.1.3 ---> worked
    ntpdate 192.168.1.1 ---> failed
    ntpdate 192.168.1.2 ---> failed


    I don't think this configuration because the NTP servers and the firewalls are directly on the same network. Is that correct?

  2. #2
    Join Date
    2007-06-04
    Posts
    3,301
    Rep Power
    17

    Default Re: NAT assistance

    I don't think is that on the same subnet that is an issue

    Looking at what you seeing then is always the first one that works.

    What happens if try

    Linux Client 10.0.1.1 to 192.168.1.1
    Linux Client 10.0.1.2 ( if exists ) to 192.168.1.2

    Does that work

    I would also look at what see in the fw monitor on the gateway do you see the NAT occurring for the reply traffic as expected with the Second Attempt and Third Attempt when trying from 1 Client to All 3.

    I suspect that the Second Attempt is trying to fold into the 1st Connection Attempt so possibly not doing the NAT on the Reply Traffic correctly.

  3. #3
    Join Date
    2006-09-26
    Posts
    3,193
    Rep Power
    16

    Default Re: NAT assistance

    Quote Originally Posted by mcnallym View Post
    I don't think is that on the same subnet that is an issue

    Looking at what you seeing then is always the first one that works.

    What happens if try

    Linux Client 10.0.1.1 to 192.168.1.1
    Linux Client 10.0.1.2 ( if exists ) to 192.168.1.2

    Does that work

    I would also look at what see in the fw monitor on the gateway do you see the NAT occurring for the reply traffic as expected with the Second Attempt and Third Attempt when trying from 1 Client to All 3.

    I suspect that the Second Attempt is trying to fold into the 1st Connection Attempt so possibly not doing the NAT on the Reply Traffic correctly.
    I have NOT done that yet but even if the above works, it will not resolve my issue because in Linux client 10.0.1.1 host I have this in the /etc/ntp.conf file:

    server 192.168.1.2 iburst
    server 192.168.1.2 iburst
    server 192.168.1.3 iburst

  4. #4
    Join Date
    2007-03-30
    Location
    DFW, TX
    Posts
    307
    Rep Power
    13

    Default Re: NAT assistance

    Quote Originally Posted by mcnallym View Post
    I suspect that the Second Attempt is trying to fold into the 1st Connection Attempt so possibly not doing the NAT on the Reply Traffic correctly.
    This is almost certainly what's going on. The destination is being changed, but the source isn't. Some janky clients (most notably, many versions of systemd) send NTP traffic from UDP port 123, not just to UDP 123. Translating the destination address doesn't change the source port. The reply would match the virtual connection opened for the connection to the real NTP server, so it would be sent to the client with no translation, and the client would ignore it as unsolicited traffic.

    The fix for this would be to add source hide NAT to the rules. Hiding behind the firewall's cluster VIP would be easiest.
    Zimmie

  5. #5
    Join Date
    2006-09-26
    Posts
    3,193
    Rep Power
    16

    Default Re: NAT assistance

    Quote Originally Posted by Bob_Zimmerman View Post
    This is almost certainly what's going on. The destination is being changed, but the source isn't. Some janky clients (most notably, many versions of systemd) send NTP traffic from UDP port 123, not just to UDP 123. Translating the destination address doesn't change the source port. The reply would match the virtual connection opened for the connection to the real NTP server, so it would be sent to the client with no translation, and the client would ignore it as unsolicited traffic.

    The fix for this would be to add source hide NAT to the rules. Hiding behind the firewall's cluster VIP would be easiest.
    Thank you for the explaination.

    However, I just tested Hide NAT the source and it does not work either :-(. If the NTP servers are directly connected to the FW, it will not work.

  6. #6
    Join Date
    2011-08-02
    Location
    http://spikefishsolutions.com
    Posts
    1,650
    Rep Power
    10

    Default Re: NAT assistance

    any chance the nat isn't happening because there is an active connection? I don't think you can modify an active flow. Drop the flow for the time your udp timeout is set to then make the NAT change you want and then allow.

    of course you could try fw tab -x but i would do the drop.

    Or have someone read about ansible.

  7. #7
    Join Date
    2011-08-02
    Location
    http://spikefishsolutions.com
    Posts
    1,650
    Rep Power
    10

    Default Re: NAT assistance

    Come to think of it, this doesn't even make sense. Who cares if it doesn't work? If the primary goes down all 3 will stop working. If the primary is working and the only one, who cares if the secondary and ternary (ha tertiary) ... is that right?... don't work?

    NTP might also be smarter than everyone else and detect they're all the same clock source.
    Last edited by jflemingeds; 4 Weeks Ago at 21:46. Reason: tertiary dang it

Similar Threads

  1. IPS assistance
    By cciesec2006 in forum IPS-1
    Replies: 2
    Last Post: 2010-02-13, 14:16
  2. FTP over SSL assistance needed
    By cciesec2006 in forum Check Point SecurePlatform (SPLAT)
    Replies: 11
    Last Post: 2009-03-20, 11:04
  3. Upgrade from R55 to R65 assistance, please
    By jobroco in forum Installing And Upgrading
    Replies: 0
    Last Post: 2009-03-03, 15:48
  4. R54 to R6X assistance needed
    By pshady in forum Installing And Upgrading
    Replies: 7
    Last Post: 2009-01-06, 08:01
  5. IKEView assistance
    By Binary_01 in forum IPsec VPN Blade (Virtual Private Networks)
    Replies: 2
    Last Post: 2008-08-06, 16:44

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •