Problems with Asterisk server behind firewall

[nsumner]

I suspect somebody has been down this road before. I setup a new asterisk server behind the firewall. It has an internal IP, and it has a VIP assigned to it. The relevant rules are (for now for testing). piaf=192.168.0.1 (for example). PIAF (VIP) external IP 91.117.108.79 (for example) internal ip 192.168.0.1 Internal to Wan piaf allow all to all. Wan to Internal all to PIAF allow all. I still can' t get any external clients working. Does anybody have any ideas?

[red_adair]

The short story is - you have to use the " SIP ALG" to work. Basically create a FW-rule with udp/5060 (SIP) passing through and apply a protection profile to this policy where, under the VoIP Section, you tick the SIP checkbox. I highly recommend that you also search this forum for SIP there have been many discussions around this. -R.

[nsumner]

I will do a search for SIP. I searched for asterisk and nothing much came up. In paticular I don' t care about internal phones. I tried that technique which did not work. I might also give Fortigate a call later. I setup a PBX at home using the exact same settings on the PBX side of things (okay the externip setting is obviously different but that is insignificant) and it works without any problems.

[nsumner]

Unfortunately still nothing I haven' t tried. I will post a solution when/if I find one.

[red_adair]

make sure you run something like a recent MR7 release. Also apply a SIP-enabled Protection-Profile to the policy vip:ext -> int. # diag sniff pack internal ' udp port 5060' and/or # diag sniff pack internal ' host <ip-of-pbx>' to see if at least this communication works (to PBX and reply from PBX) # diag sniff pack internal ' host <ip-of-pbx>' 3 gives you full packet trace. Dump this to a file and have it converted with fgt2eth.pl (check kc.forticare.com) to PCAP Format for post Analysis in Wireshark. Wireshark does have pretty nice SIP decoding. -R.

[nsumner]

red.adair Any more ideas. The packet sniffing is obviously useful but in this case is brining me to a dead end. The traffic is being eaten and not by any rule that I can determine.

[nsumner]

Well the plot thickens so to say. I have 2 VDOMs. The first is connected to the 2 WAN interfaces and simply passes all traffic into the internal VDOM. It actually does no NAT even. The reason for this config is that I am running BGP to 2 ISPs. I need the same public IP to map to one machine from both WAN1&2. The fortigate won' t allow you to do that it is too smart except in the case of BGP it is too smart for it' s own good:-) The solution Fortinet provided was running with 2 VDOMs... If I watch traffic coming into the external VDOM I can see the traffic coming in no problem. If I watch the traffic flowing between the VDOMs it is sorely missing! Let alone inside the root VDOM where it also obviously can' t be seen as it never gets there. The firewall policy on the BGP vdom is to allow ALL traffic from anywhere from either wan interface to the root VDOM and vice versa. In other words firewall policies should not be interfering at all. Does anybody have any suggestions!

[red_adair]

_what_ is eaten ? SIP or RTP or both ? Did you apply a Protectionprofile with SIP enabled to the inbound VIP rule ? Do you run a recent Version of MR7 (highly recommended when working with SIP) ? whenever you do NAT (and a VIP is NAT; DNAT) you must use a SIP-enabled Protection profile - otherwise the SIP Header is not changed. -R.

[nsumner]

red.adair It is eating SIP as for RTP who know we haven' t gotten there yet. You are missing it however I am not doing NAT at the point the traffic is being eaten! It doesn' t pass through a VDOM that only has public IP addresses assigned to any given interface! All it does is routing ruth 2 firewall rules just set to allow anything and everything. It' s purpose in life is to do BGP and that is it. I see the traffic come in but I don' t see it hit the other side. Here is a log (with IP addresses obfuscated). Logging on wan1 141.182197 91.208.x.x.5060 -> 216.235.152.230.5060: udp 647 141.364724 91.208.x.x.5060 -> 216.235.152.230.5060: udp 647 150.602570 192.115.22.9.29454 -> 91.208.x.x.5060: udp 554 151.111102 192.115.x.x.29454 -> 91.208.x.x.5060: udp 554 152.111112 192.115.x.x.29454 -> 91.208.x.x.5060: udp 554 154.110166 192.115.x.x.29454 -> 91.208.x.x.5060: udp 554 capturing on the inter-vdom link 0.173618 91.208.x.x.5060 -> 216.235.152.230.5060: udp 647 0.356034 91.208.x.x.5060 -> 216.235.152.230.5060: udp 647 Again this has NO NAT involved!

[player]

i had this issue with vdom-links and traffic that is not comming back, the trick is to use source nat on the policy that goes to the v-link. good luck