problems unblocking my sip provider
-
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.
-
The active rule is correct there though I would leave the destination as 'any' at least for a test.
It does depend what firewall rules you have there also. Again as a test I would open it up completely, re-register the phone and test incoming calls.
If that doesn't work it's not a firewall rule issue and probably is reliant on a SIP ALG.
Steve
-
If I get time I will go through this whole thread later and see what pops out.
Are you still trying to use a STUN server?
Who is your SIP provider??
-
I see now who your provider is..
Apparently from the graphics showing the firewall logs above your LAN device (SIP Unit) is not listed in the SIP header. Otherwise the address would show as the SIP device. Id be interested in your state table.
SIroxd is very easy to set up and probably a good idea here.
Unless specified leave it blank (or default) for now.
Delete any port forwards or static NATting you have done.
Inbound Interface- whatever ethernet port your sip device is plugged into.
Outbound Interface- whatever ethernet port goes out to your internet.
Go down to RTP proxy. Enable It.
RTP Port Range (Lower) looks like 5004 from your stuff above.
RTP Port Range (Upper) 5059
Save!
Get the stun server stuff out of the mix for now. I do not believe you need it.
Reboot your SIP device.
Watch the "Registered Devices" tab and see if your phone shows up there.
If it does not you can add a proxy to the device config or see if they will do that for you.. The proxy address is your LAN address (or address of the ethernet port your SIP device is plugged into.)
Your WAN firewall rules above pointing at "this firewall" should work although I always use "wan address"..
-
http://siproxd.sourceforge.net/ for some details if your so inclined.
-
chpalmer: Cheers mate. trying it out and testing it.
i thought i should have provided this from the very get go.
pretty sure i said before they don't officially support this, but this is the information i found online to get it working originally.
https://crowdsupport.telstra.com.au/t5/Modems-Hardware/ports-for-firewall-in-front-of-telstra-router/m-p/720153#M36304
