Hi,
This is a question of using Fortigate in the context of allowing in SIP traffic.
But then getting the firewall to dynamically open and close pinhole ports for RTP under AWS
To try and explain our setup first we have an AWS EC2 instance that ether receives phone calls or makes outgoing phone calls to a VoIP provider on the internet.
As part of this we want to make the setup PCI compliant and with PCI compliance ideally you don't want to just leave a bunch of ports open for outbound RTP all the time.
There is one problem though in that any traffic coming into an elastic / external IP under AWS is automatically statically 1:1 NAT'd to the internal IP after it arrives.
This creates something of a mismatch between the destination IP inside the Sip packet and the UDP destination IP address.
The end result of what we've tried so far:
This is where things go a bit wrong
The problem I think is similar to HNT or Hosted NAT Traversal, with that option though you need to use a virtual IP
and I think it only works when the firewall itself is directly on the internet,
But in this case the 1:1 NAT is happening from AWS before it reaches the firewall
For the Firewall rule there's not much to it
config firewall policy
edit 5
set name "SIP1_Inbound2"
set uuid eb34f308-6957-51ef-8f2e-967cbf524959
set srcintf "port1"
set dstintf "port2"
set action accept
set srcaddr "Gamma1" "Gamma2"
set dstaddr "IVR-SIP-IP-Internal"
set schedule "always"
set service "SIP"
set utm-status enable
set ssl-ssh-profile "certificate-inspection"
set voip-profile "IVR1"
set logtraffic all
next
end
For the voip profile
config voip profile
edit "IVR1"
config sip
set strict-register disable
set block-long-lines disable
set block-unknown disable
set open-via-pinhole enable
set log-violations enable
end
next
end
Gamma1 / Gamma2 are external IPs
IVR-SIP-IP-Internal is 10.40.15.156
The version of the firmware is the latest as its a fresh AWS instance for Fortigate
So far I've been digging through pdf links like this one without much of a result
https://fortinetweb.s3.amazonaws.com/docs.fortinet.com/v2/attachments/01b12c6d-1a17-11e9-9685-f8bc12...
To be clear I'm not trying to do any form of NAT at the Fortigate level
just trying to counteract the effects of AWS's 1:1 NAT when the packets come in for SIP so that the pinholes outbound for RTP are opened
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.
Hello @garlicbread ,
Have you taken any packet captures?
According to https://community.fortinet.com/t5/FortiGate/Technical-Tip-Disabling-VoIP-Inspection/ta-p/194131, what VoIP mode do you use?
For general troubleshooting, review https://community.fortinet.com/t5/FortiGate/Technical-Tip-SIP-useful-Commands/ta-p/195289
In configuration, have you check is RTP ports are configured or not? https://docs.fortinet.com/document/fortigate/6.2.0/new-features/784393/custom-sip-rtp-port-range-sup...
For clearing all sessions related to SIP, review https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-One-way-Audio-issue-in-VOIP-with-SIP...
Thanks,
Ronak Patel
Hello @garlicbread ,
Can we try to assign an Elastic IP to the FortiGate instance in AWS. This way, the external IP seen in the SIP packets will match the IP of the Fortigate and use it in VIP
I've uploaded our current config below
https://github.com/Local-Hecatron-BCH/IVRLogs/blob/master/03-09-2024-15-25/FortiGate-VM64-AWS_7-2_16...
And this is the debug output
https://github.com/Local-Hecatron-BCH/IVRLogs/blob/master/03-09-2024-15-25/debug_output.txt
The VOIP mode we're currently using is the default "proxy-based"
although I have also tried the older "kernel-helper-based" one as well without any luck
For the Debug output you can see it's trying to use the external IP embedded in the SIP packet to allow traffic through
ip sess 0x7f84d10cd000 vd 0 vrf 0 pinhole (nil) add UDP 3.9.196.238:0 -> 151.2.139.6:18185 ()
sip sess 0x7f84d10cd000 vd 0 vrf 0 pinhole (nil) add UDP 151.2.139.6:0 -> 3.9.196.238:23075 ()
sip sess 0x7f84d10cd000 vd 0 vrf 0 pinhole (nil) add UDP 3.9.196.238:0 -> 151.2.139.6:18184 ()
sip sess 0x7f84d10cd000 vd 0 vrf 0 pinhole (nil) add UDP 151.2.139.6:0 -> 3.9.196.238:23074 ()
Output From `diagnose sys sip-proxy stats`
vdom name: root
---------------------------
active-sessions: 1
calls-attempted: 1
calls-established: 1
calls-failed: 0
calls-active: 1
registers-active: 0
| received | blocked | unknown form | long headers
req-type | req resp| req resp| req resp| req resp
UNKNOWN 0 0 0 0 0 0 0 0
ACK 1 0 0 0 0 0 0 0
BYE 1 1 0 0 0 0 0 0
CANCEL 0 0 0 0 0 0 0 0
INFO 0 0 0 0 0 0 0 0
INVITE 1 3 0 0 0 0 0 0
MESSAGE 0 0 0 0 0 0 0 0
NOTIFY 0 0 0 0 0 0 0 0
OPTIONS 0 0 0 0 0 0 0 0
PRACK 0 0 0 0 0 0 0 0
PUBLISH 0 0 0 0 0 0 0 0
REFER 0 0 0 0 0 0 0 0
REGISTER 0 0 0 0 0 0 0 0
SUBSCRIBE 0 0 0 0 0 0 0 0
UPDATE 0 0 0 0 0 0 0 0
PING 0 0 0 0 0 0 0 0
The next thing I tried was attaching the elastic IP of 3.9.196.238 to the WAN port of the firewall, then setting up a VIP
Unfortunately as I suspected, AWS is doing DNAT or destination NAT on the packet before it gets to the wan interface of the firewall
Changing the destination IP 3.9.196.238 to the internal IP 10.40.81.194
What I'll look into next is ether IPv6 which might avoid nat, or a VPN Tunnel if that's possible
For the record I've also tried a couple of other approaches
The first was a VIP approach
In this situation what's actually happening is double nat, AWS is nating 3.9.196.238 to 10.40.81.238 first. Then the firewall is natting 10.40.81.238 to 10.40.15.156 second.
The idea being that we can get the firewall to fixup the traffic some how as it passes through because it's nat options are enabled. but even with Hosted nat transversal enabled this didn't seem to work.
Also tried the AWS SDN which can pick up on the external / internal IP mappings from AWS, but all that does is group IP address's into things that can be matched against within the firewall policies, it doesn't feed into the SIP-ALG at all.
I suspect we'll have to use something like https://www.consoleconnect.com from the looks of things to get the traffic into the network as our SIP provider doesn't support VPN site to site tunnels.
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 |
---|---|
1698 | |
1092 | |
752 | |
446 | |
228 |
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.