<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<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>
<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>