problems unblocking my sip provider

[randomaustralian]

So i barely use my "land line" except for out going calls and they have mostly worked for me, but i haven't been able to receive incoming calls since i switched to pfSense. (not such a bad thing, no telemarketers) the reason its turned into a problem is my outgoing calls that last longer then 15 minutes get cut, i think, by pfSense.

Tonight i had the idea to use wire shark, worked out the packet capturing and discovered the external IP address of the sip server. i have now worked out snort was blocking the incoming packets as an unknown sip.
i unblocked the IP in snort and now its being blocked by the default deny rule.

i have added the IP and all the relevant sockets to the pass lists on the WAN interface but its still being denied by the block rule...

is this just me getting the syntax incorrect or is there something else i need to change.

[NogBadTheBad]

@randomaustralian said in problems unblocking my sip provider:

ave added the IP and all the relevant sockets to the pass lists on the WAN interface but its still being denied by the block rule.

Try killing the firewall states.

[randomaustralian]

@nogbadthebad said in problems unblocking my sip provider:

@randomaustralian said in problems unblocking my sip provider:

ave added the IP and all the relevant sockets to the pass lists on the WAN interface but its still being denied by the block rule.

Try killing the firewall states.

does not appear to have helped, a reboot did nothing either.

[NogBadTheBad]

What's with the top rule ?

You are passing everything from Telstra to 10.0.0.150

inetnum: 58.160.0.0 - 58.175.255.255
netname: TELSTRAINTERNET42-AU
descr: Telstra Internet
descr: Locked Bag 5744
descr: Canberra
descr: ACT 2601
country: AU
org: ORG-TC6-AP
admin-c: TIAR-AP
tech-c: TIAR-AP
remarks: -----
remarks: All reports regarding SPAM or security breaches
remarks: should be addressed to abuse@telstra.net
remarks: ------
status: ALLOCATED PORTABLE
mnt-by: APNIC-HM
mnt-lower: MAINT-AU-TIAR-AP
remarks: --------------------------------------------------------
remarks: To report network abuse, please contact mnt-irt
remarks: For troubleshooting, please contact tech-c and admin-c
remarks: Report invalid contact via www.apnic.net/invalidcontact
remarks: --------------------------------------------------------
mnt-irt: IRT-TELSTRA-AU
last-modified: 2017-09-26T23:28:48Z
source: APNIC

FYI I've sat on conf calls for hours and not been cut off, don't think its a pfSense issue.

[randomaustralian]

@nogbadthebad
Telstra is my sip provider. I started of with only the single IP address that i was tracking then added the entire network cause the IP address that was sending me sip packets kept changing.

on my previous firewall i only had to open the ports and the SIP connections worked perfectly. but pfsense keep auto blocking the telstra IP addresses

[NogBadTheBad]

The connection should originate from the phone, i'm surprised you need any rules on the WAN interface.

I use a SIP phone and don't require any rules on the WAN interface.

https://docs.netgate.com/pfsense/en/latest/nat/configuring-nat-for-voip-phones.html?highlight=voip

Maybe try installing Siproxd

https://docs.netgate.com/pfsense/en/latest/packages/siproxd-package.html

Out of interest does the WAN interface have a RFC 1918 IP address ?

https://www.netgate.com/resources/videos/firewall-best-practices-for-voip-on-pfsense.html

[stephenw10]

Hmm, yeah if you just have a phone I would not normally expect anything to be required. Some providers might require static outbound NAT.

I assume you have port forwards in place for all those ports? Those doen't look to have been added automatically by the port forwards though.

What happens if you have none of those rules enabled? Does the phone register?

15mins sounds like a state timeout of some sort. Try setting the 'Firewall Optimization' to Conservative in System > Advanced > FIrewall&NAT if you have not already done so.

Steve

[randomaustralian]

@nogbadthebad & @stephenw10

connection should originate from the phone

outbound connections do work, inbound ones dont.

my previous firewall (IPFire) i had to put in exceptions for those ports or incoming didn't work. with pfsense the packets are still coming up as blocked in the logs.

I'll try siproxyd

[stephenw10]

Hmm, curious. How do Telstra expect this to work? Do they supply their own router with SIP ALG included?

What you're describing is well beyond the ability of the average user...

[randomaustralian]

@stephenw10

I got it to work easily enough last time. i have used a 3rd party router since i got FTTP NBN cause its all PPOE. They don't at all support what i'm doing. I'm putting my ISP supplied router behind my 3rd party router so i can still use all the ISP features that require my ISP supplied router to be used.

But it think pfSense is more secure then IPFire. even when i try to allow the ports and IP addresses in my firewall rules i still can't get incoming calls to work.

[NogBadTheBad]

Double NAT is the issue then.

[randomaustralian]

@nogbadthebad said in problems unblocking my sip provider:

Double NAT is the issue then.

not at all.

i'm not connecting anything through the supplied router... its just sitting on my network like any other device. and the WiFi on it does work on my phone so it cant be a double nat issue. at least it wasn't a problem previously

i'm just using it like a wifi hotspot and a sip device

[NogBadTheBad]

Have a look at a SIP packet from a packet capture from pfsense.

[randomaustralian]

@nogbadthebad said in problems unblocking my sip provider:

Maybe try installing Siproxd

i don't think this is my solution as this seems to be a server that runs sip on my lan, when i already have a stand alone box that does it.

[stephenw10]

I agree, capture some SIP packets and see what's happening.

Sounds like it's registering it's internal IP maybe or something similar. SIProxd might actually help if that is the case.

Steve

[chpalmer]

Insert the :rolleys: smiley here.. SIP was not originally designed to be behind NAT!

It was written in later when services such as Vonage and a couple earlier started to look at the residential market. And it does not work all that well.. Double NAT is not in the spec. If you try your on your own.

In the SIP header you will find (normally) your NATted address. Yes. Building a WAN firewall rule will help in some cases depending on the carrier. Sometimes you need to pay attention to your states when you try to make a call and see what carrier your device is connecting to. SIP from your provider.. RTP from the carrier they use. It is truly a case by case basis.

Few SIP providers will also need static port enabled. Very few these days.

I never port forward to any client devices. All of my SIP customers work flawlessly.

[randomaustralian]

so for an incoming call
if i turn off all the rules i get this:

if i open just all the ports in my rules i get:

with

capturing a sip packet i get... a ringing phone? WTF?!?!?!

seems its a 1 off though as it didn't ring the next 3 attempts

[stephenw10]

What I expect to happen here is the phone connects out to the SIP server at port 5060. If you don't have static outbound NAT set for the phone IP the source port as that leaves the WAN will be randomised. The phone holds that state open with keepalive packets so that when the provider sends traffic to it for an inbound call it still passes through the firewall.

Since you are seeing it blocked that state is either not being held open or the provider is replying to the wrong port.

Check your state table for the phones IP. See what source port it is using, is it port 5060?
Is it holding open a SIP state at all?

It could be you need a static outbound NAT rule.

Can we see that actual packet capture file? The SIP packets there likely contain useful info.

Steve

[tim.mcmanus]

You have ovcercomplicated this and now your troubnleshooting is going to be far more complicated.

I am running a Cisco SIP phone behind pfSense and have been doing it for years with no issues. I also run a SIP client (Bria) on my iOS phone as well as my Mac. All three of them have no issues running behind pfSense.

Your SIP phone will initiate a connection from itself to the SIP provider. Since that connection is initiated on pfSense’s LAN, it also manages the incoming connection back to the phone with no additional configurations required. If you installed a default pfSense box as your router with no additional configurations (other than the ones you need to get your LAN to communicate with the Internet), your phone will work with no issues. The problem is the complexity of your configuration and trying to acutely manage this traffic. Let pfSense do it’s job and when the outgoing connection starts, pfSense will manage the inflow too.

I was on hours of conference calls yesterday with no issues whatsoever. I have a minimal pfSense installation with very few rules in order to reduce the complexity of the installation to ensure that stuff works without me having to go in and continually tweak stuff.

So try ratcheting back all of the features and config you have first. Reduce the complexity and then build up rules from there. When you enable the rule or config that’s killing your SIP connection, you’ll find it this way.

IMHO, YMMV...

[randomaustralian]

@randomaustralian said in problems unblocking my sip provider:

@stephenw10

I got it to work easily enough last time. i have used a 3rd party router since i got FTTP NBN cause its all PPOE. They don't at all support what i'm doing. I'm putting my ISP supplied router behind my 3rd party router so i can still use all the ISP features that require my ISP supplied router to be used.

But it think pfSense is more secure then IPFire. even when i try to allow the ports and IP addresses in my firewall rules i still can't get incoming calls to work.

I just realized i didn't answer your question properly.
telstra don't expect this to work. the sip host is on their provided edge router and they do not support what i am trying to do...
the thing is I got it to work easily on ipfire. I'm having troubles with pfsense because it seems pfsense is more secure/intelligent with what is allows through.