I don't know, it was designed specifically for the B and B+ models. http://www.raspberry-asterisk.org/
Casey On Fri, Jan 30, 2015 at 9:37 AM, Scott Reed <[email protected]> wrote: > Maybe using the wrong distribution so it did not have the correct drivers > for the interfaces? > > > On 1/30/2015 8:22 AM, Casey Mills wrote: > >> 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/b6568c01/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 >> >> >> ----- >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 2015.0.5646 / Virus Database: 4273/9025 - Release Date: 01/30/15 >> >> >> > -- > Scott Reed > Owner > NewWays Networking, LLC > Wireless Networking > Network Design, Installation and Administration > Mikrotik Advanced Certified > www.nwwnet.net > (765) 855-1060 (765) 439-4253 Toll-free (855) 231-6239 > > > _______________________________________________ > 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/7a9d0639/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
