Yes, I cleared the helper then reset all the connections and rebooted the router. Still no luck.
Casey On Fri, Jan 30, 2015 at 8:29 AM, Tim Warnock <[email protected]> wrote: > Did you disable the SIP Helper? > > > -----Original Message----- > > From: [email protected] [mailto:mikrotik- > > [email protected]] 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 <[email protected]> > > 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 > > > [email protected] > > > > > > 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 > > > [email protected] > > > 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 > > [email protected] > > http://mail.butchevans.com/mailman/listinfo/mikrotik > > > > Visit http://blog.butchevans.com/ for tutorials related to Mikrotik > RouterOS > _______________________________________________ > Mikrotik mailing list > [email protected] > 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/73713936/attachment.html> _______________________________________________ Mikrotik mailing list [email protected] http://mail.butchevans.com/mailman/listinfo/mikrotik Visit http://blog.butchevans.com/ for tutorials related to Mikrotik RouterOS
