Page 1 of 1
NATted connections have RST packet sent to LAN for no reason
Posted: Mon Dec 17, 2012 4:21 pm
by silviot
Hi,
I have a RB450G between a small office LAN (10-20 users) and a 100Mb ISP line to the Internet.
Since some time connections started being dropped after a certain amount of time. A RST packet is generated on the router and sent to my LAN host. The other host doesn't notice the connection has gone down (I see "still logged in" for dropped ssh connections). The amount of time a connection will stay open seems to vary from day to day but to be consistent in experiments repeated over a short amount of time; it's between 5 minutes and 120 minutes. I currently have no connections older than 120 minutes.
The rule I use for masquerade is:
chain=srcnat action=masquerade to-addresses=192.168.0.2 src-address=192.168.1.1-192.168.1.255 out-interface=ether1-gateway
I'm pretty sure all this started when I upgraded to routeros 5.22 from 5.5. I'd love to downgrade to verify my hypothesis, but I wasn't able to download it from the official mikrotik page.
I upgraded to 6.0rc5 with no luck.
This is driving me and my users crazy. Nightly Backups often don't complete, skype sessions are a PITA... well, you can imagine.
My problem seems similar to
http://forum.mikrotik.com/viewtopic.php?f=2&t=61826 but reversed (the RST packet hits my LAN but not the remote server).
I will have to switch to some other device if I can't fix this quick, just as the OP of that thread had to do.
Regards,
Silvio
Re: NATted connections have RST packet sent to LAN for no re
Posted: Tue Dec 18, 2012 11:33 am
by tomaskir
Dont rely on the v6 RCs, they still have quite a few bugs. Try 5.21, but I would guess your problem is somewhere other then the ROS version.
How are your timers in "/ip firewall connection tracking print"
Re: NATted connections have RST packet sent to LAN for no re
Posted: Tue Dec 18, 2012 3:41 pm
by silviot
Dont rely on the v6 RCs, they still have quite a few bugs. Try 5.21, but I would guess your problem is somewhere other then the ROS version.
How are your timers in "/ip firewall connection tracking print"
I just found some unofficial source for old packages. I hope it's true that the routerboard will refuse to install a tampered binary (as I read somewhere) so getting those npk from an untrusted source should not be a problem. I'll try to downgrade.
My timers are (I already tried raising them):
[admin@RB450G] > /ip firewall connection tracking print
enabled: yes
tcp-syn-sent-timeout: 15s
tcp-syn-received-timeout: 15s
tcp-established-timeout: 2d
tcp-fin-wait-timeout: 20s
tcp-close-wait-timeout: 20s
tcp-last-ack-timeout: 30s
tcp-time-wait-timeout: 30s
tcp-close-timeout: 30s
udp-timeout: 40s
udp-stream-timeout: 15m
icmp-timeout: 10s
generic-timeout: 10m
max-entries: 480832
total-entries: 1459
Re: NATted connections have RST packet sent to LAN for no re
Posted: Tue Dec 18, 2012 3:57 pm
by coffeecoco
Hi,
I have a RB450G between a small office LAN (10-20 users) and a 100Mb ISP line to the Internet.
Since some time connections started being dropped after a certain amount of time. A RST packet is generated on the router and sent to my LAN host. The other host doesn't notice the connection has gone down (I see "still logged in" for dropped ssh connections). The amount of time a connection will stay open seems to vary from day to day but to be consistent in experiments repeated over a short amount of time; it's between 5 minutes and 120 minutes. I currently have no connections older than 120 minutes.
The rule I use for masquerade is:
chain=srcnat action=masquerade to-addresses=192.168.0.2 src-address=192.168.1.1-192.168.1.255 out-interface=ether1-gateway
I'm pretty sure all this started when I upgraded to routeros 5.22 from 5.5. I'd love to downgrade to verify my hypothesis, but I wasn't able to download it from the official mikrotik page.
I upgraded to 6.0rc5 with no luck.
This is driving me and my users crazy. Nightly Backups often don't complete, skype sessions are a PITA... well, you can imagine.
My problem seems similar to
http://forum.mikrotik.com/viewtopic.php?f=2&t=61826 but reversed (the RST packet hits my LAN but not the remote server).
I will have to switch to some other device if I can't fix this quick, just as the OP of that thread had to do.
Regards,
Silvio
so I cant be certain because I dont know if mikrotik will auto exclude gateway and broadcast address's
but instead of using src 192.168.1.1-192.168.1.255 try 192.168.1.0/24
and as far as i can work out that masq rule will only NAT traffic with /24 src address and the packet must have a dest address of 192.168.0.2 ..... looks odd....
all the rest of the traffic will probably go out the relevant route in the Route table guessing... 0.0.0.0 unless there is a defined routed of 192.168.0.2 in there...
i guess i am suggesting to you. remove the dst address and try again
Re: NATted connections have RST packet sent to LAN for no re
Posted: Tue Dec 18, 2012 4:08 pm
by tomaskir
@coffeecoco
Its a "to-address" parameter for the "action=dst-nat". It tells the dst-nat rule what IP to use for NATing.
It has nothing to do with dst-address of the packets.
@silviot
But yes, that parameter is not used for "action=masquarade", so its strange that you have it in your command.
@coffeecoco
As for using an IP range rather then specifying a subnet, that is fine as well.
@silviot
How does your firewall look? post the "/ip firewall filter export compact" please.
Re: NATted connections have RST packet sent to LAN for no re
Posted: Tue Dec 18, 2012 4:37 pm
by silviot
@silviot
But yes, that parameter is not used for "action=masquarade", so its strange that you have it in your command.
It's in fact a leftover. I use winbox and my original rule was a srcnat: the router has both 192.168.0.1 and 192.168.0.2; the latter is NATted by my ISP to a publicly reachable IP; the former is natted to an IP shared among ISP customers. Since I want to support Upnp I want natted connections to go out through my own public IP, hence 192.168.0.2.
When I changed in winbox the Action from srcnat to masqueade (in an attempt to debug the RST problem) the old to-address parameter was hiddent in winbox interface but is still there in text dumps. Anyway removing it doesn't solve the problem (I just tried).
@silviot
How does your firewall look? post the "/ip firewall filter export compact" please.
My firewall is empty. Yesterday I added these two rules to prevent a goflex nas to open low ports via upnp. I'm positive they don't have anything to do with the RST problem.
/ip firewall filter
add action=reject chain=input dst-port=1900 protocol=udp reject-with=icmp-port-unreachable src-address=192.168.1.117
add action=reject chain=input dst-port=2869 protocol=tcp reject-with=icmp-port-unreachable src-address=192.168.1.117
I didn't mention the NAT rule I posted originally is not the only one. Here's the complete list:
/ip firewall nat
add action=masquerade chain=srcnat src-address=192.168.1.0/24
add action=dst-nat chain=dstnat dst-address=192.168.0.2 dst-port=443 protocol=tcp to-addresses=192.168.1.196
add action=dst-nat chain=dstnat dst-address=192.168.0.2 dst-port=500,1701,4500,1723,8291,1194 protocol=tcp to-addresses=192.168.1.1
add action=dst-nat chain=dstnat dst-address=192.168.0.2 dst-port=50 protocol=tcp to-addresses=192.168.1.1 to-ports=22
add action=dst-nat chain=dstnat dst-address=192.168.0.2 to-addresses=192.168.1.195
add action=masquerade chain=srcnat comment="Masquerade VPN varie" disabled=yes src-address=192.168.1.0/24
add action=netmap chain=dstnat disabled=yes dst-address=10.42.4.0/24 to-addresses=192.168.1.0/24
Re: NATted connections have RST packet sent to LAN for no re
Posted: Tue Dec 18, 2012 5:02 pm
by coffeecoco
does the issue dissapear when you turn off upnp ?
Re: NATted connections have RST packet sent to LAN for no re
Posted: Tue Dec 18, 2012 5:43 pm
by silviot
does the issue dissapear when you turn off upnp ?
Nope.
Re: NATted connections have RST packet sent to LAN for no re
Posted: Tue Dec 18, 2012 6:15 pm
by coffeecoco
does the issue dissapear when you turn off upnp ?
Nope.
I dont understand the situation enough but, im going to take a guess it has something todo with your double nat
you said the isp is natting as you are also?
It could be
a) your natting when your supposed to be. just pass the packets to the REAL nat(Router)
b) the double nat is how its designed but related to at point X nat translation table is not remaining open while other is open
c) im corrected and we think more
Re: NATted connections have RST packet sent to LAN for no re
Posted: Thu Dec 20, 2012 9:57 am
by tomaskir
I see nothing in particular which should cause a problem like this. Hows your "/ip address print" look like? (just asking to get better vision of the topology, since you netmap a subnet and use dns-nat for other IPs.)
Do the connections dissappear from router's conn track table as well after the RST packet? Is it the router or the remote host that sends the RST? If the router, is the RST sent to both ends of the TCP session or just one? Also, seems you are double NATting, are you sure the other device that NATs is all fine?
I would normally also blame this on the upnp, what rules are dynamically created by the upnp clients?
Re: NATted connections have RST packet sent to LAN for no re
Posted: Thu Dec 20, 2012 3:38 pm
by silviot
After many tries (downgrade/upgrade, change NAT rule etc) I could not solve it.
I re-checked the source of the RST packets, and it seems they come from my ISP NAT. I can sniff them on the internet-facing ethernet port of the mikrotik.
They are probably changing configs daily with a new broken config each morning (today my connections don't live more than 2 minutes).
So my initial assumption that about RB450G's fault is wrong.
Now I'll have to convince my ISP that they must fix somthing.
Thanks for your help and sorry for the noise.
I'll double check next time before asking (in fact I thought that I already did).
Silvio
Re: NATted connections have RST packet sent to LAN for no re
Posted: Thu Dec 20, 2012 4:18 pm
by janisk
to-address works for action=dst-nat or action=src-nat, while action=masquerade will randomly choose one of the addresses on the interface packets are leaving the router and use that.