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?
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
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
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.
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
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1732 | |
1106 | |
752 | |
447 | |
240 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.