If the subscriber can't connect to Laserfiche, when the connection is re-established, it checks the activity log for the last event it processed and picks up from there. If the subscriber is receiving events from LF, it checks them against its cached copy of the rules and queues them up for processing using MSMQ. The Workflow Server picks up works from the queue. So if the WF Server is down but the subscriber is running, the work gets queued up. There are size limits on the queues since they're written to disk, so there is a chance of losing data with prolonged outages.

The Subscriber refreshes its copy of the rules periodically, so if it can't connect to the WFServer, it may process events against outdated rules. However, since the reason for not being able to connect to the WF Server is most likely because the server is down, the chances of new rules being published is virtually zero.

I'm not very familiar with network inner workings, but in the situation you describe above, I don't think Workflow was affected at all since all of the communication needed for getting events from the Laserfiche Server and performing Workflow actions would be from WF going out, there wouldn't be any connections coming in. Now, things like starting business processes from the Client of Web Access would be affected since they'd be calling into the Workflow Web Service. Still, that would be by name by default, not by IP, so as long as the DNS knew how to find it, it should still work.