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/b6568c01/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
