<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Connection tracking was on from the start. The solution is to use
masquerading properly, not to rape the routing table.<br>
<br>
<div class="moz-cite-prefix">On 2014-04-03 22:40, Bart Kus wrote:<br>
</div>
<blockquote cite="mid:533E45BC.3060106@bartk.us" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Right on!<br>
<br>
I'm glad you were able to diagnose and solve the problem with
minimal assistance!<br>
<br>
You experienced a version of asymmetrical routing that I
recently documented on the LAN Integration page. Another
solution for you might be to change the routing table on that
server so it uses the HamWAN modem for port 26 comms. The best
solution I can think of is to send the packet back out the same
interface it came in. With a Linux server you can pull it off
there, or you can pull it off on most routers too by enabling
connection tracking. That way you don't have to lose the source
IP. I documented one scenario of how to do this on the LAN
Integration page. It hasn't been tested yet.<br>
<br>
--Bart<br>
<br>
<br>
On 4/3/2014 7:55 PM, Dean Gibson AE7Q wrote:<br>
</div>
<blockquote cite="mid:533E1F23.2070805@ae7q.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
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=ISO-8859-1"
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=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>
<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>
</blockquote>
</blockquote>
<br>
</body>
</html>