<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
OK, I tried that (maxing the SSH window gave me 273 columns), and as
I suspected, the wlan packets are being forwarded to the target, but
the responses are not coming back to the radio. That's the
difference between source/destination NAT and masquerading; the
latter also modifies the source packet to cause the responses to
come back to the NAT box, so that they can be "un-masqueraded" and
sent back to the originator.<br>
<br>
What was happening, is that the responses were being generated, but
since the source address (out in the wild Internet) had not been
masqueraded, the responses were sent by the default route back to
the originator. However, when that happened, the default route
masqueraded the response, and so when it arrived at the originator,
it had the IP address of the default route (eg, my normal ISP's
router), not the IP address of the radio that the originator
expected. Result? <b><font color="#cc0000">DROP.</font></b><br>
<br>
I needed a second masquerading line, show below in red. Works!<br>
<br>
<div class="moz-cite-prefix">On 2014-04-03 18:11, Bart Kus wrote:<br>
</div>
<blockquote cite="mid:533E06CB.7090906@bartk.us" type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<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=UTF-8">
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>
<font color="#009900"> 3 chain=input action=accept
protocol=tcp in-interface=wlan1-gateway dst-port=26</font><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>
<font color="#009900">7 chain=forward action=accept
protocol=tcp in-interface=wlan1-gateway dst-port=26</font><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</small></tt></i></font><font
color="#3333ff"><i><tt><small><font color="#3333ff"><i><tt><small><br>
</small></tt></i></font></small></tt></i></font><font
color="#cc0000"> <i><small><tt>1 </tt><tt>chain=srcnat
action=masquerade to-addresses=192.168.0.250
protocol=tcp out-interface=ether1-local dst-port=26</tt></small></i></font><br>
<font color="#3333ff"><i><tt><small><font color="#3333ff"><i><tt><small><br>
</small></tt></i><font color="#009900">2</font></font><font
color="#009900"> chain=dstnat action=dst-nat
to-addresses=192.168.0.250 protocol=tcp
in-interface=wlan1-gateway dst-port=26</font></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>
</blockquote>
</blockquote>
<br>
</body>
</html>