Replacing a dual-wan Peplink unit with a dual wan Fortinet 100E firewall (5.4.11 iirc). Wan1 has a fibre connection (static ip) and Wan2 has a dsl connection (pppoe with static ip assigned via pppoe). lan to wan1 is just data traffic, servers, workstations etc dmz to wan2 is just sip voice traffic There are separate switches, cabling and data ports for the phones (cisco) vs the computers (hp and netgear). Most desk phones are older 79xx series boardroom conference phones are Polycom and the reception phone with sidecar is a Mitel. ALL fail with the Fortinet setup. Problem is this, when we swap out the PepLink for the Fortinet, we start having issues. This occurs in the same manner both before and after disabling the SIP helpers and the SIP ALGs on the Fortinet. Basically reboot a phone and you eventually get errors, can't make calls as it hasn't loaded it's firmware or config from the phone provider's SIP Proxy/Gateway. Sometimes a phone will seem to be booted up fine but you can't make calls even though you have dial tone. Swap the old firewall back in and everything works again. I've tested with my laptop on the dmz lan and internet access works fine once I allow all outbound traffic outbound. Normally the firewall rule only allows access to the netblock for the provider's SIP Proxies/Gateways. In both cases can ping and access the provider's netblock without issues. I've added the TFTP option to the Fortinet DHCP on the DMZ (normally option 66, but on Fortinet it's option 150). It points to the ip of the SIP Proxy. Packet capture from the Fortinet converted to wireshark shows the phones are attemping an FTP connection to the SIP Proxy and eventally the SIP Proxy says can't find/load the file. That's when I added the TFTP option to DHCP but no change in behaviour. SIP provider basically says they aren't doing anything special and it should work. Fortinet support says issue is with the SIP Provider. A couple other tests I haven't done yet 1) take a phone off voip network and see if it works on data network.
2) take a voip phone from our office (different provider using same software).
3) take voip phone from client's office and try it in one of our offices which also is running Fortinet gear.
4) sip provider willsetup a phone or ATA using his service so I can test behind our Fortinet's and then take onsite to the client to see what happens. Any other ideas?
After checking these forums I wonder if the TFTP helper might be implicated somehow.
I'd focus on the TFTP server option first. The option value needs to be entered in hex (you will have read about that). What if you configured the server's IP address on a test phone so that this wouldn't have to work? If the phone then can register, debug the DHCP option. If not, it's something else.
From what I've learned with telco equipment behind a FGT, the SIP helper is all you need - that is, it's not as bad or 'evil' as perceived sometimes. The ALG will only kick in if you define a VoIP profile and use it in the outgoing policy, so I'd ignore the ALG at the moment.
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 |
---|---|
1737 | |
1107 | |
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.