FW MONITOR
————
i – Preinbound, just where the packet is received on the interface. If you see only this then the packet is dropped by address spoofing or the access rule.
I – Postinbound, where the packet has gone across the incoming interface. If you don't see the the capture after this, you could infer that it's a routing issue.
For both i & I the interface is the incoming, where the packet enters the firewall.
o – Preoutbound, the place where the packet is received at the exit interface within the firewall. If this is the point beyond which the capture is not seen, then it turns it to be a NAT issue.
O- Postoutbound, If you see this then make yourself sure that the packet has left the firewall and the ACL, route and NAT all are correct.
TCPDUMP.
———
It captures at position i & O of firewall monitor, and you can be sure the traffic has left the firewall. It would show the return traffic as well.
This is same as the way you put captures in Cisco PIX/ASA.
So, which one you use ?
Consider you run tcpdump and see the incoming traffic but don't see the traffic leaving the exit interface. You can guess it's a routing or a NAT issue. But to make a sure shot without wasting time looking in routes or the NAT rules you could run fw monitor and know what the issue is.
Why TCPDUMP? simple, Easy to use, industry standard, aslo with layer 2 info such as ARP requests/replies as Nick said in his article Packet Captures on Secure Platform – Part 3
Why not TCPDUMP? In dealing with tcpdump on a firewall, you must really understand your network and choose the interface (-i ethX) wisely, or else you might completely miss the traffic that you are searching for. Packet Captures on Secure Platform – Part 1
What else did fw monitor show us that tcpdump did not? It shows us the routing. Let say that your ping was failing, but the SmartView Tracker logs showed it as being accepted. Packet Captures on Secure Platform – Part 2
No comments:
Post a Comment