Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
bgourley
New Contributor

UDP traffic issue in Site to Site VPN

Setup: I've got a FG 40C with a VLAN that we have an IP PBX on. 192.168.81.0/24 On the other side of the VPN we have a Juniper SSG 20 with a subnet of 192.168.200.0/24. We've got a couple of SIP phones on the Juniper side that connect back to the IP PBX. This setup was created with the 40C at 5.2.2 and worked great for months. We made no changes on the Juniper, but upgraded the FW on the 40C to 5.2.3 and the phones can no longer register to the PBX. The tunnel is up and passes traffic. What I've done to troubleshoot: TCP, ICMP, and NTP seem to pass just fine since I can connect to web interfaces of varying equipment from both sides and make RDP connections through. In pulling packet captures from the IP PBX I can see the phones getting NTP info from the PBX, but I never see a SIP registration make it to the PBX. Using the packet sniffer from the FG I can see the sip traffic on the VPN Tunnel interface, but I never see it on the VLAN interface. I've tried recreating the policy between the two interfaces, ensuring that all services are passed with no luck. I've verified that routing info is correct on both devices. Has anyone else seen anything similar or have any ideas on further troubleshooting?

3 REPLIES 3
emnoc
Esteemed Contributor III

The diag debug flow command is your #1 best friend. I would 1st check that to see if ;

 

1: your siip registers are actually entering the tunnel

 

2: that you SIP-ALG is handling the SIP_REGISTER

 

3: and monitor any failed  SIP_REGISTERS that could be sent back to the  client

 

The diag debug flow command will also validate the fwpolicy-id that's being matched

 

e.g ( a typical diag I would do )

 

 

 

diag debug dis

diag debug reset

diag debug flow filter port 5060 ( or what whatever SIP_SIGNL port )

diag debug flow show console enable

diag debug flow trace start 1000

diag debug enable

 

After completion reset the diagnostics and disable it

 

Review the outcome for 1> routing and 2> any status 3> diag sys sip  commands will prove any ALG sessions status

 

 

 

 

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
bgourley
New Contributor

Ran the diag debug flow and pushed the output to a log file which I've annotated and attached to this. It looks like it may not be finding the policy to route the traffic? I'm not incredibly well versed in diag debug flow, so I'd appreciate the help in reading the output. We also are not running the SIP session helper in our config by design.

Edvard

Hi!

I understand, that the problem is pretty much too old and the author has found the resolution long ago already, so I post just to have the solution here. 

 

Delete the existing UDP sessions so that they are built fresh and been routed correctly. 

 

Here is a KB explaining how to display / filter / clear sessions. 

http://kb.fortinet.com/kb/documentLink.do?externalID=FD30042

 

Kind regards, 

Ed

Labels
Top Kudoed Authors