<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">You can do a bit more debugging here to
      bridge the gap between "config upload" and "connections don't
      work".  The router has a nice "/tool sniffer quick" utility
      built-in.  Try it with the arguments "interface=all
      ip-protocol=tcp port=26" and launch a connection in from the
      outside world.  You should be able to see everything going on,
      from the original packet coming in (or not), to it getting
      translated and sent to your server (or not), to your server
      replying (or not), to the un-NAT and retransmission (or not). 
      Somewhere along the line you'll spot the root of the problem.  I
      don't know what it is, as the config looks fine to me.<br>
      <br>
      Oh, and screen width DOES matter.  I believe if your window isn't
      wide enough (eg: just 80 columns) it'll omit MAC address details. 
      So, max your window before running the sniffer.  Either that or
      use the winbox GUI sniffer.<br>
      <br>
      Please report back!<br>
      <br>
      --Bart<br>
      <br>
      <br>
      On 04/03/2014 05:17 PM, Dean Gibson AE7Q wrote:<br>
    </div>
    <blockquote cite="mid:533DFA19.1000309@ae7q.com" type="cite">
      <meta http-equiv="content-type" content="text/html;
        charset=ISO-8859-1">
      Objective: When an external (ie, wlan) connection is attempted to
      port 26 on the radio, forward that traffic ("destination NAT") to
      a computer on my internal LAN.<br>
      <br>
      Firewall rules in the radio (rules #3 & #7 in the filter
      chain, and rule #1 in the NAT chain, have been inserted by me):<br>
      <br>
      <font color="#3333ff"><i><tt><small>/ip firewall filter print<br>
              Flags: X - disabled, I - invalid, D - dynamic<br>
               0   ;;; default configuration<br>
                   chain=input action=accept protocol=icmp
              src-address=44.0.0.0/8<br>
              <br>
               1   ;;; default configuration<br>
                   chain=input action=accept
              connection-state=established<br>
              <br>
               2   ;;; default configuration<br>
                   chain=input action=accept connection-state=related<br>
              <br>
               3   chain=input action=accept protocol=tcp
              in-interface=wlan1-gateway dst-port=26<br>
              <br>
               4   ;;; default configuration<br>
                   chain=input action=drop in-interface=wlan1-gateway<br>
              <br>
               5   ;;; default configuration<br>
                   chain=forward action=accept
              connection-state=established<br>
              <br>
               6   ;;; default configuration<br>
                   chain=forward action=accept connection-state=related<br>
              <br>
               7   chain=forward action=accept protocol=tcp
              in-interface=wlan1-gateway dst-port=26<br>
              <br>
               8   ;;; default configuration<br>
                   chain=forward action=drop connection-state=invalid<br>
              <br>
              /ip firewall nat print<br>
              Flags: X - disabled, I - invalid, D - dynamic<br>
               0   ;;; default configuration<br>
                   chain=srcnat action=masquerade to-addresses=0.0.0.0
              out-interface=wlan1-gateway<br>
              <br>
               1   chain=dstnat action=dst-nat
              to-addresses=192.168.0.250 protocol=tcp
              in-interface=wlan1-gateway dst-port=26</small></tt></i></font><br>
      <br>
      I use the same technique on my Linux boxes, and it works fine
      (albeit iptables is slightly different).  However, when accessing
      my radio from an external IP address, no connection is made (times
      out).  If I change the dstnat rule action to "accept", the
      connection is refused.  The logs for port 26 on the target device
      (192.168.0.250) show no connection attempt.  In the (default)
      srcnat chain, "action=masquerade" implies NATting on the return
      trip (into the LAN).  The same thing needs to happen in a dstnat
      chain, but I don't see a way to do that;  I'm "assuming" that the
      OS automatically does that.  When doing DNAT on Linux, I have to
      do that manually, with the same rule in the "PREROUTING" and
      "OUTPUT" NAT chains, but those chains don't exist in my radio.<br>
      <br>
      Ideas welcome (note that "action=masquerade" is not valid in a
      dstnat chain).<br>
      <br>
      -- Dean<br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
PSDR mailing list
<a class="moz-txt-link-abbreviated" href="mailto:PSDR@hamwan.org">PSDR@hamwan.org</a>
<a class="moz-txt-link-freetext" href="http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org">http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>