I have a security rule to allow ip "A" to ssh to ip "B". I can see the traffic actually hitting the fw but it gets dropped with interzone-default. The test policy match also verifies that it matches the traffic.
IP "B" is actually the firewall. And IP "B" is nated like this: original packet source IP "C", original packet dest ip "A", translated packet source ip "B".
How can this happen? So the traffic hitting the firewall has an explicit allow rule but still missed.
IP "A" is on the other end of the IPSec tunnel and when this traffic comes, it successfully creates a child SA. Routing is also set up for IP "A"
Not applicable is because the firewall does not waste resources trying to identify it when it's already matched the deny rule.
Are you sure the rule is set up correctly? When NAT is involved, the security rule should be to the pre-NAT IP, but the post-NAT zone.
not-applicable is because the sesison is dropped, so the firewall doesn't care which application it is
In regards to NAT: you're connecting from A to B, but then have a NAT rule from C to A source B?
your nat rule is supposed to allign with the direction the session is being established in
so unless you forgot to mension bidirection is enabled, this will never work
but then you add that IP A is at the remote end of an IPSec tunnel, so the tunnel happens between D and B?
A will actually egress out of the tunnel interface, this should be a different zone than interface B. Did you account for this in the NAT rule?
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!