CPUG

The Check Point User Group

A Resource For The Check Point Community.  Fast.  Useful.  Independent.

1. CCSA or CCSE One-Week Certification Training Courses with CPUG in Beautiful San Francisco!
    R70 CCSA Courses Starting (2010) 6/7, 7/12, 8/9, 10/11, 11/8, 12/6.  R70 CCSE Courses Starting (2010) 8/16.
2. CPUG CON 2010 EUROPE, the User Conference in Switzerland, September 20th-22nd, 2010!
3. Join Our CPUG Groups On LinkedIn and Facebook.  See Our Channel on YouTube.


Go Back   CPUG: The Check Point User Group > Check Point Firewall-1/VPN-1 And Related Products > NAT (Network Address Translation)
R70 completely mangling NAT troubleshooting R70 completely mangling NAT troubleshooting
Register Projects FAQ Members List Social Groups Calendar Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old 2010-07-22
Junior Member
  
Join Date: 2006-04-20
Posts: 10
Rep Power: 0
Pneuma has an average reputation (10+)
Default R70 completely mangling NAT troubleshooting
I have noticed on our R70 FW1 we are no longer seeing the NAT during troubleshooting with fw monitor.
I can see the NAT in Tracker and I can see it on the remote host, but I just do not see it during traffic analysis any longer, ie. all I see is the private IP addresses, as per:

[fw_0] eth6:i[109]: 10.2.4.25 -> 196.1.1.1 (TCP) len=109 id=16270
TCP: 80 -> 50946 ...PA. seq=91b22ed5 ack=d2da1e71
[fw_0] eth6:I[109]: 10.2.4.25 -> 196.1.1.1 (TCP) len=109 id=17845
TCP: 80 -> 50946 ...PA. seq=91b22ed5 ack=d2da1e71
[fw_0] eth5:o[109]: 10.2.4.25 -> 196.1.1.1 (TCP) len=109 id=17845
TCP: 80 -> 50946 ...PA. seq=91b22ed5 ack=d2da1e71
[fw_0] eth5:O[109]: 10.2.4.25 -> 196.1.1.1 (TCP) len=109 id=17845
TCP: 80 -> 50946 ...PA. seq=91b22ed5 ack=d2da1e71

Whilst on an older machine, VSX R65 in this case, we get the following which is clear and easy to interpret as it includes the proper NAT taking place:
eth6:i[40]: 10.15.1.2 -> 196.1.1.1 (TCP) len=40 id=56948
TCP: 80 -> 50940 ..R.A. seq=00000000 ack=a3cb30f1
eth6:I[40]: 10.15.1.2 -> 196.1.1.1 (TCP) len=40 id=56948
TCP: 80 -> 50940 ..R.A. seq=00000000 ack=a3cb30f1
wrp384:o[40]: 10.15.1.2 -> 196.1.1.1 (TCP) len=40 id=56948
TCP: 80 -> 50940 ..R.A. seq=00000000 ack=a3cb30f1
wrp384:O[40]: 196.28.84.130 -> 196.1.1.1 (TCP) len=40 id=56948
TCP: 80 -> 50940 ..R.A. seq=00000000 ack=a3cb30f1

This occurs both with manual and automatic NATs. I see that there is now a "[fw_0]" appended to the output, so I am assuming that there was an update of the tool.

Does anyone know of a way to force it to show NATs, I hope there is some sort of option flag perhaps, as this really impacts on troubleshooting.

~~Pneuma
Last edited by Pneuma; 2010-07-22 at 01:26. Reason: All CR removed on original
Reply With Quote
  #2 (permalink)  
Old 2010-07-22
Senior Member
  
Join Date: 2008-07-31
Location: Netherlands, Europe
Posts: 705
Rep Power: 3
msjouw has an average reputation (10+)
Default Re: R70 completely mangling NAT troubleshooting
When you run a second SSH session to your gateway running fw monitor and issue the command fw ctl chain
This will show the processes in the chain and where fw monitor is inserted, with the -pO 999 you can make sure the last outboud is at the end of the chain.
__________________
Regards, Maarten.
P1 R65.4 IPSO SPLAT IOS
Last edited by msjouw; 2010-07-22 at 02:35.
Reply With Quote
  #3 (permalink)  
Old 2010-07-22
Junior Member
  
Join Date: 2006-04-20
Posts: 10
Rep Power: 0
Pneuma has an average reputation (10+)
Default Re: R70 completely mangling NAT troubleshooting
Thanks Maarten,

I have checked on the fw ctl's outbound chain, and NAT is sequence 3, the fwmonitor is seq 16, tcpt outbound is seq 15, so fw monitor *should* be picking up the chain after the NAT.

I did use the "-pO 999" flag, and it definitely stuck fwmonitor at the end, but it appears to be completely ineffective:

[fw_0] eth6:i3 (vpn decrypt)[40]: 10.1.1.1 -> 196.1.1.1 (TCP) len=40 id=8170
TCP: 1835 -> 5040 ....A. seq=91b4b392 ack=d2dbc151
[fw_0] eth6:I18 (fw SCV inbound)[40]: 10.1.1.1 -> 196.1.1.1 (TCP) len=40 id=19442
TCP: 1835 -> 5040 ....A. seq=91b4b392 ack=d2dbc151
[fw_0] eth5:o2 (vpn nat outbound)[40]: 10.1.1.1 -> 196.1.1.1 (TCP) len=40 id=19442
TCP: 1835 -> 5040 ....A. seq=91b4b392 ack=d2dbc151
[fw_0] eth5:O19 (Chain End)[40]: 10.1.1.1 -> 196.1.1.1 (TCP) len=40 id=19442
TCP: 1835 -> 5040 ....A. seq=91b4b392 ack=d2dbc151

This is very strange, it really is a pity that checkpoint didn't include any of this in the release notes for R70, as it seems the fundemental workings of fw monitor have been changed some how. The output of "fw monitor -?" is the same on R65 and this R70, so either there is no new flag, or the developers forgot to change the output of the help flag.

I should mention I am using Check Point VPN-1(TM) & FireWall-1(R) R70 - Build 143, I will schedule to upgrade to the new R71 HFA 1 in the next few weeks, not sure if this issue exists in R71.10.

~~Pneuma
Last edited by Pneuma; 2010-07-22 at 04:27.
Reply With Quote
  #4 (permalink)  
Old 2010-07-22
Senior Member
  
Join Date: 2008-07-31
Location: Netherlands, Europe
Posts: 705
Rep Power: 3
msjouw has an average reputation (10+)
Default Re: R70 completely mangling NAT troubleshooting
Pneuma,

We're not running 7x jet and I can say we have seen his behaviour in some of the R65 gateways as well...
You can set the different steps iIoO all with a -px value flag so these are valid:
-pi 1 -pI 999 -po 1 -pO 999
Also the processname (the short in brackets name) can be used to position fw monitor, use a + / - to set the before / behind the indicated process:
-pI -vpn_pol

Hope this helps a bit in further testing.
__________________
Regards, Maarten.
P1 R65.4 IPSO SPLAT IOS
Reply With Quote
  #5 (permalink)  
Old 2010-07-22
Senior Member
  
Join Date: 2006-01-25
Posts: 1,384
Rep Power: 6
melipla has an average reputation (10+)
Default Re: R70 completely mangling NAT troubleshooting
Quote:
Originally Posted by msjouw View Post
-pi 1 -pI 999 -po 1 -pO 999
Why not just use the "-p all" command?


Quote:
Originally Posted by Pneuma View Post
[fw_0] eth6:i3 (vpn decrypt)[40]: 10.1.1.1 -> 196.1.1.1 (TCP) len=40 id=8170
TCP: 1835 -> 5040 ....A. seq=91b4b392 ack=d2dbc151
[fw_0] eth6:I18 (fw SCV inbound)[40]: 10.1.1.1 -> 196.1.1.1 (TCP) len=40 id=19442
TCP: 1835 -> 5040 ....A. seq=91b4b392 ack=d2dbc151
[fw_0] eth5:o2 (vpn nat outbound)[40]: 10.1.1.1 -> 196.1.1.1 (TCP) len=40 id=19442
TCP: 1835 -> 5040 ....A. seq=91b4b392 ack=d2dbc151
[fw_0] eth5:O19 (Chain End)[40]: 10.1.1.1 -> 196.1.1.1 (TCP) len=40 id=19442
TCP: 1835 -> 5040 ....A. seq=91b4b392 ack=d2dbc151
To me, according to that fw monitor the packet is not being NATed. When I was trying to troubleshoot why all my R70 gateways stopped doing NAT after I had upgraded to R70 and was pushing policy for the first time, support told me never to trust Tracker in regard to NAT. He was very adamant about the fact that you have to do a fw monitor to really see if NAT is taking place. My question to you, is Smartview Tracker right or is the fw monitor right?


For what it's worth, I see my R70.30+hotfixes gateway is showing NAT within my fw monitor:

Quote:
[fw_2] eth2:i10 (fw VM inbound )[60]: 10.1.1.11 -> 72.14.204.103 (ICMP) len=60 id=12614
ICMP: type=8 code=0 echo request id=1 seq=68
[fw_2] eth2:I11 (wire VM inbound )[60]: 10.1.1.11 -> 72.14.204.103 (ICMP) len=60 id=12614
ICMP: type=8 code=0 echo request id=1 seq=68
[fw_2] eth2:I12 (vpn policy inbound)[60]: 10.1.1.11 -> 72.14.204.103 (ICMP) len=60 id=12614
ICMP: type=8 code=0 echo request id=1 seq=68
[fw_2] eth2:I13 (SecureXL inbound)[60]: 10.1.1.11 -> 72.14.204.103 (ICMP) len=60 id=12614
ICMP: type=8 code=0 echo request id=1 seq=68
[fw_2] eth2:I14 (fw SCV inbound)[60]: 10.1.1.11 -> 72.14.204.103 (ICMP) len=60 id=12614
ICMP: type=8 code=0 echo request id=1 seq=68
[fw_2] eth2:I15 (passive streaming (in))[60]: 10.1.1.11 -> 72.14.204.103 (ICMP) len=60 id=12614
ICMP: type=8 code=0 echo request id=1 seq=68
[fw_2] eth2:I16 (TCP streaming (in))[60]: 10.1.1.11 -> 72.14.204.103 (ICMP) len=60 id=12614
ICMP: type=8 code=0 echo request id=1 seq=68
[fw_2] eth2:I17 (IP Options Restore (in))[60]: 10.1.1.11 -> 72.14.204.103 (ICMP) len=60 id=12614
ICMP: type=8 code=0 echo request id=1 seq=68
[fw_2] eth2.28:I18 (HA Forwarding)[60]: 10.1.1.11 -> 72.14.204.103 (ICMP) len=60 id=12614
ICMP: type=8 code=0 echo request id=1 seq=68
[fw_2] eth2.28:I19 (Chain End)[60]: 10.1.1.11 -> 72.14.204.103 (ICMP) len=60 id=12614
ICMP: type=8 code=0 echo request id=1 seq=68
[fw_2] eth0:o0 (IP Options Strip (out))[60]: 10.1.1.11 -> 72.14.204.103 (ICMP) len=60 id=12614
ICMP: type=8 code=0 echo request id=1 seq=68
[fw_2] eth0:o1 (vpn multik forward out)[60]: 10.1.1.11 -> 72.14.204.103 (ICMP) len=60 id=12614
ICMP: type=8 code=0 echo request id=1 seq=68
[fw_2] eth0:o2 (vpn nat outbound)[60]: 10.1.1.11 -> 72.14.204.103 (ICMP) len=60 id=12614
ICMP: type=8 code=0 echo request id=1 seq=68
[fw_2] eth0:o3 (TCP streaming (out))[60]: 10.1.1.11 -> 72.14.204.103 (ICMP) len=60 id=12614
ICMP: type=8 code=0 echo request id=1 seq=68
[fw_2] eth0:o4 (passive streaming (out))[60]: 10.1.1.11 -> 72.14.204.103 (ICMP) len=60 id=12614
ICMP: type=8 code=0 echo request id=1 seq=68
[fw_2] eth0:o5 (vpn tagging outbound)[60]: 10.1.1.11 -> 72.14.204.103 (ICMP) len=60 id=12614
ICMP: type=8 code=0 echo request id=1 seq=68
[fw_2] eth0:o6 (Stateless verifications (out))[60]: 10.1.1.11 -> 72.14.204.103 (ICMP) len=60 id=12614
ICMP: type=8 code=0 echo request id=1 seq=68
[fw_2] eth0:o7 (fw VM outbound)[60]: 10.1.1.11 -> 72.14.204.103 (ICMP) len=60 id=12614
ICMP: type=8 code=0 echo request id=1 seq=68
[fw_2] eth0:O8 (wire VM outbound )[60]: 4.2.2.2 -> 72.14.204.103 (ICMP) len=60 id=12614
ICMP: type=8 code=0 echo request id=48480 seq=68
[fw_2] eth0:O9 (vpn policy outbound)[60]: 4.2.2.2 -> 72.14.204.103 (ICMP) len=60 id=12614
ICMP: type=8 code=0 echo request id=48480 seq=68
[fw_2] eth0:O10 (SecureXL outbound)[60]: 4.2.2.2 -> 72.14.204.103 (ICMP) len=60 id=12614
ICMP: type=8 code=0 echo request id=48480 seq=68
[fw_2] eth0:O11 (l2tp outbound)[60]: 4.2.2.2 -> 72.14.204.103 (ICMP) len=60 id=12614
ICMP: type=8 code=0 echo request id=48480 seq=68
[fw_2] eth0:O12 (vpn encrypt)[60]: 4.2.2.2 -> 72.14.204.103 (ICMP) len=60 id=12614
ICMP: type=8 code=0 echo request id=48480 seq=68
[fw_2] eth0:O13 (tcpt outbound)[60]: 4.2.2.2 -> 72.14.204.103 (ICMP) len=60 id=12614
ICMP: type=8 code=0 echo request id=48480 seq=68
[fw_2] eth0:O14 (TCP streaming post VM)[60]: 4.2.2.2 -> 72.14.204.103 (ICMP) len=60 id=12614
ICMP: type=8 code=0 echo request id=48480 seq=68
[fw_2] eth0:O15 (IP Options Restore (out))[60]: 4.2.2.2 -> 72.14.204.103 (ICMP) len=60 id=12614
ICMP: type=8 code=0 echo request id=48480 seq=68
[fw_2] eth0:O16 (Chain End)[60]: 4.2.2.2 -> 72.14.204.103 (ICMP) len=60 id=12614
ICMP: type=8 code=0 echo request id=48480 seq=68
__________________
Its all in the documentation.
Reply With Quote
Reply

« Previous Thread | Next Thread »
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes
Linear Mode Linear Mode

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
BB code is On
Smilies are Off
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


All times are GMT -7. The time now is 15:44.

Contact Us - CPUG Home Page - Archive - Top

Powered by vBulletin® Version 3.8.5
Copyright ©2000 - 2010, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.5.1