Page 1 of 1

Martian packets

Posted: Sat Jul 21, 2018 7:10 pm
by mobdoc
I have a number of Mikrotik mAP2n boxes running a hotspot server, each connected to an SXT Lite which connects to an Omnitik which has the internet connection. The Omnitik acts as a DHCP server handing out addresses in the range 10.0.0.0/24. The SXT Lites and mAP2ns all use DHCP client to obtain an address from the Omnitik. The mAP2n boxes then act as routers with their own DHCP server handing out addresses to local clients in the range 192.168.86.0/24. The mAP2n boxes NAT all outbound traffic using the interface connected to the SXT lites. So far so good.

My problem is that I am seeing packets on the Omnitik that have source addresses in the range 192.168.86.0/24. This should not be possible as all outbound traffic from the mAP2n should be NATted as there is a firewall NAT rule
/ip firewall nat
add action=masquerade chain=srcnat comment="default configuration" out-interface=ether1-gateway to-addresses=0.0.0.0
I started investigating this as the internet router is logging hundreds of martian packets with source addresses in the local range from the mAP2n and it is causing problems with the router.

Can anyone suggest why this is happening (all boxes are running V6.42.6)

Thanks
Steve

Re: Martian packets

Posted: Sat Jul 21, 2018 10:26 pm
by sindy
I don't say it really happens, but if the Omnitik sends a packet to a 192.168.86.0/24 to one of the SXT's WANs, and the SXT!s firewall doesn't filter out or redirect such packet, and something on that address listens and responds, the masquerade rule will not affect the response and the connection tracker will keep it open.

Just a minor remark - the to-addresses parameter is only relevant for action=src-nat; action=masquerade ignores it.

Re: Martian packets

Posted: Sat Jul 21, 2018 11:51 pm
by mobdoc
Hi sindy,

Thanks for your reply and the comment regarding the to-address parameter. I haven't added that to my rule but it does appear when you do a /ip firewall nat export.

I don't think it is the Omnitik that is sending the packets as the source address is 192.168.86.xxx and the destination address is always a public IP on the internet. The problem is the main border router is logging these packets and it is causing a huge overhead on that device. I am now in the process of filtering them out before they reach the border which should solve my problem but it is really just masking the issue instead of eradicating it.

It also looks like I am only getting the issue from devices that have the hotspot enabled. My network includes a lot of mAP2n devices that are not part of the hotspot system and I do not seem to get the issue from these devices. Comparing the configuration shows that the only difference is the hotspot related elements.

Thanks
Steve

Re: Martian packets

Posted: Sun Jul 22, 2018 12:10 am
by sindy
I don't think it is the Omnitik that is sending the packets as the source address is 192.168.86.xxx and the destination address is always a public IP on the internet.
In the scenario I was talking about, the Omnitik would be sending packets with destination address 192.168.86.xxx, and responses to them would have source address 192.168.86.xxx because they would escape the src-nat rule on the SXTs. But as you say the dst-addresses of these "would-have-to-be-response" packets are public ones, the reason why they occur is not this scenario.

It also looks like I am only getting the issue from devices that have the hotspot enabled. My network includes a lot of mAP2n devices that are not part of the hotspot system and I do not seem to get the issue from these devices. Comparing the configuration shows that the only difference is the hotspot related elements.
In that case, look at the output of /ip firewall nat print chain=srcnat (not export, but really print). The hotspot astro clock adds some "dynamic" rules, and it could be than one of these precedes and shadows the action=masquerade rule you've quoted for some packets, thus allowing them to escape it. export only shows static configuration items, print shows also the dynamically added ones.