Community discussions

MikroTik App
 
AlexN
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 82
Joined: Thu Feb 18, 2010 11:02 am

MikrotTik NAT doesn't masquerade some packets

Tue Feb 12, 2013 6:45 pm

Hi.
Recently I've noticed that some packets form my clients behind NAT-route going through it without being masqueraded. After a closer look I discovered that packets with flags FIN, RST or PSH are affected. Looks like my clients have no any issues according to this matter but I'm concerned about garbage going through WAN interface. Why is this happening? Is it something that I do not understand so far or is it a bug?

Thank you in advance.
 
psamsig
Member Candidate
Member Candidate
Posts: 161
Joined: Sun Dec 06, 2009 1:36 pm
Location: Denmark

Re: MikrotTik NAT doesn't masquerade some packets

Wed Feb 13, 2013 11:26 pm

My guess would be that the connection has timedout in the connection-tracking (IP -> Firewall -> Connections push 'Tracking') that handles NAT, there are quite a number of timeout settings in there to play with, but so far I haven't really found any good description of what and why (and why not) to change these settings.
 
AlexN
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 82
Joined: Thu Feb 18, 2010 11:02 am

Re: MikrotTik NAT doesn't masquerade some packets

Thu Feb 14, 2013 10:27 am

Thank you for your reply. Problem looks like has been solved thanks to MT support. Those packets didn't belong to established connections so adding filter rule to drop connections with invalid state looks like helped. Now I'm interesting what is the cause of generation of "wrong" packets at the client side. Bad TCP/IP realization? Anyway in my case it did not look like as something nasty. Almost in all cases it were packets with ACK/FIN flags destined to some web server.
 
psamsig
Member Candidate
Member Candidate
Posts: 161
Joined: Sun Dec 06, 2009 1:36 pm
Location: Denmark

Re: MikrotTik NAT doesn't masquerade some packets

Thu Feb 14, 2013 10:34 am

The reason I answered was that I have just resently seen something quite similar, when tracking problems with a HTTP based webservice, and in my case I got rid of it (without really understanding the root cause) by changing the HTTP session from 'Connection: Keep-Alive' to 'Connection: Close'. I wrote it off as something NAT state timeout issue, but was reluctant to meddle with the defaults for already stated reasons.

Who is online

Users browsing this forum: No registered users and 19 guests