Skip to main content
bgourley
New Member
June 26, 2015
Question

UDP traffic issue in Site to Site VPN

  • June 26, 2015
  • 3 replies
  • 10327 views

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

emnoc
New Member
June 26, 2015

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

 

 

 

 

bgourley
bgourleyAuthor
New Member
June 26, 2015

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
New Member
April 24, 2018

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

Thought Leadership Security Summit. Outpace New Threats with AI - enhanced defense. Tuesday, Septmeber 15, 8:30 AM - 2:30 PM PT. The Golf Club at Newcastle, WA.
Virtual event | September 2026. SASE summit. The age of autonomous trust. Register here!