Packet processing stops after chain module "fw post VM inbound"

[TomShanti]

Hi all,

I have an issue with a connection that should be NATed.

The NAT that should be applied on a connection between 10.1.1.82 and 10.1.1.154 does not work:

fw monitor -p all -e "accept(host(10.1.1.154));"

[vs_0][fw_2] bond1.280:I16 (fw post VM inbound )[44]: 10.1.1.82 -> 10.1.1.154 (50) len=104 id=5411

A working connection shows this as next step:

[vs_0][fw_3] bond1.280:I16 (fw post VM inbound )[44]: 10.1.1.82 -> 172.1.1.7 (50) len=152 id=5014
[vs_0][fw_3] bond1.280:I17 (RTM packet in)[44]: 10.1.1.82 -> 84.1.1.93 (50) len=152 id=5014

So it looks like in the first scenario the processing stopped at chain module "fw post VM inbound".

It was working before but since we reapplied multi-queuing config on this cluster it stopped working.

Any idea why ?

Thanks Thomas

PS: Running R81.10

[PhoneBoy]

Most likely, you're going to need to enable kernel debugs to see where the traffic goes (and why).
Might need the TAC to help you figure out the correct debug flags to use here (and fix the underlying problem, of course): https://support.checkpoint.com/results/sk/sk98799 

[Timothy_Hall]

Try running fw ctl zdebug drop while the traffic is not working, this will show you all live drops by any Check Point code along with a reason, even if it is not being logged.

[the_rock]

I would definitely do zdebug, to start with. Just to be 100% sure, can you remove multi q config and see if it works again?

Andy

[AmirArama]

1. it's better to use: fw monitor -p all -F "0,0,10.1.1.154,0,0"

2. i also suggest to use 'fw ctl zdebug + drop" | grep 10.1.1.154

[Timothy_Hall]

@TomShanti if you are going to attempt to run a fw monitor -F and a fw ctl zdebug + drop simultaneously, be aware that you must do so in a particular order to keep the two commands from stepping on each other and causing problematic results.  See here:  Max Capture Update 2: Debug Filter Battle -- fw monitor -F vs. fw ctl zdebug + drop