take a brush, made from the areaportal texture, and make it into a func_areaportal entity. this is non solid and invisible in-game. it works something like this.

when you are looking through a func_areaportal, the engine will do real time calculations of the faces that can be seen, and render only them. this causes an extra load on your system, and how much that is will depend on the scene being rendered. (the portal is open)

when the func_areaportal is not in your line of sight, then everything behind it gets dropped from all 'what can we see' calculations. (the portal is closed)

if you have an areaportal inside a door, then because the door isn't a vis blocker even when it's closed, the portal would normally still be considered viewable and would remain open. however, the areaportal properties allow you to name a door, and when the door is in an open or closed state, then the areaportal is forced to follow.

[post edited after i realised i'd been talking bollocks again]

a very important point to remember when using areaportals of any description, is that the area you seal with it must be 'leak-free' from any other sealed area. for example, if you made a corridor that went around in a big circle, and only used one func_areaportal(or door with a areaportal textured brush tied inside), then you'd get an error. this is because the ant that does the calculations for the engine gets disoriented, and doesn't understand how the same door is at both ends of the same corridor. this is when it starts running around making messy marks on your compile log.

when you use two or more areaportals, then the ant can go about its business, and take notes that portal1 is between the back of doors 1 and 2, and portal2 is in front of them etc.

and please dont leave cracks or gaps that the little guy will crawl through, he's got a hard enough time as it is.