PacketiX VPN 4.0 の強力なファイアウォール貫通機能の解説
今日は久しぶりに VPN に関する記事を書こうと思います。
一昨日 (11/26)、PacketiX VPN 4.0 の RC1 をリリースしました。 このバージョンではいくつかの面白い機能を追加しました。
追加された機能のうち、『IPsec や MS-SSTP, OpenVPN, EtherIP, L2TP, L2TPv3 などの新しいプロトコルのサポート』が最も大きな進化点となると思います。iPhone や iPad、Android、Windows Mobile などのモバイル端末や、Mac、そしてこれまで OpenVPN を使用していたパソコンなどすべての VPN クライアントデバイスが、PacketiX VPN Server にまとめて VPN 接続できるようになりました。これにより、iPhone 向けには Cisco、OpenVPN クライアント向けには OpenVPN Server, Microsoft の Windows 向けには Windows Server 2008 の SSTP サーバー、・・・ という具合にデバイス向けに別々の VPN サーバーシステムを用いて構築していた従来の VPN サーバーを、たったの 1 台の「PacketiX VPN Server」に統合することができます。この機能については こちら をご覧ください。
その他の新機能のうち次に重要なのが『接続性の向上、ファイアウォールの貫通』というものです。これについては公式サイトの解説ページもありますが、今日の日記ではこの新機能の利便性を解説したいと思います。
VPN の NAT トラバーサル (UDP ホールパンチング) 機能
SoftEther が話題になった理由は、「社内のパソコンを VPN クライアントにして、社外の VPN サーバーに HTTPS プロトコルに乗せた VPN 通信が簡単に可能である」という特徴によるものでした。これは確かに画期的なことでした。
しかし、SoftEther によって、たとえば「自宅に立ち上げた VPN サーバー」に「社内の VPN クライアント」から接続することは簡単にできても、その逆は簡単にはできませんでした。つまり、「自宅の VPN クライアント」から「社内の VPN サーバー」に接続するためには、以下のような少し難しい設定が必要でした。
SoftEther 1.0 やこれまでの PacketiX VPN では、社員が社内 LAN などのプライベートネットワークに VPN サーバーを立ち上げたいと思った場合、インターネットとの間に NAT やファイアウォールがある場合 (ほとんどの場合) はインターネット側からのアクセスがあったときに TCP ポートを転送する設定 (ポートフォワーディング、ポート転送、DMZ などと呼ばれます) を行う必要があったと思います。PacketiX VPN だけではなく、他社の VPN (Microsoft や Cisco のもの、OpenVPN などほぼすべて) を利用する場合もそのようになっていました。
しかし、ポート転送を行うためには NAT となっているルータの設定画面にログインして難しい設定を行う必要があります。初心者にとってルータの設定画面は大変危険です。VPN のためのポートを開放しようとする操作を誤って、他のポート (135 番など) も開放してしまうかも知れません。そうするとインターネット上からワームのパケットが飛んできて、危険極まりない状態になります。
そこで、PacketiX VPN 4.0 では、『NAT トラバーサル (UDP ホールパンチング) 機能』を実装しました。これにより、たとえ社内のプライベート LAN 上に VPN Server を立ち上げる場合であっても、NAT やファイアウォールの設定を一切変更 (穴開け) することなく、社外の VPN Client から社内の VPN Server にとても簡単にアクセスできます。実際に こちらからダウンロード してやってみてください。これまでルータの設定画面と格闘しなければならなかったのが、今回のバージョンで本当に全く何もしなくても VPN がつながることに驚かれると思います。
この NAT トラバーサル機能を図に説明すると、以下のようになります。
左が従来の手法、右が今回新たに実装された手法です。従来は VPN は TCP (HTTPS) に乗っていましたので、ルータ側で少なくとも TCP ポートを 1 個開けてやる必要がありました。そして、そのポートをプライベート LAN 上の VPN Server が動作しているパソコンにフォワードする必要がありました。
いっぽう、新しい手法では「Reliable UDP」(内部名称) という UDP トンネルプロトコルが実装されています。このトンネルプロトコルは UDP パケットで構成されますが、実際にはその中に TCP と類似したストリームが流れるようになっています。TCP と同様に確認応答やシーケンス番号などの仕組みもあり、パケットロスが発生した場合でもストリームがおかしくなることはありません。このストリームの中に SSL (TLS v1) を流してします。ユーザー認証や暗号化などに必要なセキュリティ通信の確立は SSL に任せてあります。つまり、この部分は SSL over UDP のようなものです。
トンネリングプロトコルを TCP から UDP に変更すると、「UDP ホールパンチング」または「NAT トラバーサル」というテクニックを使って、外側からファイアウォールの内側との間で UDP チャネルを確立することができます。この手法は TCP でも本当はできるのですが、OS のプロトコルスタックをいじる必要があり、実装が困難でした。UDP であれば通常のソケット API を駆使することで実現ができました。Reliable UDP を UDP ホールパンチングを用いていったん社内の目的となる VPN サーバーに到達させれば、それ以降は UDP セッションが NAT やファイアウォール上のメモリ上でエントリとして維持され、安定した VPN 通信が可能となります。
VPN が確立されるまでの間は SSL over UDP を用いますが、いったん VPN が構築された後は、VPN のペイロードパケットを流す場合は確認応答は不要ですので省略しています。この場合は SSL で交換した鍵を用いて IPsec の ESP と同様に各パケットのデータグラムを暗号化、署名して伝送します。パケットの確認応答が不要な分、実は今回の新しい over UDP のほうが、単にファイアウォールを通過だけるだけでなく、従来の over TCP よりもスループットが出やすいという特徴があります。
この「UDP ホールパンチング」により、社員が会社内のパソコンに VPN Server をインストールすれば、単にそれだけで、後は自宅や出張先などから VPN 接続をすることができます。SoftEther 1.0, PacketiX VPN 2.0・3.0 で不可能であった「NAT やファイアウォールの設定を変更せずに、LAN 内に VPN サーバーを置いて公開する」ということが 4.0 でようやく実現したのです。
ダイナミック DNS 機能 ('*.softether.net')
上記の UDP ホールパンチングを有効にした (デフォルトで有効になってします) VPN Server を会社のパソコンにインストールしてから自宅に帰宅したときに、会社のパソコンに VPN 接続するためには、会社の LAN がインターネットに接続されているところのグローバル IP アドレスの入力が当然必要です。会社の現在のグローバル IP アドレスは、たとえば自分が会社にいる間に IP アドレス確認くん などにアクセスすることで取得でき、それをメモしておけばだいたいは間に合うのですが、ときどき、突然グローバル IP アドレスが変化してしまう場合があります。もし会社のインターネット接続が「固定 IP アドレスプラン」で ISP に接続されている場合はグローバル IP アドレスが変化する心配はありませんが、多くの会社では Web サーバーを同一の回線で運用するといった予定がない場合は「可変 IP アドレスプラン」を契約している場合が多いでしょう。このような場合に、会社の現在の IP アドレスを、自宅に帰宅した後でも知ることができれば便利です。
そこで、PacketiX VPN 4.0 には新たに「ダイナミック DNS 機能」を搭載しました。VPN Server 側にダイナミック DNS の設定をしておけば (設定は簡単です)、「好きなホスト名.softether.net」というホスト名と、現在の会社の LAN のグローバル IP アドレスとが関連付けられます。
そして自宅に帰り、先ほどの「好きなホスト名.softether.net」というホスト名を宛先として VPN クライアントに入力して接続設定を行い、「接続」をクリックすると、会社の自分が立ち上げた VPN サーバーに接続されます。
「ダイナミック DNS 機能」はこれまで色々な会社が小額料金やフリーで提供してきました。しかしどれも設定方法が異なり、たいていの場合は英語で設定する必要がありました。また、変な常駐アプリをインストールしておく必要がありました。こういった状況のため「ダイナミック DNS 機能」は初心者にとって敷居が高いものだったと思います。PacketiX VPN 4.0 では以下の画面のように、VPN Server の設定ツールにダイナミック DNS が統合されましたので、初心者の方でも簡単に設定できます。
VPN Azure で通信を中継
上記の「NAT トラバーサル」と「ダイナミック DNS」を組み合わせれば、ほとんどのファイアウォール・NAT を「外から内に」通過することができます。ソフトイーサで調査した結果としては、日本にある約 95.7% のファイアウォール・NAT で PacketiX VPN 4.0 の NAT トラバーサルを通過します。いっぽう、4.3% のファイアウォール・NAT では NAT トラバーサルがうまく機能しないようです。
この残された 4.3% のファイアウォール・NAT を利用しているユーザーは、本来であれば NAT トラバーサル機能を利用するためにはファイアウォール・NAT をリプレースする必要があります。しかし、ファイアウォール・NAT を交換することはとても手間です。そこで、そのようなうまく通信ができないファイアウォールでも何とか「外から内に」VPN を確立することができるようにするため、ソフトイーサでは「VPN Azure クラウドサービス」を 2012/11/26 に開始しました。
上図で一目瞭然ですが、「VPN Azure クラウドサービス」は、VPN 通信の内容に関与せずに単に VPN セッションを折り返すだけのサーバーです。VPN 専用のプロキシサーバーのようなものであると考えていただければ良いと思います。
「NAT トラバーサル」が通らない全体の 4.3% のファイアウォールであっても、「社内」から「社外」への HTTPS (Port 443) は通る場合がほとんどです。そこで、VPN Azure を利用するように VPN Server で設定すると、VPN Server は VPN Azure との間でコネクションを確立します。コネクションはそれ以降半永久的に確立され続けます。Skype や Windows Live Messenger を起動すると、ファイアウォールの内側から外側に対してずっとコネクションが確立され続けますが、それと同様です。
そして、VPN Azure に対して VPN クライアントが接続要求を出したときに、その接続要求はファイアウォールの内側にある VPN Server に転送されます。VPN Server は接続要求に対して再度ファイアウォールの「内側から外側に向かって」応答し、VPN セッションが確立されます。
VPN Azure を経由して VPN Client が VPN Server に接続する際のコントロール通信は、VPN Azure を物理的に経由します。一方、一端 VPN セッションの確立が成功した後は、データ通信 (VPN 通信の対象となるパケットのことです) は VPN Azure を経由せず、Client と Server 間で直接通信が行われます。この際には UDP が使用されます。しかし何らかの理由で UDP が使用できない場合は、VPN Azure を経由した通信が自動的に行われます。
VPN Azure はまた、Microsoft SSTP VPN サーバーの受け側としての機能も持っています。Windows Vista / 7 / 8 / RT に搭載されている Microsoft SSTP クライアントを用いて、VPN Azure を経由して社内の VPN サーバーに VPN 接続することができます。この場合はすべての通信が VPN Azure 経由となるのでスループットが落ちますが、メリットとして、クライアントパソコン側には PacketiX VPN Client をインストールする必要がないという点があります。つまり Windows に標準付属の VPN を利用できますので、インストールがとても簡単です。
詳しくは「VPN Azure クラウドサービス」の Web サイトをご覧ください。
「VPN Azure クラウド」はまだ研究開発途中のバージョンであり、学術実験プロジェクトとして筑波大学の内部に設置されています。研究が完了し、安定して動作するようになったときは、世界中のデータセンタに分散して配置される予定です。こうすれば、VPN サーバーやクライアントに最も近いデータセンターが中継ポイントとして自動的に選択されるという仕組みを実現できます。
Admin 権限がなくても VPN サーバーをインストールする機能
会社の自分のパソコンを普段は一般ユーザーとして使用している場合は多いと思います。そのパソコンに、上記のような新機能を活用して「自宅から会社に VPN 接続したい」と思った場合、VPN Server をインストールする必要があります。しかし、SoftEther 1.0 や PacketiX VPN 2.0 / 3.0 ではインストール時に Administrators 権限のユーザーである必要がありました。
これでは、たとえば会社で使っている自分のパソコンの Admin ユーザーのパスワードを忘れてしまった場合に VPN サーバーのインストールを行うことができず不便です。VPN サーバーをインストールするためだけにパソコンを再インストールして管理者ユーザーのパスワードを再設定しなければならなくなります。
このような手間を避けるために、PacketiX VPN 4.0 ではインストール時に以下のように「ユーザーモード」を選択することができるようになりました。ユーザーモードを選択すれば、Admin 権限がないユーザーでもインストールが完了し、VPN サーバーはタスクトレイに常駐します。タスクトレイのアイコンが邪魔だと感じる場合は、希望により非表示にすることもできます。(非表示にするときには、本当に非表示にして良いかどうかの確認メッセージが表示されます。)
ユーザーモードの VPN Sever プロセスはユーザー固有のスタートアップに登録されます。Windows にログオンしている間だけ動作します。ログオフすると動作は停止します。再度ログオンすると動作が再開します。実用上は、Windows にログオンしたまま、画面をロックして帰宅するのが良いと思います。
Admin 権限なしに VPN サーバーをインストールし常駐させることができる機能は、単に「Admin 権限のパスワードを忘れた場合に便利」というだけに留まりません。実は一般ユーザー権限で VPN サーバーを動すことができる本機能は、セキュリティを向上させることにつながるすばらしい機能なのです。一般的に、Windows や UNIX などの OS では、サーバープロセスを「root 権限」、「システム権限 (Admin 権限と等価)」で常駐させることはセキュリティ上あまり好ましくないと言われています。これは、万一プログラムにバグがあった場合は暴走してシステム全体を停止させてしまったり、脆弱性があった場合はシステム全体にわたって影響が生じたりするためです。もしプロセスを一般ユーザー権限で立ち上げておけば、たとえバグや脆弱性があった場合でもセキュリティ上の影響は最小限に留まります。
そのため、PacketiX VPN 4.0 が「ユーザーモードでのインストール・常駐」をサポートしたことは、単に便利だというだけではなく、セキュリティを向上させるために念のため一般ユーザー権限で常駐させたいという、セキュリティ意識の高い方の需要も満足することができる大変良い改良点だと思います。
なお、「ユーザーモードで動作している VPN Server の仮想 HUB 内の VPN クライアントが、社内の物理的な LAN 上のコンピュータとの間で通信ができるようにする」ことを実現するのには大変な苦労を要しました。こちら にあるような、「逆 TCP/IP プロトコルスタック」というようなものをソフトウェアで実装し、VPN Server 内に組み込んであります。この技術により、VPN Server プロセスは一般ユーザー権限のみで、VPN クライアントと物理的なコンピュータとの間で TCP/UDP/ICMP での通信を実現しています。
TCP over ICMP / TCP over DNS 機能で通信不良の無線 LAN に対応
最近は公衆無線 LAN が普及しており、色々なところで無線 LAN が利用可能になりました。しかし、たくさんの人々が利用する公共の無線 LAN アクセスポイントでは、よく、TCP や UDP の通信が不安定になっている場合があるようです。
せっかく SSID に接続することができて IP アドレスも割当てられているのに、なぜか、インターネット上の Web サーバーにアクセスすると、HTTP 通信 (TCP を用いています) がうまくつながらずにエラーが画面に表示されたり、意図した接続先の Web サーバーとは異なる、よくわからないフィッシングのようなサイト (カード番号や料金を請求される) に勝手にリダイレクトされたりすることがあります。このような場合は、HTTP 以外にも、Skype やメッセンジャーなどの通信 (TCP や UDP を使用している) がうまくいかない場合があります。
前者のような「TCP 接続エラー」が発生する原因の多くは、公衆無線 LAN の利用者が多すぎ、共用の NAT が扱えるセッションテーブルが溢れてしまっていることが原因なのではないかと推測されます。この場合、これ以上新たな TCP/IP 通信を行うことができません。
後者のような「意図した URL とは明らかに違う、よくわからないフィッシングのようなサイト (カード番号や料金を請求される) に勝手にリダイレクトされる」という現象が、公衆無線 LAN の一部でよくあると聞いています。私は実際にあまり経験したことがないのですが、確かにそのような無線 LAN があるようです。そこで推測するに、恐らくその無線 LAN は付近に誰か別の悪いユーザーがいて、そのユーザーが偽の DHCP や DNS、ARP スプーフィングサーバなどを無線 LAN の同一 SSID のセグメント内で立ち上げ、小額料金を請求するフィッシング詐欺のようなものを企んでいるのではないかと思います。
上記のように、TCP/UDP の通信が不調となってしまっている無線 LAN アクセスポイントであっても、なぜか ICMP や DNS のパケットは通る場合があるようです。無線 LAN の先にあるルータなどでは TCP/UDP と ICMP/DNS とは別の処理が適用されるようになっているため、たとえばセッション数超過で TCP/UDP のマッピングテーブルがいっぱいになってしまっている場合でも、ICMP による Ping 通信は可能な場合が多いようです。
このような通信不良が発生している無線 LAN アクセスポイントで、VPN を ICMP または DNS パケット上に載せて通信することができればとても便利です。そこで、PacketiX VPN 4.0 には以下の図のような VPN over ICMP / DNS 機能を搭載しました。
たとえば、自社に VPN サーバーを立ち上げておき、グローバル IP アドレスを割当てておきます。そしてインターネット側からの ICMP や DNS のパケットが到達するようにしておきます。そうすれば、上図のように、通信が不安定な無線 LAN を利用するときに、まず VPN サーバーとの間で ICMP / DNS を用いて VPN チャネルを確立しておき、その上で好きな通信 (HTTP など) を行うということができます。
もちろん、自社の VPN サーバーを経由して、自社の社内 LAN 上のコンピュータにアクセスすることもできます。
VPN over ICMP / VPN over DNS 機能は、上記のように、TCP/UDP の通信ができない場合の最終手段としてとても便利です。
ネットワーク管理者が社員の無断の VPN 利用を『確実に』禁止したい場合
これまでに書いてきた、PacketiX VPN 4.0 の強力な「ファイアウォールの貫通」機能の解説は、ユーザーの側の視点から見たものです。一方、ネットワーク管理者側の視点から見たとき、一部の管理者には、ユーザーの通信をすべて監視・管理したいとか、ユーザーが管理者に無断で VPN 通信を行えないようにしたいといった需要がある場合もあるかと思います。
そこで、今度はネットワーク管理者の立場に立って、PacketiX VPN 4.0 を「社員が無断で勝手に利用してしまう」ことを防ぐ方法について解説したいと思います。
従来の方法として、ファイアウォールに「IPsec や PPTP は通さない」といったフィルタを書くという方法があります。この方法を用いれば IPsec や PPTP などのレガシーな VPN プロトコルを遮断できます。しかし、PacketiX VPN や OpenVPN などのモダンな VPN プロトコルは TCP や UDP を用いて通信をしますので、単に特定のプロトコルだけをフィルタするという手法ではうまく遮断できません。PacketiX VPN や OpenVPN はポート番号も変更することができますので、「OpenVPN のデフォルトポートである 1194 を遮断する」という方法では遮断できません。
OpenVPN や Windows に付属している VPN サーバー機能であれば、会社のファイアウォールで「外側から内側に対して始動される通信はすべてブロック」する設定にすれば、会社内に VPN サーバーを立てても、外からアクセスすることはできなくなります。従来は、社員が無許可で「社内に VPN サーバーを設置し、外からアクセスできるようにされてしまう」ことを防止するためには、この方法でだいたい十分でした。
しかし、PacketiX VPN 4.0 からは上記の「NAT トラバーサル」や「VPN Azure」といった機能が新たに追加されました。これらの機能は、前述のとおり、日本国内の 約 95.7% のファイアウォール・NAT を「外から内に」通過することができます。「外側から内側に対して始動される通信はすべてブロック」する設定にしていても、やはり通過できます。(原理は Skype と同じです。) そのため、別の対策が必要になります。
「社内の PC すべてをシステム管理者が管理し、社員には Admin 権限を渡さない」という運用方法は、これまでかなり有効でした。SoftEther や PacketiX VPN をインストールしたり、Windows 付属の PPTP VPN サーバー機能を有効にしたりするためには Admin 権限である必要があるためです。しかし、今回リリースされた「PacketiX VPN Server 4.0」には上記のとおり「ユーザーモードインストール」機能が搭載されていますりで、Admin 権限がなくてもインストールすることができます。グループポリシー機能で Windows Installer の実行を禁止している場合でも、PacketiX VPN Server 4.0 のユーザーモードインストーラは Windows Installer を用いていませんので、やはりインストールできます。したがって、「社員には Admin 権限を渡さない」という方法だけでは、無許可の VPN サーバーを立ち上げることを防止できなくなりました。
なお、Windows 7 以降の法人向けエディションを使用している場合で Active Directory を導入している場合は、AppLocker 機能を使用すれば、許可されたアプリ以外は、たとえユーザーモードのものであっても一切動作させないといった設定が可能です。これはとても有効に機能しますので、検討の余地があります。ただし、許可されたアプリ以外を禁止してしまうと、社員が業務のために利用したいと考える小さなユーティリティソフトなど (ZIP 解凍ソフトなど) が動作しなくなり、動作させる必要があるソフトを 1 つずつ洗い出して許可なければならない、というデメリットもあります。
AppLocker 機能などを用いて、OpenVPN や PacketiX VPN の EXE のハッシュ値を指定してブロックするというのも 1 つの方法です。しかし OpenVPN はオープンソースですし、PacketiX VPN 4.0 も間もなく GPL のオープンソースとして公開される予定ですので、ユーザーはいつでも自分の環境でリビルドすることができます。そうすると EXE ファイルのハッシュ値が変化しますので、この方法ではブロックできません。
「プロトコルの挙動を監視し、特定の性質が発見された場合は通信を遮断する」という仕組みのファイアウォールを導入することが 1 つの方法です。ネットエージェント社の One Point Wall はそのような製品の 1 つです。この製品は従来の SoftEther, PacketiX VPN, OpenVPN, IPsec, PPTP などの VPN プロトコルを遮断してきた実績があります。
しかし、残念ながらこのような高度なファイアウォールを導入しても確実に VPN を遮断することはできません。OpenVPN はオープンソースで公開されていますので、誰でもソースコードを修正して、挙動を変更することができます。変更された挙動は既存のファイアウォールでは検出できなくなります。ソフトイーサ社の「PacketiX VPN 3.0」も筑波大学との共同研究によってオープンソース化 (GPL) されており、UT-VPN (University of Tsukuba VPN Project) としてソースコードも公開されています。ソースコードを改良するだけで、ユーザー自らの手でいかようにもプロトコルを改良することができますので、ファイアウォールで確実に検出することはほとんど不可能だと思います。
なお、上記のような強力なファイアウォール貫通機能を有する「PacketiX VPN 4.0」も間もなくほとんどの機能を搭載した状態でオープンソース化され、GPL ライセンスで公開される見込みです。
それでも、ネットワーク管理者の方が「確実に無許可の VPN を遮断したい」と考える場合、1 つだけ、とても有効な方法があります。以下の図のように、ファイアウォールの制限を厳しくして、通信を「ホワイトリスト許可制」にするのです。
通常、ファイアウォールは社内から始動されたほとんどの通信を通してしまいます。通すポート番号を「80」、「443」に限定すれば HTTP のアクセスのみ通しそれ以外はフィルタすることもできるようになりますが、PacketiX VPN では「Ethernet over HTTP」を実現していますので、通過してしまいます。また、「VPN over ICMP」、「VPN over DNS」を実装した PacketiX VPN 4.0 では ICMP や DNS の通信を許可している場合はその上で VPN を構築できます。大抵のファイアウォールは ICMP や DNS の「内から外」への通信を許可していますので、通過してしまいます。
そこで、ファイアウォールの制限をいっそう厳しくし、「ホワイトリスト許可制」を導入します。これまで「内から外」の通信を原則として許可していたのを、「原則として禁止」というルールに変更します。その上で、社員に対してアクセスを許可する Web サイトの IP アドレスのみを通過できるようにルールを書きます。上図であれば、たとえば www.jal.co.jp と www.askul.co.jp という 2 つのサイトは社員が仕事でアクセスする可能性があるため通過させ、それ以外の IP アドレスは不明なサーバーがある可能性が高いのでフィルタします。このようにすれば、確実に「社員による無許可の VPN の通信」を禁止することが可能です。そして、ほとんどのファイアウォールはこのような設定が可能です。とても安価なコンシューマ向けブロードバンドルータでさえも可能であったりします。そのため、ここで解説した方法は、新たにほとんどコストはかかりません。ただし、社員は許可された Web サイトしか見れなくなりますので、たとえば Skype やメッセンジャーを利用したり、Web で情報を検索したりすることはできなくなるという制限事項もあります。
各社員に VPN サーバーを立ち上げる程度のリテラシを身につけさせる
「社員に勝手に VPN サーバーを立ち上げさせない」よりも「各社員に VPN サーバーを立ち上げる程度のリテラシやセキュリティ意識を身につけさせる」戦略をとるほうが長い目で見た場合は、コストも低くなり、管理の手間も減り、社員の能力や業務効率が高まります。
PacketiX VPN 4.0 は、そのような目的に最適の VPN ソフトウェアだと思います。現在はベータ版が無償でダウンロード可能です。また、間もなく PacketiX VPN 4.0 の製品版が出る頃には、PacketiX VPN 4.0 をオープンソース化した「SoftEther VPN」という無償バージョンが出る予定です。SoftEther VPN はオープンソース (GPL) となる予定ですので、永久に使用できますし、利用者の側で挙動を好きなように改良することもできます。PacketiX VPN 4.0 や SoftEther VPN 4.0 は、システム管理者が全社システムとして導入する場合でも、社内の各社員が自分のパソコンに 1 個ずつ導入する場合でも、どちらの場合も便利に利用できます。システム管理者が全社で導入する場合は、効率が良く間違いが少ないですが、どうしても細かい点で融通が利きにくくなります。各社員が自分のために 1 個ずつ VPN サーバーを設置する方法であれば、最初は少し大変かも知れませんが、長期的に見ると各社員のネットワークや VPN に関する知識が向上し、それぞれの社員ごとに最適な環境が作られることになります。そのような会社は、社員がそれぞれ積極的に物事を考え問題解決を行うことができる会社となり、そうでない会社と比べて全体の業績がアップすることでしょう。PacketiX VPN 4.0 やオープンソース版 SoftEther VPN が普及し、そのような良い会社が増えれば良いと思います。
