The packets from a source to a destination in one path and takes a different path when it returns

[A_KOUADIO]

When i initiate a trafic is drop or match another rule, so i need to create another rule for the return trafic.

 See the screenshot

[Chris_Atkinson]

Have you confirmed the routing is correct end-to-end and that anti-spoofing is set correctly?

Is there any NAT involved and could you please share a better/clearer screenshot?

[A_KOUADIO]

Routing is correct.

antispoofing is set correctly.

I will check the NAT.

Do you think that it is normal (correct) to have return trafic as new entry in log without nat the trafic ?

[Chris_Atkinson]

This screenshot appears different to the original, can you provide the more detailed log cards for both flows?

There is some suggestion here that's proxy is involved, are only some ports/redirected to the proxy and others NAT different?

[A_KOUADIO]

I didn't understand your message but the client has a proxy in his intranet.

[the_rock]

I would agree totally with what Chris said. 99% of the time, its either NAT, routing or anti-spoofing (or combination of all of them).

[A_KOUADIO]

Ok I will check the cpinfo file today to verify?

[G_W_Albrecht]

What will you check how in cpinfo ?

[A_KOUADIO]

As i said, I am currently looking for the cause of the asymmetric routing

[G_W_Albrecht]

But how to accomplish this in cpinfo ? Never heard of routing issues resolved by cpinfo analysis...

[A_KOUADIO]

I don't have access to the appliance, so i will analyze on my side the cpinfo file and after that i will contact the customer to have clear understanding of the issues.

[_Val_]

I do not think you will find all answers in the CPInfo. In most cases, asymmetric routing is caused by external factors. 

[G_W_Albrecht]

Great - which tool are you using ? Or do you search in the cpinfo text ?

[A_KOUADIO]

CheckPoint Diagnostics View

[the_rock]

Hey @A_KOUADIO ,

I think what @_Val_ and @G_W_Albrecht are saying is that its very unlikely you would find an answer as to why assymetric routing happens from cpinfo file review, as thats simply the config file from the firewall. Here is what I would run and examine carefully the output. So, just as an example, say the source is 10.10.10.10 and dst is 20.20.20.20, try commands like below:

fw monitor -e "accept host(10.10.10.10) and dst(20.20.20.20);"

fw monitor -e "accept host(20.20.20.20) and dst(10.10.10.10);"

fw minitor -e "accept host(10.10.10.10) or dst(20.20.20.20);"

Alternatively, you can also use below command. Idea is to filter for src IP, src port, dst IP, dst IP, protocol

fw monitor -F "10.10.10.10,0,20.20.20.20,0,0" -F "20.20.20.20,0,10.10.10.10,0,0"

I can also suggest a website my colleague made ages ago to help people with captures on different platforms (its very useful)

https://tcpdump101.com/#

Hope all this helps you.

Cheers,

Andy

[G_W_Albrecht]

Dropped by Access Rule Number 1225 ???

[A_KOUADIO]

Because the source port match another rule.

As I said previously, the return traffic is dissociated from the going trafic so it match another rule or drop by the cleanup rule.

[G_W_Albrecht]

I would not use 1225 rules - but that should not cause asymmetrical routing afaik...