[HamWAN PSDR] Mikrotik port forwarding

[Dean Gibson AE7Q]

Connection tracking was on from the start.  The solution is to use 
masquerading properly, not to rape the routing table.

On 2014-04-03 22:40, Bart Kus wrote:
> 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
>>

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