Verifying NAT translation is working on R81.10

[gurowar]

Good day all;

I am pretty new to Checkpoint, but how do I verify that my NAT translation is working?  On a cisco I can do a show ip nat trans | grep for the IP address that I am looking for.  Is there a similar command on Checkpoint?  On SmartConsole in the logs I can see when I make an attempt, I can see that it is accepted and in the NAT portion of log I can see  "Xlate (NAT) Destination IP  and it show me  my internal IP and the NAT Rule Number I created.  What I am trying to verify is that it is making it all the way to the internal server. I am assuming it is based on what I am seeing.  I also tried running the fw ctl conntab command and based on what I see above an this output that I am making it to the server and he server isn't responding.

[Expert@Firewall02:0]# fw ctl conntab -sip=110.49.120.141 -rule=66
<(inbound, src=[110.49.120.141 ,60263], dest=[220.180.140.138,443], TCP); 28/40, rule=66, tcp state=SYN_SENT, service=558, Ifncin=22, conn modules: Authentication, FG-1, ISP-Redundancy, SynDoSDefender>

<(inbound, src=[110.49.120.141 ,60262], dest=[220.180.140.138,443], TCP); 28/40, rule=66, tcp state=SYN_SENT, service=558, Ifncin=22, conn modules: Authentication, FG-1, ISP-Redundancy, SynDoSDefender>

<(inbound, src=[110.49.120.141 ,60264], dest=[220.180.140.138,443], TCP); 26/38, rule=66, tcp state=SYN_SENT, service=558, Ifncin=22, conn modules: Authentication, FG-1, ISP-Redundancy, SynDoSDefender>

based on this I see that it is hitting the correct public IP: 220.180.140.138

but I don't see that actual translation so I think it is working but I wanted to make sure before I turn this over to the server folks and tell them we can make it to the server but the server isn't responding.  

Thank you in advance!!!

[the_rock]

I knew of that command on Cisco, ran it while back, super useful. Not aware there is one similar to it on CP side, either on expert or clish, unless you can grep for something from the nat table itself

Maybe someone else can chime in to confirm.

Andy

https://support.checkpoint.com/results/sk/sk32224

[Lesley]

Think for beginner checking in NAT tables is pretty complex. I would recommend to give tcpdump a try or fwmonitor

Here the only website you ever need to make filters. Make sure to make captures on source IP because I think you are natting the dst. 

In general the rule is if you see NAT happen in fw log it will happen. But to see if server replies to the SYN, TCPdump will tell you. 

[genisis__]

would also suggest cpcap as alternative to tcpdump.

[the_rock]

I would also add fw monitor -F flag.

[Lesley · Accepted solution]

Forgot to paste the website: https://tcpdump101.com/#

This contains cpcap, tcpdump and also the fw monitor with -F (new version R80.20+)

[the_rock]

One of my colleagues built that website while ago, its excellent.

Andy

[gurowar]

Good Morning All,

Just an update on this, as suggested by everyone I ran cpcap, fw monitor and tcpdump.  In each cases I sourced from my home public IP and used the NATTed IP I created.  I ran the test with the one that is working and compared it to the new one I am setting up.  In each case I can see from the one that is working.  CPCAP I can see connection established, in TCPDUMP I can see conversation happening.  But when I do the same for the new one on CPCAP I only see SYNC but no response, TCPDUMP I just see the S flag and nothing else. So then I though well how do I know for sure that the NAT is working?  I figured because I can see the conversations that proved it.  But wasn't good enough so what I did was ran the same but filtered on the private IP.  So if I see the same conversation if I attempt to connect on the Public IP and on CPCAP/TCPDUMP filter for the private IP that will prove it.  Happy to say I can see the same conversations so I am confident that the new server isn't responding.  Do you all agree?

[spottex]

I make sure the xlate is in the log like you have done already.
I then tcpdump the egress interface to make sure the traffic is leaving the firewall and there is return traffic.
tcpdump -nni < egress interface> host <src_IP>

Possible issues.

FW Routing out the incorrect interface (check with 'ip route get <dest_IP>')

No return traffic in the tcpdump looking more like:
Async Routing - to view, filter logs with just the source IP (I.e. The IP only and no indication of direction).
Return route issue.
Host issue - Multiple interfaces, route on the host, local windows FW etc. 
Host issue 2 - if it is a new service on the host check if it is listening on the port: 
e.g. for port 443: netstat -iaon | find "443" | find "LISTENING"
- sometimes you need to guide the Server teams to get the info you need

[gurowar · Accepted solution]

Just wanted to give you all the final on this, so we have confirmed that the configuration on the firewall is correct and that the issue was with the server itself.  So the way I verified this along with all your suggestions, which by the way I am grateful for.... thank you all again!!! So I decided to download and run wireshark on the windows server and attempted my connection from an external device.  From the wireshark output I was able to see the Syn sent but no response from the server. Once the server folks saw that they finally said , "oh maybe I need to upload the Cert and bind it" once they did that connectivity was in place.  Again appreciate all you help!!! Much appreciated!!!

@spottex.....will take note of your suggestion for the next time

Thank you all!!!  Issue resolved!!

[Timothy_Hall]

Thanks for the follow-up, in celebration I'd suggest reading the following thread: "It's not the firewall"

[_Val_]

Lol, made my day, @Timothy_Hall 

[the_rock]

Had they only knows how great you are...o well, their loss 🙂

Andy

[the_rock]

Good job!