Did you disable the SIP Helper? > -----Original Message----- > From: mikrotik-boun...@mail.butchevans.com [mailto:mikrotik- > boun...@mail.butchevans.com] On Behalf Of Casey Mills > Sent: Friday, 30 January 2015 11:23 PM > To: Mikrotik discussions > Subject: Re: [Mikrotik] SIP Problem > > Yes Nathan, everything in your first paragraph is correct. > > I also agree with your statements about the VPN and UDP. > > I ended up resetting my router back to the default configuration and > v6.19. Then only added the bare minimum to get traffic flowing again. My > FreePBX server still wouldn't connect. I was using a distribution created > for the Raspberry Pi. I went to the FreePBX website and downloaded the > full > ISO and installed on a test machine. This distribution had no issues > connecting to the SIP trunk provider SIP.US. Maybe the issues wasn't my > firewall after all, but it sure looked like it. > > I'm still really curious what the issue was. I would prefer to use a small, > low power, inexpensive device. Anyone know of a good low power device > that > might be Atom processor based to run the full distribution? > > Thanks for all of your help everyone! > Casey > > > > On Thu, Jan 29, 2015 at 9:03 PM, Nathan Anderson <nath...@fsr.com> > wrote: > > > (...replying to myself...) > > > > Ignore my comments about the dst-nat rules. I misread your posts and > > thought you had said that you successfully managed to connect directly to > > your SIP trunk provider *from your Android phone* and *from within your > > network*. Now I see that you are using those dst-nat rules to make your > > FreePBX server accessible to remote extensions from the outside, and > that > > your Android phone is set up as an extension, *not* that you were > > registering to your SIP provider from your handheld. > > > > My only comment on that would be that requiring a VPN connection rather > > than doing the port-forwarding might be safer and better protect you from > > toll fraud. :) But at least I see what you are doing with those now. > > > > I haven't tested this theory, but the reason why I suggest you try > > temporarily disabling that drop rule for forwarded traffic with an invalid > > connection state is that everything I've read so far seems to suggest that > > anything is considered an "invalid" connection if it A) doesn't already > > have an entry in connection tracking, and B) it is not a "new" connection, > > which basically means TCP SYN. Unlike TCP, my understanding is that UDP > > really doesn't have easily definable connection "states", so I'm not > > actually sure that the "connection-state" firewall matcher is compatible > > with anything other than TCP (or that it makes sense to apply it to > > anything other than TCP). Again, I have not tested or verified this. But > > if this is the case, then it's possible that rather than ignoring UDP > > traffic, the filter rule might be blindly tossing anything UDP that is > > being forwarded. (You did say that you see the packets being received > from > > the FreePBX box, but that they were being dropped b > > efore being forwarded...) > > > > If disabling that rule fixes your problem, and you want to keep a rule > > like that in place, you might try making it more specific by adding > > additional matchers, such as "protocol=tcp" and perhaps even > > "in-interface=<WAN>". > > > > -- > > Nathan Anderson > > First Step Internet, LLC > > nath...@fsr.com > > > > On Thursday, January 29, 2015 5:30 PM, Nathan Anderson wrote: > > > > > Are you doing SIP over TCP or UDP from FreePBX? (Guessing UDP.) > > > > > > Are you doing SIP over TCP or UDP from your Android phone that works? > > > (Guessing TCP.) > > > > > > Can you try either disabling the last rule in your firewall filters list > > > (action=drop chain=forward connection-state=invalid), and/or also > setting > > > protocol=tcp on it, and then try to originate SIP traffic from your > > > FreePBX server again? > > > > > > They probably aren't harming anything, but unless your SIP trunk > provider > > > isn't requiring you to send SIP REGISTER to them and instead uses > > > IP-based authentication, you don't need all of those dst-nat rules > > > pointed at your FreePBX box. The kernel's connection tracking should be > > > able to figure all of that out. > > _______________________________________________ > > Mikrotik mailing list > > Mikrotik@mail.butchevans.com > > http://mail.butchevans.com/mailman/listinfo/mikrotik > > > > Visit http://blog.butchevans.com/ for tutorials related to Mikrotik > > RouterOS > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://mail.butchevans.com/pipermail/mikrotik/attachments/20150130/b > 6568c01/attachment.html> > _______________________________________________ > Mikrotik mailing list > Mikrotik@mail.butchevans.com > http://mail.butchevans.com/mailman/listinfo/mikrotik > > Visit http://blog.butchevans.com/ for tutorials related to Mikrotik RouterOS _______________________________________________ Mikrotik mailing list Mikrotik@mail.butchevans.com http://mail.butchevans.com/mailman/listinfo/mikrotik
Visit http://blog.butchevans.com/ for tutorials related to Mikrotik RouterOS
