H.323 issue and forced deep packet inspection

[Srdjan_B]

Hello,

we have a customer using H.323 over Remote Access tunnel (using SoftPhone app). The setup was working fine before migration of gateways from R80.20/OpenServer to R80.40/CP6400 appliances. Original setup was using built-in H323 service and it was working fine with R80.20.

Troubleshooting is showing that gateway is always doing deep packet inspection and replacing IP address of VoIP board with its own IP (cluster IP). As a troubleshooting step, we created generic tcp1720 and udp1719 services, without specifying protocol and used them in the rule. Troubleshooting rule is being matched, but logs are showing that H323 service is being used and not our generic tcp1720 service. Packet capture also shows that IP address is still being replaced even after we've changed the rule to use generic services (without protocol definition).

How can we force GW not to do any H.323 processing and not to replace anything inside the packet? 

GWs are running R80.40 with JHF T118, it is HA cluster, just a regular SG (not VSX). TAC SR has been opened for three weeks, but not much progress so far. Any help is appreciated.

Thank you.

[G_W_Albrecht]

SecureXL off was tried ?

[Srdjan_B]

Yes, tried with SecureXL off, tried with IPS off, also tried 

fw ctl fast_accel add <relevant traffic here>

And also tried sk104786

Nothing helped. The issue is that call is established, but audio is one-way only (works from office to RA client, does not work from RA client to office).

Thanks.

[the_rock]

I could be wrong when I say this, but I know in the past, usually you could achieve something like this by choosing protocol 'NONE' in service properties. Dont know if there is better way now days in R80.xx and R81...

[Srdjan_B]

Thank you, this is exactly what we've done, but GW is changing the content of the packet regardless. It seems, it is ignoring our custom service and forcing built-in H323 service.

[the_rock]

Can you just ensure that actual default h323 service is not used somewhere else maybe?

[Srdjan_B]

When we check the logs, it shows that log entry has matched the rule with custom service (with no protocol defined). But it matched built-in service, not our custom service.

There is only one more rule which is using built-in service, but it is disabled.

[the_rock]

K, got it, I see what you are saying...honestly, that does not sound like an intended behavior, so I would personally engage TAC to see if they can spot anything unusual.

[_Val_]

Second that. Please take this with TAC, @Srdjan_B 

[Srdjan_B]

Thank you, the SR has been opened for three weeks, it has been escalated too, but solution is still out of reach ☹️

Customer is considering going back to R80.20 😨

[the_rock]

Ok, I know this is a long shot, but I recall in the old days IPS being an issue with scenarios like this...have you tried disabling it at all to see if it makes a difference?

[_Val_]

please PM me the SR number, @Srdjan_B 

[Srdjan_B]

Using generic services tcp1720 and udp1719 (without defined protocol) in Network policy was not enough. The issue has been resolved by creating additional specific rule in Application policy using same generic tcp1720 and udp1719 services.

[the_rock]

Thanks for letting us know, but I have to say that is very odd it had to be done in the first place. Logically, it tells me me that something with those protocols is not working as intended.

[Srdjan_B]

Yes, I agree. I wanted to do few more tests, to get to the bottom of it. But once the test was successful, customer said "don't touch it anymore", and that was that. Thank you all for suggestions and help.

[the_rock]

Understood...definitely appreciate letting us know what the solution was.