I came across the question about the Nortel EAC timing out with a banner text message and thought I could shed some light on it.
I came across this myself recently as I installed a new wireless network in my house. Having been on the team that built the Nortel Contivity (though I didn't work on the client) I happen to be in a special position to understand what was going on.
The problem is basically that the Contivity server doesn't mark the tunnel as being fully up (i.e., open to user traffic) until it has delivered the banner message. It does this using the Quote-Of-The-Day (qotd) protocol.
When I encountered the banner error I noticed that when I did a "netstat -p tcp" there would be a qotd connection inside the tunnel in the SYN-SENT state. This means that the client side is trying to establish the TCP connection for the qotd service to deliver the banner, but it is not getting responses from the server.
In my case this is happening because my wireless router (SMC barricade) is dropping the encrypted packets coming from the VPN server to my client.
The problem with the SMC only happens when I have previously had a connection up successfully, then closed it down and tried to re-establish it. I can surmise that the problem with this is that they can't really detect that the tunnel is down at the router so they have some kind of long inactivity timeout. I also infer from this behavior that the way they have implemented the IPSEC pass-through support, they can only support a single tunnel to a specific destination at any one time. If I unplug the power from my SMC and plug it back in I can then establish my IPSEC tunnel to my company (since the router has forgotten all of its state).
I haven't yet figured out what the timeout on the SMC is. I just know if I disconnect my VPN and then wait "a long time" then it is successful again later.
So, back to the "banner problem". The real issue is that the tunnel traffic isn't really getting established correctly. The IPSEC association is setup but the communication flow back toward the client is broken somehow. This can happen as it does in my case because of a temporary condition in a firewall, or it can happen if there is a firewall in the path that really doesn't know how to support IPSCEC pass-through at all. For instance, if you are travelling and dialing in through some random ISP, that ISP might have private addressing in their network and the firewall in their network that you are traversing to get back to your company doesn't support IPSEC pass-through.
By the way, supporting IPSEC pass-through in a stateful manner is very tricky, and I'm not surprised that companies would have problems with it. The typical port-swapping that NAT implementation do won't work because there are no ports. The only thing the firewall can look at is a field in the ESP header called the SPI, but they can't modify it (because it is established inside the secure key-exchange that happens in the IPSEC tunnel setup).
Hope this helps.
I came across this myself recently as I installed a new wireless network in my house. Having been on the team that built the Nortel Contivity (though I didn't work on the client) I happen to be in a special position to understand what was going on.
The problem is basically that the Contivity server doesn't mark the tunnel as being fully up (i.e., open to user traffic) until it has delivered the banner message. It does this using the Quote-Of-The-Day (qotd) protocol.
When I encountered the banner error I noticed that when I did a "netstat -p tcp" there would be a qotd connection inside the tunnel in the SYN-SENT state. This means that the client side is trying to establish the TCP connection for the qotd service to deliver the banner, but it is not getting responses from the server.
In my case this is happening because my wireless router (SMC barricade) is dropping the encrypted packets coming from the VPN server to my client.
The problem with the SMC only happens when I have previously had a connection up successfully, then closed it down and tried to re-establish it. I can surmise that the problem with this is that they can't really detect that the tunnel is down at the router so they have some kind of long inactivity timeout. I also infer from this behavior that the way they have implemented the IPSEC pass-through support, they can only support a single tunnel to a specific destination at any one time. If I unplug the power from my SMC and plug it back in I can then establish my IPSEC tunnel to my company (since the router has forgotten all of its state).
I haven't yet figured out what the timeout on the SMC is. I just know if I disconnect my VPN and then wait "a long time" then it is successful again later.
So, back to the "banner problem". The real issue is that the tunnel traffic isn't really getting established correctly. The IPSEC association is setup but the communication flow back toward the client is broken somehow. This can happen as it does in my case because of a temporary condition in a firewall, or it can happen if there is a firewall in the path that really doesn't know how to support IPSCEC pass-through at all. For instance, if you are travelling and dialing in through some random ISP, that ISP might have private addressing in their network and the firewall in their network that you are traversing to get back to your company doesn't support IPSEC pass-through.
By the way, supporting IPSEC pass-through in a stateful manner is very tricky, and I'm not surprised that companies would have problems with it. The typical port-swapping that NAT implementation do won't work because there are no ports. The only thing the firewall can look at is a field in the ESP header called the SPI, but they can't modify it (because it is established inside the secure key-exchange that happens in the IPSEC tunnel setup).
Hope this helps.