@micsu: They might have been blocked -- but the access log will still show the visits even when the user is blocked from logging in. You will still even see an HTTP status code "200" in your logs if they were blocked by the limits you set, or you may see a "503" status code if they were blocked by the Wordfence security network.
In my access logs, though, I found that I can see if the blocking was working because the document size shown in the logs is different when a login is blocked. For example, I might see something like this in my access_log -- I trimmed IP, date, referrer, etc. so it's short enough to be readable here:
"POST /wp-login.php HTTP/1.0" 200 17904
"POST /wp-login.php HTTP/1.0" 200 17904
"POST /wp-login.php HTTP/1.0" 200 17904
"POST /wp-login.php HTTP/1.0" 200 2377
"POST /wp-login.php HTTP/1.0" 200 2377
"POST /wp-login.php HTTP/1.0" 200 2377
"POST /wp-login.php HTTP/1.0" 200 2377
"POST /wp-login.php HTTP/1.0" 200 2377
"POST /wp-login.php HTTP/1.0" 200 2377
So, in the first 3 POSTs, they were getting the full login form and failure message as a response from wp-login.php, but after that, they got a shorter message from Wordfence.
It's hard to test it if you've whitelisted your own IPs, but if you can log in as a bad user from a different IP until you get the message, you can see how the message looks in your browser, and see the size of the blocked attempts in your logs.