problems unblocking my sip provider
-
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...
-
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.
-
Double NAT is the issue then.
-
@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
-
Have a look at a SIP packet from a packet capture from pfsense.
-
@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.
-
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
-
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.
-
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
-
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
-
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 said in problems unblocking my sip provider:
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. -
0_1551907391062_packetcapture.7z @stephenw10 said in problems unblocking my sip provider:
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
i have tried a LAN rule that allows all outbound from the static address i have assigned to the sip controller device to any wan address. makes no difference.
I'm still pretty sure that pfsense is killing off connections after 15 minutes cause my call cuts out to the second.
-
I am also no longer confident that outbound just "works" cause i've realized i have to call the one number multiple times and the call only goes through after 2 or 3 attempts some times. i didn't realize it before because i got the engaged noise and just thought they were already on the phone. i only noticed now because i have been calling my own mobile/cell so much for generating logs to see whats going on.
-
So you tried an outbound NAT rule with static ports? Not a static IP?
IPFire includes a SIP ALG, do you recall if it needed to be enabled?
If so SIProxd might work for you here.Steve
-
@stephenw10 said in problems unblocking my sip provider:
So you tried an outbound NAT rule with static ports? Not a static IP?
IPFire includes a SIP ALG, do you recall if it needed to be enabled?
If so SIProxd might work for you here.Steve
Someone mentioned SIProxy before. i had a quick look at it and i've never seen anything like it before. and as i keep saying....
i never had to use more then the settings i'm using now on my previous configuration and never had issues.
-
is there a way to can make pfSense stop blocking anything incoming on that port. i know its a security risk i want to try it temporarily and see if it solves my problem
-
So i have added so many firewall rules now that nothing shows up in my logs to do with any incoming or outgoing call attempts. I have also tried disabling snort cause i read a post from 3 years ago that "pfSense works perfectly with snort disabled"
but i am still having the same problems.
-
Try adding a 1:1 NAT rule to the SIP device. Then add a firewall rule on WAN allowing all traffic to that internal IP.
Yes, that's a big risk it exposes the SIP device completely. But that will add static outbound NAT and will pass everything.
If it still doesn't work there's some NAT issue like it's sending it's internal IP. That can only be solved by configuring the SIP device not to do that or using a SIP ALG that translates that.
Steve
-
are you sure its a 1:1 nat rule? i cant specify ports
isnt this what i want?
its doesn't work though
-
With a 1:1 rule all ports are forwarded. All incoming traffic will be sent to the SIP device. All outgoing traffic will leave using the same source ports the SIP device sets. That eliminates a number of possible problems.
1:1 NAT rules do not automatically open firewall rules though so you need to add a rule to pass what you need. As a test I suggest just passing everything.
However that will not help if, for example,m the SIP device is using it's private IP is SIP packets as the response address. Only looking at those packets will tell you that. If it is SIProxd could help.
Steve
-
Is there a nice guide for setting up siproxy?
as this is my second dabble with connecting sip devices i really have no idea what i am doing -
Not other than this: https://docs.netgate.com/pfsense/en/latest/packages/siproxd-package.html
That really doesn't tell you much but generally it is discouraged.
The 1:1 NAT did nit help at all? Did you still see blocked traffic?
Have you tried looking at the SIP packets yet to see what IPs the device is sending?
Steve
-
i haven't tried the 1:1 NAT because the incoming IP address in not static, and at one point i had added so many rules added into the firewall that there was nothing appearing in the logs.
i still have the issue were outgoing calls drop after 15 minutes too
-
Might need to review at this point. What exactly do you have in place right now in terms of port forwards and firewall rules and SIProxd?
What VoIP issues are you now seeing?
Steve
-
I have tried to open incoming traffic from telstra's entire sub net range.
the 5060-5065, 5004, 3487 ports are all allowed in firewall rules and NAT rules to forward them to my telstra sip device. i have included up to 5065 because i noticed in the logs that the incoming calls didn't only seem to come from 5060.
i had installed snort so I have tried removing it again.
Incoming calls almost never work and outgoing calls always get cut after about 15 minutes.
It can't be a double NAT issue and my mobile/cell phone uses the telstra device for its WiFi hot spot and it works fine.
I did not have these issues with the previous software firewall/gateway i used and all it took was to port forward the same ports i have currently configured into pfSense.
-
Ok, well there are two possibilities. It requires some static source NAT outbound that the old router provided. It requires a SIP ALG which the old router provided.
Just using 1:1 NAT and opening the phone up completely will test theory one.
To test theory two I would capture the SIP traffic and check the contents to see what's actually happening. Then deploy SIProxd if it's appropriate.
Steve
-
Just taking a complete guess at this.
i never specified a nat source for outbound previously, nor a SIP ALG. i just forwarded the ports
-
-
I'm sure THIS is why its not working... even when i managed to get that to stop showing up it still seems to be blocking it
-
i also can't list a nat rule like this
it requires me to put a redirected port in.. but the source it transmitting from port 5060 to 44780.
i cant just specify any port recieved from the source port of 5060 to forward it
-
am i reading these logs wrong.. it looks like my provider is trying to send sip packets from port 5060 to a random port on my gateway, where pfSense seem to want to to come from a random port from the source and arrive at port 5060
-
What i have right now is :
out of maybe 30 attempted incoming calls one worked... is there some kind of auto closing of established connections that could be going on?
-
looking at the out going packets from a out going call it seems to be normal.
the packets are being sent from my local device port 5065 to a receiving port of 5060.
-
incomming packet sniff
-
The external IP should be the WAN IP address in that 1:1 NAT rule.
Setting the destination as Telstras subnet there means it will only applky to traffic to or from that. So if they are using other IPs it won't pass it. I would leave that as 'any' as a test.
The reason traffic comes back to a random port is because it's replying to traffic the p[hone sent out and pfSense will randomise source ports for security. That should not be a problem. However the fact it's showing as blocked means that firewall state has closed so replies are not getting back to the phone.
You did set the firewall optimisation to conservative earlier? It might require exceptionally long timeouts there.The working 1:1 NAT rule will by-pass that though as traffic will be allowed back in even if the state has expired and source ports will not be changed.
Steve
-
I cant do a 1:1 NAT rule on my wan IP address because i do not currently have a static IP address. there isn't an option to just specify "wan address" like there has been for many other options.
Is there a way i can put in a request for this option?
-
another idea i had now that i'm thinking of it, can i put the telstra device in a dmz on its own vlan and just tell pfsense to forward anything to that single ip address. that would mean anything that didn't originate from my internal lan would get forwarded to the tesltra device, and if it got hacked, its in its own vlan, so they cant do anything anyways.
-
Hmm, interesting I hadn't considered that. Just as a test you can add you current IP as the destination though. You don't want to have that open on all ports permanently. If it works we can look at why it worked and how to replicate that woth port forwards.
Steve
-
sorry i took so long to reply. was sick for like 6 days and had no motivation to look at something with i'm already too frustrated with.
i tried both of these, neither have worked. did i not set it up the way you meant?
i get the occasional incoming call but i think it has more to do with the timing of my sip device re-establishing a connection before it getting dropped out after 15 minutes.