Using Fortigate under AWS for SIP / RTP / Outbound Pinholes

[garlicbread]

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:

• SIP traffic on port 5060 arrives at AWS on ElasticIP1
• AWS then automatically translates the destination IP for the packet from ElasticIP1 to InternalIP1
• Traffic is routed to the Fortigate Firewall on it's WAN interface
• There's a single firewall rule / policy to allow SIP through for InternalIP1 as a destination via the Lan interface.
• There's also a VOIP policy attached to this rule so that SIP-ALG will inspect the packet

This is where things go a bit wrong

• At this stage what should happen is that SIP-ALG should then open outbound connections for RTP using pinhole ports.
• But due to I think the destination IP of the UDP packet and the destination IP of the SIP packet being different this doesn't seem to happen.
• SIP traffic goes in, but RTP doesn't get out.

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

[patelr]

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

[HarshChavda]

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

[garlicbread]

In the case of AWS when you assign an elastic ip to any network interface there's always a one to one NAT that takes place from AWS's point of view before it reaches inside

So the Fortigate will always see an internal IP hit it's WAN port for the UDP Packet and never the true external IP

As far as assigning the elastic IP directly to the Fortigate's WAN then using a VIP I think unfortunately this would have the same issue. Since you'll still end up with the same thing happening with the destination IP being switched by AWS from an external one to an internal one (something that can't be avoided)

So the virtual IP mapping wouldn't see the external IP arrive but an internal one instead and this wouldn't match what is inside the SIP packet

Looking here for example the VIP mapping is using internal IPs if you try it that way - https://community.fortinet.com/t5/Blogs/Adding-Elastic-IPs-to-AWS-FortiGate-to-be-used-as-VIPs/ba-p/...

I'm pulling together some logs and configs I'll post a bit later, but I've attached a network diagram below

To be clear we don't have NAT enabled on the SIP Firewall rule policy, since we want it to just pass through (single device on the EC2 end)

For this link - https://docs.fortinet.com/document/fortigate/6.2.0/new-features/784393/custom-sip-rtp-port-range-sup... it's related to NAT which we're not doing inside the Fortigate, also it has some default values set anyway.

The part we're interested in is getting it to dynamically open and close the outbound pinholes for RTP after the SIP traffic has arrived.

I was hoping "set hosted-nat-traversal enable" might fix this, but it looks as if NAT needs to be enabled inside the firewall policy rule for that to work

and so far I've not had much luck with NAT enabled on the policy rule, so that might be my next point of call

https://community.fortinet.com/t5/FortiGate/Technical-Tip-FortiGate-Hosted-NAT-Traversal-for-SIP/ta-...

[garlicbread]

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

[garlicbread]

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

[garlicbread]

For the record I've also tried a couple of other approaches

The first was a VIP approach

• Setup a secondary IP address on the WAN interface of the firewall
• In this case 10.40.81.238
• Point the external IP that was associated with the SIP server (3.9.196.238)
• To the firewall's internal secondary internal IP under AWS
• Setup a VIP which maps 10.40.81.238 (Firewall WAN) on the outside
• To the SIP server's internal IP 10.40.15.156 on the inside.
• Then setup firewall rules for SIP inbound and full outbound, with NAT enabled in the rules.

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.