These NSFs are bizarre

[timor5000]

I would love to know how these things work. Trying to get Nortel to tell me or find doco on the inner workings of these switches is nigh on impossible

Troubleshooting a connection through these things is tough. Is tcpdump totally broken on these things?

For example if i run tcpdump -n -i <internal interface> host <my IP> and do the same on the external interface i'll see the SYN on the internal and nothing else. Alot of the time I just see nothing at all.

For my packet arriving on the internal interface I will not see the SYN ACK on any interface. Can anyone explain exactly how these accelerators handle connections? It's driving me crazy. btw this is being tested on a non production firewall so there's absolutely no load on it. buffer space should not come into play

tcpdump is tcpdump. it's linux. I would expect it to behave properly

anyone have any clues on how to get this to operate as expected? is it because of the switch architecture it behaves this way?

bizarre...

[Carsten]

I have almost no experience with tcpdump on a firewall, I prefer fw monitor, you should give it a try as well, because it is meant especially for firewall packet filtering and it is superior to tcpdump for this purpose.

http://www.cpug.org/check_point_reso...or_rev1_01.pdf

[timor5000]

I have almost no experience with tcpdump on a firewall, I prefer fw monitor, you should give it a try as well, because it is meant especially for firewall packet filtering and it is superior to tcpdump for this purpose.

http://www.cpug.org/check_point_reso...or_rev1_01.pdf

I use fw mon and it's a great tool for understanding how packets traverse the firewall and troubleshooting. The trouble is i like to have the all the info on one line so i can apply filters to it like grep and awk

fw monitor splits this line into 2 so you see src dst IP on the first line and ports on the second. fine i guess for dumping the output into a reader like wireshark but its crap for Real time troubleshooting

havent figured out how to get it into one line if it can even be done?

will have to play with INSPECT

[Sidney]

I would love to know how these things work. Trying to get Nortel to tell me or find doco on the inner workings of these switches is nigh on impossible

Troubleshooting a connection through these things is tough. Is tcpdump totally broken on these things?

For example if i run tcpdump -n -i <internal interface> host <my IP> and do the same on the external interface i'll see the SYN on the internal and nothing else. Alot of the time I just see nothing at all.

For my packet arriving on the internal interface I will not see the SYN ACK on any interface. Can anyone explain exactly how these accelerators handle connections? It's driving me crazy. btw this is being tested on a non production firewall so there's absolutely no load on it. buffer space should not come into play

tcpdump is tcpdump. it's linux. I would expect it to behave properly

anyone have any clues on how to get this to operate as expected? is it because of the switch architecture it behaves this way?

bizarre...

Hi,

Well the reason why I think tcpdump don't and actually can't work is that the accelerator part (the switch) is not running linux contrary to the director piece, it's based on asics. On the other hand fw monitor is "glued" to the Checkpoint kernel so it gathers its information from the director (bear in mind fw monitor limitations with SXL, the hardware based acceleration from the switch on ASF/NSF or ADP on Nokia and Xbeam X series).

My 2cents.

Sidney

[SuperMacs]

The NSF are accelerator architecture. The actual firewall part, the director, where you perform the capture. Will only see the start of the session. The rest of the packets are accelerated/bypassed via the external accelerators (6400/6600).
It is possible to turn off acceleration for specific services to enable you to do full packet capture on a session. This is a Checkpoint enabled functionality, but I do not have my notes at present.