I have three rules at the top of my input and forward chains for dealing with connections based on state: drop invalid, accept established, accept related.

I'm using masquerade on customer traffic coming in via ether2 and out via ether1.

In my filter logs, I see drops on the input chain for traffic that should be accepted as part of a valid connection from customer hosts on ether2. For example, SYN-ACK or FIN packets from a remote site hosting my Hotspot sign-on application. This also happens for other web sites. It doesn't happen all the time, but I'm concerned it's affecting the user experience for my customers. I've had similar problems with DNS responses being dropped, so my customers can't connect. I've had to put rules explicitly allowing traffic from my DNS and web servers to get around this problem.

The destination address in these packets is the IP on ether1 (the external address of the router). I would think that on input, the router would translate the destination back to the appropriate customer IP and send it through the forward chain, where it can match the rule for established connections. But it doesn't.

Why would this traffic be dropped on the input chain?

The INPUT chain is only used by traffic destined for the router. Customer traffic that is traversing the router will only use the FORWARD chain.

Regards

Andrew

The problem I'm seeing is that packets that should be going through the forward chain are being dropped in the input chain.

Those packets are part of connections from my internal segment, which are NAT'd in srcnat with the masquerade action. The dropped packets have the external IP of the router as the destination IP, as they should, having had their original source translated to the external IP by the masquerade rule.

does this only happen right after a reboot for about 1-4 hour period of time ? I've experienced this on a heavily used pipe - some default firewall thats installed before the real one is used or something ... happens to the 2-3 ips that are the most active while 'starting services...' the nat rules are ignored for those and they hit my input chain instead.

Do you have Connection Tracking turned on?

Regards

Andrew

changeip: no, this happens on routers that have been up for weeks or months.

andrewluck: yes, that's enabled. The state tracking generally works; this happens sporadically.

I'm still collecting firewall logs to see if some pattern emerges.

Also, possibly related: even with these rules checking connection-state, and a drop-all at the end of the input policy, I still get log messages popping up on the console for failed login attempts (to ssh and ftp) from foreign IPs. I had to add an explicit drop rule at the very top, which uses a src-address-list that these IPs are pushed into. I consider this a hack to deal with something that shouldn't occur in the first place.

I don't see anything like this. Post your NAT & firewall rules for us.

Regards

Andrew

it is the connection tracking timeout values that cause it.
your typical windows/bsd/linux tcp stack have fairly conservative timeout values compared to the routeros defaults.