NATed addresses showing up in a torch

RouterOS Wireless Networking
1

I have several wireless towers with Mikrotik routers broadcasting and Mikrotik clients connecting. This is an example of what I’m seeing and I’m hoping someone has seen this and can point me in the right direction.

Example IP in my AP: 200.200.200.254/24

Example IP in the Mikrotik client radio: 200.200.200.15/24

Masquerade DHCP server in the client radio handing out addresses like 10.10.10.10/24

The torch in my AP Mikrotik sees the 10.10.10.10 address of a client’s PC, masqueraded in the client radio.

Why would the tower see the 10.10.10.10 address that’s in the client radio? :open_mouth:

2

Probably it’s because of the “invalid” packets, for example - TCP packets sent after the connection is finished (FIN). You should block “invalid” packets in the beginning of the firewall filter (on each router that has connection-tracking enabled), as in the example from http://wiki.mikrotik.com/wiki/Manual:IP/Firewall/Filter#Customer_protection :

/ip firewall filter
add chain=forward protocol=tcp connection-state=invalid \
 	action=drop comment="drop invalid connections"  
add chain=forward connection-state=established action=accept \ 
 	comment="allow already established connections"  
add chain=forward connection-state=related action=accept \
 	comment="allow related connections"

Just drop packets with connection-state=invalid on the client radios. If the 10.10. addresses disappear from the torch on AP completely - there is a little “+” button near my karma waiting :wink: .

I had the same problem, my MT router kept sending packets with private addresses, although there was NAT on the outgoing interface, so everything “should” be NATted. I couldn’t imagine, why was that possible - so I finished sniffing everything and then analyzing in WireShark… And the packets were mainly “doubled” TCP-FIN packets, probably treated by MikroTik as “invalid”. If a packet is invalid, it doesn’t belong to any connection, and - so - cannot be NATted (as NAT is working on connections in connection-tracker). The rule always suggested by MikroTik (first rule of /ip firewall filter, chain=forward, connection-state=invalid, action=drop) solved the case :slight_smile:.

I think that your problem is the same. Torch shows only outgoing and single packets from the addresses, not carrying much data.