Zamiast zezwalać zewnętrznym, potencjalnie złośliwym komputerom klienckim na bezpośrednią komunikację z serwerami i klientami w sieci firmowej, czasami lepiej jest skierować je do innego serwera proxy lub hosta bastionu. Host bastionu (rysunek 2.9) to po prostu standardowy komputer, niekoniecznie szczególnie wydajny (na przykład 486-DX66 z zaledwie 16 MB pamięci), który działa jako bariera między światem zewnętrznym a bezpieczną siecią wewnętrzną
Posiada dwie karty sieciowe i dwa adresy IP. Serwer otrzymuje żądania ze świata zewnętrznego, ale musi następnie poprosić klienta o zweryfikowanie przekazania żądania do bezpiecznej aplikacji. Żadne pakiety IP nie przechodzą bezpośrednio. Prawidłowo skonfigurowany zapewnia wysoki stopień bezpieczeństwa. Można go również skonfigurować do przechowywania rejestru przechodzących wiadomości, ustanawiając w ten sposób pełną ścieżkę audytu do monitorowania bezpieczeństwa online lub offline. Bastiony są szczególnie dobre do implementacji bram aplikacji, ponieważ możliwe jest przeprowadzanie złożonych kontroli zawartości wiadomości, które przez nie przechodzą, na przykład w celu uniknięcia wirusów e-mail. Jedno podejście, SOCKS, opracowane przez Internet Engineering Task Force (IETF), zapewnia standardowy sposób zezwalania bezpiecznym aplikacjom na działanie przez zaporę. Każda taka aplikacja wymaga poddania się procesowi skarpetkowania. Pierwotnie oznaczało to, że aplikacja musiała zostać ponownie skompilowana i połączona z zestawem funkcji bibliotecznych SOCKS. Było to skomplikowane i czasochłonne. Ostatnio, biblioteki dołączane dynamicznie, które działają w czasie wykonywania, usunęły ten problem, przynajmniej w przypadku aplikacji Windows. Wciąż jednak toczy się debata na temat tego, czy SOCKS są konieczne i/lub pożądane w dłuższej perspektywie.