1. Is the packet arriving on the SRX?
The first thing that we need to make sure is that the traffic is arriving on the SRX itself. We should be able to see the traffic by just viewing the output of the debug itself. This may not be the case if stateless firewall filters are being used, which may drop the packets before they are processed by the flow engine. If you don’t see the traffic arriving on the SRX, you should check the routing table of the peer device, as well as checking to see if the peer device has an ARP entry for the IP address we are trying to reach. This is particularly important if you are using static NAT, as Proxy ARP MAY be required.
2. Is the packet being blocked by a Screen?
If a packet is an invalid packet, and screens are enabled on the source zone, it may be dropped. An example would be a packet that has a SYN, ACK, and FIN bits set.
3. Is the packet destined for the firewall itself?
This is most common with management traffic such as telnet, ssh, and SNMP, but also for protocol traffic such as BGP, OSPF, RIP, and PIM. In this case, we must make sure that these respective services are running on that interface. In JUNOS, this is configured at either the zone or interface level under [edit security zones security-zone <zone> hostinbound- traffic] if this is not configured then the firewall will drop the packet.
4. Is the session asymmetric?
Stateful SYN checking is on by default, and if the firewall does not see the SYN packet, it will drop the subsequent packets and the session will not establish. This should be clear from the debug. In this situation you must either ensure that the SRX is in the initial packet path so that it sees the SYN packet (recommended!) or turn off SYN checking. If the SRX cannot see both directions of the flow then some features such as IDP may not be able to work at the full capacity.
5. Is the packet from an existing session?
If the packet matches an existing session then we will not include all debugging information in that output, just some basics, and we refer it to the session ID to cross reference. You can still examine the session table to track this session with the “show security flow session” command.
6. Is the packet arriving on the correct interface/zone?
When looking at the debug output you should be able to tell what interface the packet has arrived on, and subsequently, what the source zone is. This is important for policy lookup, and if it is not matched properly, then most likely a problem will occur.
7. Is the appropriate route / L2 forwarding path being selected?
Depending on if you are using Layer 3 more or Transparent mode, we will need to ensure that the appropriate forwarding decision is chosen. With layer 3 mode, the firewall will do a route lookup based on the destination of the route, which will determine what the egress interface will be (which also determines the to-zone,) if the device is in transparent mode, the device will either do an ARP, or will broadcast the packet out all interfaces (except that from which it came) in the same bridging domain. If the wrong route is set (in transparent mode, the forwarding decision should happen without intervention, unless other mechanisms such as Dynamic ARP inspection or L2 Broadcast filtering in place to block this) then we may chose the wrong outbound interface to send the traffic out, as well as the wrong NAT decision. Currently, we do not give a route-id in the output of the debug like we did in ScreenOS. This will probably change in the future. You may need to do a route lookup with the “show route <prefix>” command to make sure that the correct route is chosen and that the appropriate outbound interface and next-hop is selected. In transparent mode, you can check the L2 forwarding table with the “show arp” and “show ethernetswitching table” if using the branch SRX, while the High End SRX use a different command “show l2- learning interface” to see what entries are known by the system.
8. Is the correct policy being selected by the firewall?
Now that we have determined what the appropriate egress interface / zone are supposed to be, assuming that those are correct, we need to make sure the correct firewall policy is being selected by the firewall. Today that number is referenced in the debug logs as “policy <#>” and as shown in the debug above, we can run the “show security policies | find “Index\: <#>” command to make sure that the policy is correct. If it is not the correct policy, you will need to take a look at the source/destination address and service. It is often prudent to look into the address and service objects themselves to make sure that they are really matching what you are looking for, and not just the names of the address objects themselves as shown in the policy. For instance, we could name an object 220.127.116.11/24, but the actual address that it matches if we omit the subnet mask wouldbe 18.104.22.168/32. Just by looking at the object name we may have it wrong. Also, see the next step about NAT configuration as it may impact your policy.
9. Is the correct NAT being applied by the policy?
Today we have some improvements that are going to be put into NAT debugging, but for now, the best thing to check is to look at the output of the debug and see what translation takes place. Is it what you expect (e.g. is the source translated or not translated as expected? Is the destination translated or not translated as expected?) Remember that static translations happen before policy lookup, while source and destination translations occur AFTER policy lookup, so you need to make sure that you have factored this in when configuring your policy. If the wrong action is being taken on your policy, you may want to review the rulebase configuration to visually inspect the match and action criteria. There can be many NAT rulebases depending on the configuration, so be sure to take that into account.
10. Does the debug show that the packet is being processed by “Application Services” or is destined to a VPN tunnel?
If the packet is being processed by application services then further debugging may be necessary, for instance, if you have IDP enabled on that policy, and the IDP detects that packet as malicious, it may drop it based upon policy (so even though the FW flow looked OK, it could still be dropped based upon policy) same is true for other UTM features, so you need to keep this in mind. If the packet is destined to a tunnel, then you should see this output. If a VPN is referenced, the VPN must be active, or else the packet will not have anywhere to go.
If you feel this article helped you to get some learning, please support by clicking below.