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
