CPUG: The Check Point User Group

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


First, I hope you're all well and staying safe.
Second, I want to give a "heads up" that you should see more activity here shortly, and maybe a few cosmetic changes.
I'll post more details to the "Announcements" forum soon, so be on the lookout. -E

 

Results 1 to 7 of 7

Thread: accessing NATed internal IP from outside not working (no translation happening)

  1. #1
    Join Date
    2012-08-06
    Posts
    63
    Rep Power
    9

    Default accessing NATed internal IP from outside not working (no translation happening)

    Hi,

    I have NAT problems.

    Outside clients are: 172.17.7.0/24
    Inside adresses are: 10.30.x.x
    Inside NATed addresses are: 172.29.255.x

    I have the following NAT rules


    Click image for larger version. 

Name:	nat.jpg 
Views:	172 
Size:	21.9 KB 
ID:	937

    However an incoming ping (ICMP) just doesn't get translated and gets routed back to the default interface since there is no explicit route for the NATed address (and I guess there shouldn't be as it's supposed to be natted).

    Here the fw monitor output:

    Code:
    [vs_0][fw_0] eth6.45:i0 (IP Options Strip (in))[60]: 172.17.7.114 -> 172.29.255.38 (ICMP) len=60 id=46166
    ICMP: type=8 code=0 echo request id=1792 seq=46441
    [vs_0][fw_0] eth6.45:i1 (Stateless verifications (in))[60]: 172.17.7.114 -> 172.29.255.38 (ICMP) len=60 id=46166
    ICMP: type=8 code=0 echo request id=1792 seq=46441
    [vs_0][fw_0] eth6.45:i2 (SecureXL conn sync)[60]: 172.17.7.114 -> 172.29.255.38 (ICMP) len=60 id=46166
    ICMP: type=8 code=0 echo request id=1792 seq=46441
    [vs_0][fw_0] eth6.45:i3 (fw VM inbound )[60]: 172.17.7.114 -> 172.29.255.38 (ICMP) len=60 id=46166
    ICMP: type=8 code=0 echo request id=1792 seq=46441      *****NOT TRANSLATED*****
    [vs_0][fw_0] eth6.45:I5 (SecureXL inbound)[60]: 172.17.7.114 -> 172.29.255.38 (ICMP) len=60 id=46166
    ICMP: type=8 code=0 echo request id=1792 seq=46441   
    [vs_0][fw_0] eth6.45:I6 (fw SCV inbound)[60]: 172.17.7.114 -> 172.29.255.38 (ICMP) len=60 id=46166
    ICMP: type=8 code=0 echo request id=1792 seq=46441
    [vs_0][fw_0] eth6.45:I7 (passive streaming (in))[60]: 172.17.7.114 -> 172.29.255.38 (ICMP) len=60 id=46166
    ICMP: type=8 code=0 echo request id=1792 seq=46441
    [vs_0][fw_0] eth6.45:I8 (TCP streaming (in))[60]: 172.17.7.114 -> 172.29.255.38 (ICMP) len=60 id=46166
    ICMP: type=8 code=0 echo request id=1792 seq=46441
    [vs_0][fw_0] eth6.45:I9 (IP Options Restore (in))[60]: 172.17.7.114 -> 172.29.255.38 (ICMP) len=60 id=46166
    ICMP: type=8 code=0 echo request id=1792 seq=46441
    [vs_0][fw_0] eth6.45:I10 (HA Forwarding)[60]: 172.17.7.114 -> 172.29.255.38 (ICMP) len=60 id=46166
    ICMP: type=8 code=0 echo request id=1792 seq=46441
    [vs_0][fw_0] eth6.45:I11 (Chain End)[60]: 172.17.7.114 -> 172.29.255.38 (ICMP) len=60 id=46166
    ICMP: type=8 code=0 echo request id=1792 seq=46441
    
    [vs_0][fw_0] eth6.45:o0 (IP Options Strip (out))[60]: 172.17.7.114 -> 172.29.255.38 (ICMP) len=60 id=46166
    ICMP: type=8 code=0 echo request id=1792 seq=46441
    [vs_0][fw_0] eth6.45:o1 (TCP streaming (out))[60]: 172.17.7.114 -> 172.29.255.38 (ICMP) len=60 id=46166
    ICMP: type=8 code=0 echo request id=1792 seq=46441
    ...
    Translations from inside to outside (plus replies) are ok (Rule #91).
    Rule#90 just won't have any effect.

    Is there a NAT cache maybe somewhere and it needs to be cleaned?

    Please help, I'm losing my sanity ;-)

    ---

    Note: I don't think proxy arp is required as 172.29.255.x are "virtual" IPs, only for NAT, this is not a directly connected network. Correct me if I'm wrong. But in case I have to define it, what Real IP do I use? The cluster/VRRP IP?

    Note 2: The connection is incoming on the interface that as far as topology is concerned is the external interface. Is that a problem?
    Last edited by jeronimo; 2015-04-15 at 14:22.

  2. #2
    Join Date
    2007-06-04
    Posts
    3,314
    Rep Power
    18

    Default Re: accessing NATed internal IP from outside not working (no translation happening)

    Firstly I would if using fw monitor then use

    fwaccel off

    to turn off SecureXL as gives you incorrect output in the fw monitor


    I must presume here that as getting the traffic to the IP address arriving at the Firewall that you route the traffic for that NAT to the Firewall so Proxy ARP shouldn't be needed.

    Being External shouldn't be a problem.

    Is Translate Destination on Client Side checked under Global Properties for Manual NAT?

    What appears to be happening is traffic is arriving at the Firewall, isn't being dropped, but then when routed is being routed back out the same interface by the Default Gateway, so wouldn't get NATed as never reaches the other side.

    If don't want to change the NAT then add a route for the NAT IP and give the next hop as the Internal IP. You will probably need to add the NAT IP to the Topology of the Internal Interface as well.

  3. #3
    Join Date
    2012-08-06
    Posts
    63
    Rep Power
    9

    Default Re: accessing NATed internal IP from outside not working (no translation happening)

    Quote Originally Posted by mcnallym View Post
    Firstly I would if using fw monitor then use

    fwaccel off

    to turn off SecureXL as gives you incorrect output in the fw monitor
    It's off already, so, unfortunately no incorrect output.

    I must presume here that as getting the traffic to the IP address arriving at the Firewall that you route the traffic for that NAT to the Firewall so Proxy ARP shouldn't be needed.
    That's exactly what I meant.

    Is Translate Destination on Client Side checked under Global Properties for Manual NAT?
    I didn't know there was a setting like that, unfortunately it is enabled already.

    What's the "client side"? I think I understand "destination" but "client"? Since we're talking about IP addresses here I don't get the point of "client" or "server". Do they mean "initiator" with "client"? What's the philosophy here?

    I've seen this (https://www.fir3net.com/Firewalls/Ch...-side-nat.html), but I don't really get the point.

    What appears to be happening is traffic is arriving at the Firewall, isn't being dropped, but then when routed is being routed back out the same interface by the Default Gateway, so wouldn't get NATed as never reaches the other side.
    So as far as I understand, we have:
    - ACL
    - (No Client NAT) (Why??)
    - Routing (to the wrong place since not correctly NATed)
    - (No) Destination NAT (too late anyway)
    - ...
    That's strange, for an ICMP reply packet (which works fine) it looks like this:

    Code:
    [vs_0][fw_0] eth6.45:i0 (IP Options Strip (in))[84]: 172.17.7.114 -> 172.29.255.53 (ICMP) len=84 id=46154
    ICMP: type=0 code=0 echo reply id=4126 seq=2305
    [vs_0][fw_0] eth6.45:i1 (Stateless verifications (in))[84]: 172.17.7.114 -> 172.29.255.53 (ICMP) len=84 id=46154
    ICMP: type=0 code=0 echo reply id=4126 seq=2305
    [vs_0][fw_0] eth6.45:i2 (SecureXL conn sync)[84]: 172.17.7.114 -> 172.29.255.53 (ICMP) len=84 id=46154
    ICMP: type=0 code=0 echo reply id=4126 seq=2305
    [vs_0][fw_0] eth6.45:i3 (fw VM inbound )[84]: 172.17.7.114 -> 172.29.255.53 (ICMP) len=84 id=46154
    ICMP: type=0 code=0 echo reply id=4126 seq=2305  *** NAT OK ***
    [vs_0][fw_0] eth6.45:I5 (SecureXL inbound)[84]: 172.17.7.114 -> 10.31.1.53 (ICMP) len=84 id=46154
    ICMP: type=0 code=0 echo reply id=4126 seq=2305
    [vs_0][fw_0] eth6.45:I6 (fw SCV inbound)[84]: 172.17.7.114 -> 10.31.1.53 (ICMP) len=84 id=46154
    ICMP: type=0 code=0 echo reply id=4126 seq=2305
    [vs_0][fw_0] eth6.45:I7 (passive streaming (in))[84]: 172.17.7.114 -> 10.31.1.53 (ICMP) len=84 id=46154
    ICMP: type=0 code=0 echo reply id=4126 seq=2305
    [vs_0][fw_0] eth6.45:I8 (TCP streaming (in))[84]: 172.17.7.114 -> 10.31.1.53 (ICMP) len=84 id=46154
    ICMP: type=0 code=0 echo reply id=4126 seq=2305
    [vs_0][fw_0] eth6.45:I9 (IP Options Restore (in))[84]: 172.17.7.114 -> 10.31.1.53 (ICMP) len=84 id=46154
    ICMP: type=0 code=0 echo reply id=4126 seq=2305
    [vs_0][fw_0] eth6.45:I10 (HA Forwarding)[84]: 172.17.7.114 -> 10.31.1.53 (ICMP) len=84 id=46154
    ICMP: type=0 code=0 echo reply id=4126 seq=2305
    [vs_0][fw_0] eth6.45:I11 (Chain End)[84]: 172.17.7.114 -> 10.31.1.53 (ICMP) len=84 id=46154
    ICMP: type=0 code=0 echo reply id=4126 seq=2305
    
    **ROUTING HAPPENS HERE IT SEEMS**
    
    [vs_0][fw_0] eth4.29:o0 (IP Options Strip (out))[84]: 172.17.7.114 -> 10.31.1.53 (ICMP) len=84 id=46154
    ICMP: type=0 code=0 echo reply id=4126 seq=2305
    [vs_0][fw_0] eth4.29:o1 (TCP streaming (out))[84]: 172.17.7.114 -> 10.31.1.53 (ICMP) len=84 id=46154
    ICMP: type=0 code=0 echo reply id=4126 seq=2305
    [vs_0][fw_0] eth4.29:o2 (passive streaming (out))[84]: 172.17.7.114 -> 10.31.1.53 (ICMP) len=84 id=46154
    So in the original example it should be NATed long before routing?

    If don't want to change the NAT then add a route for the NAT IP and give the next hop as the Internal IP. You will probably need to add the NAT IP to the Topology of the Internal Interface as well.
    That's awkward, what if there is no next hop? What if this is the last router? It isn't, but what if? ;-) That's a nasty hack you have to implement there.

    I want to change the NAT..... in a way such that what I like to do just works without any hacks. :-)

  4. #4
    Join Date
    2013-09-25
    Location
    Bucharest
    Posts
    649
    Rep Power
    8

    Default Re: accessing NATed internal IP from outside not working (no translation happening)

    Without a deep look over this I still think you need to make sure your routing info does exist before NAT kicks in.

  5. #5
    Join Date
    2009-04-30
    Location
    Colorado, USA
    Posts
    2,252
    Rep Power
    15

    Default Re: accessing NATed internal IP from outside not working (no translation happening)

    Assuming the default options are enabled on the Global Properties NAT page (client-side translation), translation works like this if a NAT rule matches the packet:

    • If the source IP address is subject to NAT the translation occurs on the outbound/server side (o->O)
    • If the destination IP address is subject to NAT the translation occurs on the inbound/client side (i->I)

    These principles apply regardless of connection direction or NAT type (Static/Hide). For example:

    1. A new connection from inside to the Internet is initiated and it is subject to Hide NAT. The TCP SYN's source IP is subject to NAT so it occurs on the server/outbound side.
    2. The return's SYN-ACK's destination IP is subject to NAT so it occurs on the inbound/client side.
    3. The final ACK's source IP is subject to NAT so the translation occurs on the server/outbound side.

    If the destination IP is subject to NAT, we translate prior to routing so when the IP driver makes its routing decision it is based on the post-NAT destination IP address. The IP driver generally doesn't care about the source address (unless policy-based routing is employed) so we wait to translate the source IP until the outbound side (o->O) to avoid a conflict with anti-spoofing enforcement.

    So with all that said, to the OP's original problem:

    New outbound connections appear to be successfully matching on NAT rule 91 and reply packets are matching up via stateful inspection and are being successfully translated on the return path. It would appear new inbound connections to this NAT address are not matching NAT rule 90 at all. My guess is that the new inbound connections are matching an anti-NAT rule (where the Translated Packet is Original Original Original) prior to rule 90. You need to find the SmartView Tracker entry for these new inbound connections, double-click them, and see what NAT rule is being applied. My guess is that it is something prior to 90 or perhaps rule 90 is not constructed with the proper addresses for matching under Original Packet.

    If you are permitting ICMP in the Global Properties implied rules, you'll need to check "Log Implied Rules" on that screen and reinstall policy to see the inbound ICMP connection logs. I also seem to recall some odd quirks involving NAT and rule 0 when ICMP is permitted via the Global Properties implied rules, if you are allowing ICMP that way try disabling the ICMP checkbox and creating an explicit security policy rule permitting ICMP inbound to that NAT address.
    --
    Third Edition of my "Max Power 2020" Firewall Book
    Now Available at http://www.maxpowerfirewalls.com

  6. #6
    Join Date
    2012-08-06
    Posts
    63
    Rep Power
    9

    Default Re: accessing NATed internal IP from outside not working (no translation happening)

    What you write makes sense.

    Maybe there were errors in the NAT before but the final config was OK. I also see correct translations. All ICMP packets are logged (except from some monitoring servers etc.)

    Could one of the problems be that if they leave a ping running on the remote side and I update my (NAT) rules (because they were wrong before or whatever), then their pings continue running (because the flow/connection was established) and is not rechecked as long as it is running. The pings would have to stop and time out from the connections table for the new rules to really apply, no?

    It's not always easy simulating traffic if you don't control the other side.....

    Currently I'm NATing in front of the Checkpoint such that the only thing required is identity nat on the CP in order to disable automatic rules etc., which seems to work fine.

    I guess I'll have to build a little lab to get to the bottom of this.

    I'll let you all know.

    Thanks for now and thanks for the detailed explanations.

  7. #7
    Join Date
    2009-04-30
    Location
    Colorado, USA
    Posts
    2,252
    Rep Power
    15

    Default Re: accessing NATed internal IP from outside not working (no translation happening)

    Quote Originally Posted by jeronimo View Post
    What you write makes sense.

    Maybe there were errors in the NAT before but the final config was OK. I also see correct translations. All ICMP packets are logged (except from some monitoring servers etc.)

    Could one of the problems be that if they leave a ping running on the remote side and I update my (NAT) rules (because they were wrong before or whatever), then their pings continue running (because the flow/connection was established) and is not rechecked as long as it is running. The pings would have to stop and time out from the connections table for the new rules to really apply, no?
    Definitely. After stopping a ping you'll need to wait at least 30 seconds by default (exact value is set on the "Stateful Inspection" screen under Global Properties) for the firewall to finish tracking the ICMP "connection" and thus apply any NAT rule changes on the next ping attempt.
    --
    Third Edition of my "Max Power 2020" Firewall Book
    Now Available at http://www.maxpowerfirewalls.com

Similar Threads

  1. Replies: 0
    Last Post: 2013-03-13, 08:57
  2. FW1 Log to Nated Smartcenter IP not internal
    By warriar in forum SmartView Tracker
    Replies: 1
    Last Post: 2010-08-23, 04:06
  3. NATed Connections are not working on Nokia IP Clustering
    By mohankumar in forum Check Point IP Appliances and IPSO (Formerly Sold By Nokia)
    Replies: 3
    Last Post: 2009-08-25, 12:00
  4. accessing external ip from internal
    By gunnar in forum NAT (Network Address Translation)
    Replies: 5
    Last Post: 2008-04-18, 05:31
  5. SC only working when on Internal Network
    By Roch_Greg in forum SecureClient/SecuRemote
    Replies: 4
    Last Post: 2008-03-29, 17:06

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
  •