[HamWAN PSDR] Mikrotik port forwarding

[Bart Kus]

Right on!

I'm glad you were able to diagnose and solve the problem with minimal 
assistance!

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.

--Bart


On 4/3/2014 7:55 PM, Dean Gibson AE7Q wrote:
> 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
>
>
>
> _______________________________________________
> PSDR mailing list
> PSDR at hamwan.org
> http://mail.hamwan.org/mailman/listinfo/psdr_hamwan.org

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