>>> On 2/21/2008 at 8:24 AM, fwguru <[EMAIL PROTECTED]> wrote: [snip]
> I don't know, there may be something to > investigate there, especially after reading Crist's post. > > TCP dump is completely fw kernel independent, whereas fw monitor positions > itself in the fw inspection chain (in fact, becomes a module in the chain). > Try putting fw monitor up the chain. With fw monitor running, start another > terminal (like CTRL+F2) and type 'fw ctl chain' to see where fw monitor is > positioned (typically position 4 or 5 in the chain). Then you can run 'fw > monitor -pi 0 | grep <ip>' or 'fw monitor -pi 1 | grep <ip>' to position it > at or near the top. Do you see any output? > If you do, you can also run 'fw monitor -p all | grep <ip>'. The output > will show every kernel chain name as it passes thru it. That may be able to > isolate where the packet is being lost in the chain. Since this has come up, I wanted to see if anyone knew the real deal here. First, off what is the deal with "fw monitor" and established TCP connections? For example, I run an SSH session (over a non- standard port, but it doesn't matter) to a remote host through my R65 SPlat firewall. This is ALL I see in fw monitor, [EMAIL PROTECTED] ~]# fw monitor -e 'accept host(24.6.170.239);' monitor: getting filter (from command line) monitor: compiling monitorfilter: Compiled OK. monitor: loading monitor: monitoring (control-C to stop) eth1:i[48]: 207.88.153.67 -> 24.6.170.239 (TCP) len=48 id=26830 TCP: 1692 -> 22022 .S.... seq=f1d14e4c ack=00000000 eth1:I[48]: 207.88.153.67 -> 24.6.170.239 (TCP) len=48 id=26830 TCP: 1692 -> 22022 .S.... seq=f1d14e4c ack=00000000 eth0:o[48]: 207.88.153.67 -> 24.6.170.239 (TCP) len=48 id=26830 TCP: 1692 -> 22022 .S.... seq=f1d14e4c ack=00000000 eth0:O[48]: 207.88.153.67 -> 24.6.170.239 (TCP) len=48 id=26830 TCP: 1692 -> 22022 .S.... seq=f1d14e4c ack=00000000 eth0:i[48]: 24.6.170.239 -> 207.88.153.67 (TCP) len=48 id=10075 TCP: 22022 -> 1692 .S..A. seq=729e2892 ack=f1d14e4d eth0:I[48]: 24.6.170.239 -> 207.88.153.67 (TCP) len=48 id=10075 TCP: 22022 -> 1692 .S..A. seq=729e2892 ack=f1d14e4d eth1:o[48]: 24.6.170.239 -> 207.88.153.67 (TCP) len=48 id=10075 TCP: 22022 -> 1692 .S..A. seq=729e2892 ack=f1d14e4d eth1:O[48]: 24.6.170.239 -> 207.88.153.67 (TCP) len=48 id=10075 TCP: 22022 -> 1692 .S..A. seq=729e2892 ack=f1d14e4d eth1:i[40]: 207.88.153.67 -> 24.6.170.239 (TCP) len=40 id=26843 TCP: 1692 -> 22022 ....A. seq=f1d14e4d ack=729e2893 eth1:I[40]: 207.88.153.67 -> 24.6.170.239 (TCP) len=40 id=26843 TCP: 1692 -> 22022 ....A. seq=f1d14e4d ack=729e2893 eth0:o[40]: 207.88.153.67 -> 24.6.170.239 (TCP) len=40 id=26843 TCP: 1692 -> 22022 ....A. seq=f1d14e4d ack=729e2893 eth0:O[40]: 207.88.153.67 -> 24.6.170.239 (TCP) len=40 id=26843 TCP: 1692 -> 22022 ....A. seq=f1d14e4d ack=729e2893 eth0:i[81]: 24.6.170.239 -> 207.88.153.67 (TCP) len=81 id=10076 TCP: 22022 -> 1692 ...PA. seq=729e2893 ack=f1d14e4d eth0:I[81]: 24.6.170.239 -> 207.88.153.67 (TCP) len=81 id=10076 TCP: 22022 -> 1692 ...PA. seq=729e2893 ack=f1d14e4d eth1:o[81]: 24.6.170.239 -> 207.88.153.67 (TCP) len=81 id=10076 TCP: 22022 -> 1692 ...PA. seq=729e2893 ack=f1d14e4d eth1:O[81]: 24.6.170.239 -> 207.88.153.67 (TCP) len=81 id=10076 TCP: 22022 -> 1692 ...PA. seq=729e2893 ack=f1d14e4d eth1:i[60]: 207.88.153.67 -> 24.6.170.239 (TCP) len=60 id=26895 TCP: 1692 -> 22022 ...PA. seq=f1d14e4d ack=729e28bc eth1:I[60]: 207.88.153.67 -> 24.6.170.239 (TCP) len=60 id=26895 TCP: 1692 -> 22022 ...PA. seq=f1d14e4d ack=729e28bc eth0:o[60]: 207.88.153.67 -> 24.6.170.239 (TCP) len=60 id=26895 TCP: 1692 -> 22022 ...PA. seq=f1d14e4d ack=729e28bc eth0:O[60]: 207.88.153.67 -> 24.6.170.239 (TCP) len=60 id=26895 TCP: 1692 -> 22022 ...PA. seq=f1d14e4d ack=729e28bc monitor: caught sig 2 monitor: unloading Now, a couple of things. Where is the rest of the connection? All we see here is the three-way handshake and the first packets containing application data going each way. I was transferring a lot of data after this and finally closed the connection before interrupting the "fw monitor," but none of that shows up. Also, this traffic is being NAT on the way out. Not that you can tell from this output. OK. Things are weird with "fw monitor." Now let's look at tcpdump on the external interface for the same thing (not the exact same connection, but running the same test), # tcpdump -ni eth0 host 24.6.170.239 tcpdump: listening on eth0 11:44:33.273754 207.88.153.67.1802 > 24.6.170.239.22022: S 1363016155:1363016155(0) win 65535 <mss 1260,nop,nop,sackOK> (DF) 11:44:33.288957 24.6.170.239.22022 > 207.88.153.67.1802: S 3111754524:3111754524(0) ack 1363016156 win 65535 <mss 1460,nop,nop,sackOK> (DF) [tos 0x4] 11:44:33.291850 207.88.153.67.1802 > 24.6.170.239.22022: . ack 1 win 65535 (DF) 11:44:33.315573 24.6.170.239.22022 > 207.88.153.67.1802: P 1:42(41) ack 1 win 65535 (DF) [tos 0x4] 11:44:33.322727 207.88.153.67.1802 > 24.6.170.239.22022: P 1:21(20) ack 42 win 65494 (DF) 11:44:33.347350 24.6.170.239.22022 > 207.88.153.67.1802: P 42:642(600) ack 21 win 65535 (DF) [tos 0x4] 11:44:33.349760 206.220.220.206.34662 > 24.6.170.239.22022: P 1363016176:1363016928(752) ack 3111755166 win 64894 (DF) 11:44:33.462223 24.6.170.239.22022 > 207.88.153.67.1802: . ack 773 win 65535 (DF) [tos 0x4] 11:44:33.463892 206.220.220.206.34662 > 24.6.170.239.22022: P 752:776(24) ack 1 win 64894 (DF) 11:44:33.497710 24.6.170.239.22022 > 207.88.153.67.1802: P 642:794(152) ack 797 win 65535 (DF) [tos 0x4] 11:44:33.509427 206.220.220.206.34662 > 24.6.170.239.22022: P 776:920(144) ack 153 win 64742 (DF) [snip] 11:44:51.338730 206.220.220.206.34662 > 24.6.170.239.22022: F 3352:3352(0) ack 2297 win 65311 (DF) 11:44:51.355969 24.6.170.239.22022 > 207.88.153.67.1802: . ack 3374 win 65535 (DF) [tos 0x4] 11:44:51.355999 24.6.170.239.22022 > 207.88.153.67.1802: F 2938:2938(0) ack 3374 win 65535 (DF) [tos 0x4] 11:44:51.357537 206.220.220.206.34662 > 24.6.170.239.22022: . ack 2298 win 65311 (DF) Tcpdump gives me all of the packets, but uh, there are some odd things going on here. Notice during the TCP handshake and the first application data, we see the un-NATed 207.88.153.67 address. But then for the rest of the connection we see 206.220.220.206 as the source for the client, which is the NAT address, but we always see the internal unNATed address in the traffic back from the server. Again, this all works. In reality, all of the traffic going out of the external interface is being properly NATed. That 207.88.153.67 address is never actually seen outside the firewall. It just doesn't look that way in the "fw monitor" and tcpdump data. This is not specific to this host or this service. It's every TCP connection I've ever cared to watch on this SPlat firewall. Is this a bug? A problem with my installation? Or is this behavior expected and documented somewhere? It makes debugging hard. Luckily, I do have a completely independent system outside of the firewall that I can use for captures, so that can completely replace tcpdump for the most part, but "fw monitor" (potentially) has some capabilities that capturing at interfaces just does not make up for. B¼information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact [EMAIL PROTECTED] ================================================= To set vacation, Out-Of-Office, or away messages, send an email to [EMAIL PROTECTED] in the BODY of the email add: set fw-1-mailinglist nomail ================================================= To unsubscribe from this mailing list, please see the instructions at http://www.checkpoint.com/services/mailing.html ================================================= If you have any questions on how to change your subscription options, email [EMAIL PROTECTED] =================================================
