Taking a little break from my lab PBX to get other tasks done.

@scottalanmiller said in RTP traffic being sent to incorrect IP address:

WAN_IN, shouldn't the firewall rule allow based on the public IP, not the translated LAN IP?

With VyOS, NAT is done before firewall rules for inbound traffic and after firewall rules for outbound traffic.

Yes. Initially no, but during my troubleshooting yesterday, the address was set to .114. I had it redetect settings, and it changed to.116, so it is now configured correctly.

I did fail to mention that ending a SIP call also fails. The BYE request is sent to.114 from the SIP client as well. So if I hang up on the SIP phone at home, the call continues on the cellphone. Likewise if the cellphone hangs up; thus, I can see BYE from Twilio going to .116as intended, despite RTP traffic from Twilio going to.114.

So in my adventures with tinkering in my lab, I've encountered a new issue. RTP traffic is not being sent from the SIP client to FreePBX. SIP signaling seems fine as both sides are able to initiate and answer a call; however, neither side hears audio.

Here's the setup:

• FreePBX is on a VM that's behind a VyOS firewall in my colo.
• Yealink T21P phone behind an ERL at my home.
• Cellphone used for testing is on MetroPCS
• SIP trunking is provided by Twilio

I have a FreePBX VM in Vultr, which I've been using for a while, and I have no problems making and receiving calls with SIP clients on my home network.

My first though was that there must be something screwy with NAT; however, I don't see anything wrong with my configuration. I have the source NAT rule for FreePBX before the masquerade rule, so from what I understand, no traffic from 192.168.100.5 will be masqueraded to .114. Perhaps a few FFSes will lift my blindness.

As far as how I know that RTP traffic is going to the wrong address. I collected a packet capture from both VyOS and my Yealink phone. The SIP packets are being sent to the correct IP, .116. However, once RTP traffic flows, that traffic sent to the.114 address, which is the main address of the VyOS eth0 interface, and the address from which all other outbound traffic in my colo is masqueraded.

I'm curious as to how the Yealink phone would know to send RTP traffic to .114 rather than .116.

This is the interface configuration.

interfaces {
    ethernet eth0 {
        address 208.70.XXX.114/YY
        address 208.70.XXX.115/YY
        address 208.70.XXX.116/YY
        description WAN
        duplex auto
        firewall {
            in {
                name WAN_IN
            }
            local {
                name WAN_LOCAL
            }
        }
        hw-id 52:54:00:8d:d5:91
        smp_affinity auto
        speed auto
    }
    ethernet eth1 {
        address 192.168.100.1/24
        description LAN
        duplex auto
        hw-id 52:54:00:a9:66:e6
        smp_affinity auto
        speed auto
    }
    loopback lo {
    }
}

This is the firewall configuration.

    name WAN_IN {
        default-action drop
        rule 1010 {
            action accept
            state {
                established enable
                related enable
            }
        }
        rule 1020 {
            action accept
            description "Allow RTP to FreePBX"
            destination {
                address 192.168.100.5
                port 10000-20000
            }
            protocol udp
        }
        rule 1021 {
            action accept
            description "Allow SIP to FreePBX"
            destination {
                address 192.168.100.5
                port 5060,5061
            }
            protocol udp
        }
        rule 1030 {
            action drop
            state {
                invalid enable
            }
        }
    }

This is my NAT configuration:

nat {
    destination {
        rule 110 {
            description "Internet to FreePBX"
            destination {
                address 208.70.XXX.116
            }
            inbound-interface eth0
            translation {
                address 192.168.100.5
            }
        }
    }
    source {
        rule 105 {
            description "FreePBX to Internet"
            outbound-interface eth0
            source {
                address 192.168.100.5
            }
            translation {
                address 208.70.XXX.116
            }
        }
        rule 110 {
            description "Masquerade to Internet"
            outbound-interface eth0
            translation {
                address masquerade
            }
        }
    }
}

@jaredbusch said in What Are You Doing Right Now:

@eddiejennings said in What Are You Doing Right Now:

Working on my FreePBX and VyOS vms.

Give me an hour to get a few drinks in me then ask away!

Ha! This is a little different than using FreePBX on a Vultr instance. My current experiment is this:

1. NAT traffic to the pbx (not ports configured on this)
2. Allow only necessary ports in with my WAN_IN firewall rule set
3. Let the responsive firewall do it's thing.

#2 is probably not necessary, as I could just let any traffic to the pbx through and just rely on the responsive firewall, but this is an experiment; thus, a chance to see if I can configure it like this.

Working on my FreePBX and VyOS vms.

@scottalanmiller said in What Are You Doing Right Now:

So many calls today!

HALP! [email protected]! MAH 3MAILZ!

Watching the A's and working with VyOS.

@scottalanmiller said in What Are You Doing Right Now:

I've got customer reporting that hosted Spiceworks helpdesk is down. I see the same thing here. Anyone else seeing this?

Looks like something is up down: https://status.spiceworks.com/

Got this link from one of our Citirx admins.

https://www.theregister.co.uk/2018/05/14/citrix_rebranding/