[HamWAN PSDR] Mikrotik port forwarding

[Dean Gibson AE7Q]

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.

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? *DROP.*

I needed a second masquerading line, show below in red.  Works!

On 2014-04-03 18:11, Bart Kus wrote:
> 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.
>
> 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.
>
> Please report back!
>
> --Bart
>
>
> On 04/03/2014 05:17 PM, Dean Gibson AE7Q wrote:
>> 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.
>>
>> Firewall rules in the radio (rules #3 & #7 in the filter chain, and 
>> rule #1 in the NAT chain, have been inserted by me):
>>
>> //ip firewall filter print
>> Flags: X - disabled, I - invalid, D - dynamic
>>  0   ;;; default configuration
>>      chain=input action=accept protocol=icmp src-address=44.0.0.0/8
>>
>>  1   ;;; default configuration
>>      chain=input action=accept connection-state=established
>>
>>  2   ;;; default configuration
>>      chain=input action=accept connection-state=related
>>
>>  3   chain=input action=accept protocol=tcp 
>> in-interface=wlan1-gateway dst-port=26
>>
>>  4   ;;; default configuration
>>      chain=input action=drop in-interface=wlan1-gateway
>>
>>  5   ;;; default configuration
>>      chain=forward action=accept connection-state=established
>>
>>  6   ;;; default configuration
>>      chain=forward action=accept connection-state=related
>>
>> 7   chain=forward action=accept protocol=tcp 
>> in-interface=wlan1-gateway dst-port=26
>>
>>  8   ;;; default configuration
>>      chain=forward action=drop connection-state=invalid
>>
>> /ip firewall nat print
>> Flags: X - disabled, I - invalid, D - dynamic
>>  0   ;;; default configuration
>>      chain=srcnat action=masquerade to-addresses=0.0.0.0 
>> out-interface=wlan1-gateway///
>> ///1 chain=srcnat action=masquerade to-addresses=192.168.0.250 
>> protocol=tcp out-interface=ether1-local dst-port=26/
>> //
>> /2  chain=dstnat action=dst-nat to-addresses=192.168.0.250 
>> protocol=tcp in-interface=wlan1-gateway dst-port=26/
>>
>> 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.
>>
>> Ideas welcome (note that "action=masquerade" is not valid in a dstnat 
>> chain).
>>
>> -- Dean

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.hamwan.net/pipermail/psdr/attachments/20140403/facc71b6/attachment.html>