Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Srdjan_B
Contributor

H.323 issue and forced deep packet inspection

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.

0 Kudos
15 Replies
G_W_Albrecht
Legend
Legend

SecureXL off was tried ?

CCSE CCTE SMB Specialist
Srdjan_B
Contributor

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.

0 Kudos
the_rock
Champion
Champion

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...

0 Kudos
Srdjan_B
Contributor

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.

0 Kudos
the_rock
Champion
Champion

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

0 Kudos
Srdjan_B
Contributor

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
Champion
Champion

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.

0 Kudos
_Val_
Admin
Admin

Second that. Please take this with TAC, @Srdjan_B 

Srdjan_B
Contributor

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 😨

0 Kudos
the_rock
Champion
Champion

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?

0 Kudos
_Val_
Admin
Admin

please PM me the SR number, @Srdjan_B 

0 Kudos
Srdjan_B
Contributor

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.

0 Kudos
the_rock
Champion
Champion

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
Contributor

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
Champion
Champion

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

0 Kudos