Port forwarding issues (SYN not getting acked)

RouterOS Beginner Basics
1

I have the following high level config:
One AP Groove connected to LAN1 (192.168.88.0/24) and the internet
One station Groove setup such that WLAN is WAN and ETH is LAN2. LAN2 has no DHCP, all the devices have static IPs of 192.168.90.0/24. I have NAT enabled, and ultimately, I just want to port forward to expose a couple of ports on a couple of the devices on LAN2. The idea here is that LAN2 is a number of devices on a mobile robot, and using firewall + NAT with port forwards for select services encapsulates that network such that the entire robot appears as one device on the network (the Mikrotik Groove is of course masquerading the MAC)

I have port forwards for SSH on a box on LAN2 and then a couple of TCP socket servers. SSH works great, but the TCP socket servers (Tested with Apache2, just to make sure that it’s not an issue in my code) all time out on the LAN1 side, because SYN is not acked. I’m pretty sure this is an issue with the response not getting routed back, but I’m not sure if I have an error in my network config elsewhere.

I realize my firewall rules aren’t doing much yet. For now, I have things set loosely for debugging.

Any ideas on what I might be screwing up here?

/interface wireless
set [ find default-name=wlan1 ] band=5ghz-a/n/ac channel-width=20/40/80mhz-XXXX disabled=no frequency=auto installation=outdoor ssid=xxx station-roaming=enabled
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa2-psk eap-methods="" mode=dynamic-keys supplicant-identity=MikroTik wpa2-pre-shared-key=xxx
/ip hotspot profile
set [ find default=yes ] html-directory=flash/hotspot
/ip pool
add name=default-dhcp ranges=192.168.88.10-192.168.88.254
/ip dhcp-server
add address-pool=default-dhcp interface=ether1 name=defconf
/user group
set full policy=local,telnet,ssh,ftp,reboot,read,write,policy,test,winbox,password,web,sniff,sensitive,api,romon,dude,tikapp
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add comment=defconf interface=ether1 list=LAN
add comment=defconf interface=wlan1 list=WAN
/ip address
add address=192.168.90.1/24 interface=ether1 network=192.168.90.0
add address=192.168.88.10/24 interface=wlan1 network=192.168.88.0
/ip dhcp-client
add disabled=no interface=wlan1
/ip dhcp-server network
add address=192.168.88.0/24 comment=defconf gateway=192.168.88.1
/ip dns
set allow-remote-requests=yes
/ip dns static
add address=192.168.90.1 name=router.lan
/ip firewall filter
add action=accept chain=input
add action=accept chain=forward
add action=accept chain=output
add action=accept chain=input in-interface=wlan1 protocol=icmp
add action=drop chain=input connection-state=invalid
add action=accept chain=input connection-state=established
add action=drop chain=forward connection-state=invalid
add action=accept chain=forward connection-state=established
add action=accept chain=forward connection-state=related
/ip firewall nat
add action=masquerade chain=srcnat ipsec-policy=out,none out-interface-list=WAN
add action=dst-nat chain=dstnat dst-port=222 protocol=tcp to-addresses=192.168.90.4 to-ports=22
add action=dst-nat chain=dstnat dst-port=7610 protocol=tcp to-addresses=192.168.90.2 to-ports=7610
add action=dst-nat chain=dstnat dst-port=9689 protocol=tcp to-addresses=192.168.90.2 to-ports=9689
add action=dst-nat chain=dstnat protocol=tcp src-port=8080 to-addresses=192.168.90.4 to-ports=80
/system clock
set time-zone-name=America/Los_Angeles
/system identity
set name=Robot0
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN
2

Last dstnat rule doesn’t look right, you probably want dst-port=8080 and not src-port=8080. There’s nothing wrong with other two, but as they are going to different address, maybe it’s problem with that device. It could be missing default gateway via this router or firewall on device.

3

The config smells funny.
Why is your WAN the WLAN1 have the DHCP setup instead of ether1 your LAN setup.

Your dstnat rules are missing in-interface-list=WAN (Besides the already noted src nat being wrong)

Finally why did you frig with the default firewall rules.
What you have is horrible unless you really dont require firewall rules??

4

@sob oops! Yes so this works now.

@anav:

Why is your WAN the WLAN1 have the DHCP setup instead of ether1 your LAN setup.
The AP has a DHCP server on the network, so I let it have a DHCP lease in addition to its static address.

Finally why did you frig with the default firewall rules.
What you have is horrible unless you really dont require firewall rules??"
I was having issues setting up the Groove to begin with and castrated to rules to 100% rule out any other issues. This is def not production config.

Your dstnat rules are missing in-interface-list=WAN (Besides the already noted src nat being wrong)
Do you mean the dst port from sob’s post or the actual srcnat rule to masquarade? Now that I fixed the dstport issue this does actually work now for apache2, but not for one other device on the network which is an embedded device running LwIP. So it must be something specific to that :confused: Requests to that socket server work fine on the lan, just not through the fwd.

5

So Apache2 works on 8080 → 80, but still trying to figure out what is going on with the port forwards for the embedded device. Adding the src interface for the nat rules didn’t help. I can see the packet exchange going on in torch:

Any ideas? I’m not really sure if there is an issue on the embedded LWIP side or the router config or both.
Capture.PNG

6

If you don’t want to miss any packet, you can use logging rules like:

/ip firewall mangle
add action=log chain=postrouting dst-address=192.168.90.2
add action=log chain=prerouting src-address=192.168.90.2

and you’ll be able to see all requests and responses (or lack of them).

Adding in-interface won’t help you with this, but you do want it for the future. Either that or dst-address=192.168.88.x, where address is the one you’re connecting to. It’s because current rules match all packets, no matter what is their destination, so it will affect even traffic from 192.168.90.x, if device tries to connect to anything else using same ports as you have in dstnat rules.

7

Thanks Sob!

I actually managed to figure this one out. The embedded target (LWIP) cares about the default gateway field being populated. I’m not entirely sure why, though. The correct routing should be taken care of by NAT, but it works and I can investigate it with mangle marking. Remember, this works fine with the request on the same LAN. The whole idea of NAT is that there isn’t any special routing or anything because the destination and source addresses are modified going in and out, correct? The response destinations from the embedded target should have their destination as 192.168.90.1, correct?

Thanks all! All fixed for now

8

All devices care about gateway. If you have device with 192.168.90.x/24 and no gateway, then it’s just other 192.168.90.y addresses that are accessible to it. It needs another device (router) to access anything else. And it must know where to find this router.

This would work without gateway if you had additional srcnat rule:

/ip firewall nat
add chain=srcnat out-interface=ether1 action=masquerade

It would change source of all requests from elsewhere to 192.168.90.1 and that would be reachable in device’s /24, so it would know where to send response.