WireGuard - a VPN runs as a module inside the Linux kernel

WireGuard is an open-source software application and protocol that implements virtual private network (VPN) techniques to create secure point-to-point connections in routed or bridged configurations. It is run as a module inside the Linux kernel and aims for better performance than the IPsec and OpenVPN tunneling protocols.

Reference:

https://en.wikipedia.org/wiki/WireGuard

Install IPsec VPN for iPhone Android on pfSense 2.0

Install IPsec VPN for iPhone Android on pfSense 2.0

You can connect a number of devices to pfSense 2.0 using IPsec, most notably Android (Phones and Tablets) and iOS (iPhone, iPad, iPod Touch, etc) devices but anything that is capable of IPsec will typically work.
This document covers the most common setup for mobile devices, which is IPsec using Xauth and a mutual Pre-Shared Key.
This setup has been tested and working on Android 2.3.3 and iOS 4.3.5. Others may work as well, including the actual software Cisco client.

Mobile Clients
Go to VPN > IPsec > Mobile Clients

IKE Extensions: check "Enable IPsec Mobile Client Support".

User Authentication: select "Local Database".
Group Authentication: select "system".

Virtual Address Pool: check "Provide a virtual IP address to clients".
Virtual Address Pool: Netowrk: "10.0.0.0" / 24

DNS Servers: check "Provide a DNS server list to clients.
DNS Servers: Server #1: 8.8.8.8.
DNS Servers: Server #2: 8.8.4.4.

Click on "Save" button.
Click on "Apply changes" button.

Next, Create phase1 if it doesn't exist.

Phase 1 settings
Interface: WAN.
Description: IPsecVPN.

Authentication method: Mutual PSK + Xauth.
Negotiation mode: aggressive.
My identifier: My IP address.
Peer identifier: Distinguished name: MY_VPN_GROUP_NAME.
Pre-Shared Key: MY_VPN_PRE_SHARED_KEY.
Policy Generation: default.
Proposal Checking: Obey.
Encryption algorithm: AES 128 bits/
Hash algorithm: SHA1.
DH key group: 2.
Lifetime: 28800.

NAT Traversal: Force.

Note: Some have had more success with the following settings:
Policy Generation: Unique.
Proposal Checking: Strict.
NAT Traversal: Force.

Phase 2 settings
Mode: Tunnel.
Local Network: Network
Local Network: 10.0.0.0 / 24

Protocol: ESP
Encryption algorithms: check "AES 128 bits" only.
Hash algorithms: check "SHA1" only.
PFS key group: off.
Lifetime: 28800 seconds.

Click on "Save" button.
Click on "Apply changes" button.

Enable IPsec
VPN > Tunnels tab:

Check "Enable IPsec".

Create a IPsecVPN group with a privilege
Go to System > User Manager > Groups tab > Add a new group:

Group Name: IPsecVPN.
Description: IPsecVPN.

Click on "Save" Button. Then, edit the "IPsecVPN " group we just created again:

At the Assigned Privileges section, click on the "Add" button: select "User - VPN - IPsec xauth Dialin".

Click on "Save" Button.

User Settings - create a new user
Go to System > User Manager > Users tab > Add a new user:
Username: MyName_iphone
Password: ********
Group Memberships: IPsecVPN.

Click on "Save" Button.

Make sure the "Effective Privileges" field: Inherited from "IPSecVPN" has been set after saved.

Firewall Rule - allow VPN clients to connect to WAN interface:
Go to Firewall > Rules > WAN tab > Add new rule:

Interface: WAN.
Protocol: ESP.
Source Address: any
Destination: type "WAN net" (or "WAN address" depends on your situation)
Description: IPsecVPN

Click on "Save" button.
Click on "Apply changes" button.

Interface: WAN.
Protocol: TCP/UDP.
Source Address: any
Destination: type "WAN net" (or "WAN address" depends on your situation)
Destination port range: ISAKMP (500)
Description: IPsecVPN

Click on "Save" button.
Click on "Apply changes" button.

Interface: WAN.
Protocol: TCP/UDP.
Source Address: any
Destination: type "WAN net" (or "WAN address" depends on your situation)
Destination port range: IPsec NAT-T (4500)
Description: IPsecVPN

Click on "Save" button.
Click on "Apply changes" button.

Firewall Rule - disable VPN clients access to LAN network:
Go to Firewall > Rules > IPsec tab > Add new rule:

Interface: IPsec.
Protocol: any.
Source Address: 10.0.0.0 / 24
Destination: check "not".
Destination: type "WAN net" (or "WAN address" depends on your situation)

Click on "Save" button.
Click on "Apply changes" button.

Interface: IPsec.
Protocol: any.
Source Address: 10.0.0.0 / 24
Destination: check "not".
Destination: type "Network"
Destination: Address "192.168.0.0 / 16" (we don't want VPN clients to access LAN subnet).

Click on "Save" button.
Click on "Apply changes" button.

Firewall Rule - NAT Outbound:
Go to Firewall > NAT > Outbound tab:

Click on "Manual Outbound NAT rule generation (AON - Advanced Outbound NAT)" > click on "Save" button. Some rules will be set automatically.

Add a new mapping rule:

Interface: WAN.
Protocol: any.
Source: type "network".
Source: address "10.0.0.0 / 24".
Destination: check "not".
Destination: type "Network"
Destination: Address "192.168.0.0 / 16" (we don't want VPN clients to access LAN subnet).

Click on "Save" button.
Click on "Apply changes" button.

Device Setup (iOS)

Go to iPhone > Settings > General > Network > VPN

Add VPN Configuration

Click IPsec
Description: whatever you want
Server: IP of the server
Account: your xauth username
Password: your xauth password (or leave blank to be prompted every time)
Group Name: MY_VPN_GROUP_NAME
Secret: MY_VPN_PRE_SHARED_KEY

Device Setup (Android)

NOTE: These settings are not present on all Android devices. See Android VPN Connectivity for more info.

Settings, Networks & Wireless, VPN Settings, Advanced IPsec VPNs
From there, press the menu button, then add.
Connection Template: PSK v1 (AES, xauth, aggressive)
VPN Name: whatever you want
VPN Server: IP of the server
The phone forces the keyboard to numbers, not sure if a hostname is supported.
Pre-Shared Key Type: text
Pre-Shared Key: PSK from the Phase 1 above
Identity Type: User FQDN
Identity: vpnusers@example.com
Username: your xauth username
Password: your xauth password
Internal Subnet IP: Whatever subnet(s) you specified in p2 above.

Finish

Troubleshooting

By default iOS will tunnel all traffic over the VPN, including traffic going to the Internet. If you are unable to access Internet sites once connected, you may need to push a DNS server to the client for it to use, such as the LAN IP address of your firewall if you have the DNS forwarder enabled, or a public DNS server such as 8.8.8.8/8.8.4.4.
The reason for the above is that your 3G provider is likely giving your mobile devices DNS servers that are only accessible from their network. Once you connect to the VPN the DNS servers are now being accessed via the VPN instead of the 3G network, and the queries are likely to be dropped. Supplying a local/public DNS server will work around that.

Reference:
http://doc.pfsense.org/index.php/Mobile_IPsec_on_2.0

redirect all web traffic to a forward proxy server through Teamviewer VPN

Install Apache and set it as a forward proxy server

Eidt httpd.conf

### You can listen to multiple ports.
Listen 80
Listen 8080

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
LoadModule proxy_http_module modules/mod_proxy_http.so

# Virtual hosts
Include conf/extra/httpd-vhosts.conf

Edit httpd-vhosts.conf file:

### [START] add by Jun
NameVirtualHost *:80
NameVirtualHost *:8080



ProxyRequests On
ProxyVia On



    Order Deny,Allow
    Deny from All
    Allow from 127.0.0.1 192.168.178

    AuthType Basic
    AuthName "Password Required"
    AuthUserFile password.file
    AuthGroupFile group.file
    Require group usergroup



### [END] add by Jun

Create a password.file using the htpasswd.exe utility. Place it on the Apache Root directory

cmd> htpasswd.exe -c password.file username

Create a group.file using a text editor at the same level as the password.file with the following contents

usergroup: username

Install Teamviewer on both sever side and client side

1. download the latest Teamviewer (version 8.x and above).
http://www.teamviewer.com/download/TeamViewer_Setup_en.exe

2. Make sure you do enable the VPN option.

3. connect to your partner's teamviewer:
ID: 123 456 789
select "VPN" (make sure you do select this option, default is "Remote control".

Note: another way is to use "remote control" > extra tab at top bar > VPN > start.

4. a window will pop up, and you can see the partner's IP address. Copy the ip address.

5. Set up a proxy server for your browser:
go to start > run > Inetcpl.cpl > connections > LAN settings
> check "Use a proxy server for your LAN (These settings will not apply to dial-up or VPN connections)".
> Address (the partner's IP address from Teamviewer)
> Port 8080
> Click "Okay"

6. Done.


Reference:
http://stackoverflow.com/questions/724599/setting-up-an-apache-proxy-with-authentication

Set up OpenVPN server on FreeBSD running PF packet filter firewall and run VPN client on Windows 7 and FreeBSD 8.2

Set up OpenVPN server on FreeBSD running PF packet filter firewall and run VPN client on Windows 7 and FreeBSD 8.2

OpenVPN is a free and open source software application that implements virtual private network (VPN) techniques for creating secure point-to-point or site-to-site connections in routed or bridged configurations and remote access facilities. It uses a custom security protocol[2] that utilizes SSL/TLS for key exchange. It is capable of traversing network address translators (NATs) and firewalls. It was written by James Yonan and is published under the GNU General Public License (GPL)

My server has two WAN connections from two different ISP, so the setting in this tutorial allows the VPN clients to connect to the VPN server with my two public IP addresses. However, you can still use this tutorial to set up the OpenVPN server with a single WAN interface.

If you need help on how to set up multiple WAN interfaces with two different ISP:
http://gala4th.blogspot.com/2011/10/multiple-default-routes-gateways-with.html

Running OpenVPN in different scenarios:
1. Single OpenVPN instance on single interface.
2. Multiple OpenVPN instances on single interface. Ex: you want different rules for each set of VPN clients.
3. Single OpenVPN instance on each of multiple interfaces.
4. Multiple OpenVPN instance on each of multiple interfaces.

We will set up OpenVPN in "Single OpenVPN instance on each of multiple interfaces" scenario.

Install OpenVPN:
# cd /usr/ports/security/openvpn
# make config-recursive
# make config-recursive
# make config-recursive

Note: run "make config-recursive" few times. You may enable a dependency the first time through that has its own configuration options.

# make install

# mkdir /usr/local/etc/openvpn

This /usr/local/etc/rc.d/openvpn script supports running multiple instances of openvpn. To run additional instances link this script to something like:

For example:
# ln -s openvpn openvpn_foo

and define additional openvpn_foo_* variables in one of:
/etc/rc.conf, /etc/rc.conf.local or /etc/rc.conf.d/openvpn_foo

A list of avaiable interface on my server:

# ifconfig -l | tr ' ' '\n'
wan0 // IP 11.11.11.11. First WAN interface for my first ISP.
wan1 // IP 22.22.22.22. Second WAN interface for my second ISP.
dmz0 // IP 192.168.100.1 and 192.168.100.2. DMZ interface.
lan0 // IP 192.168.200.1 and 192.168.200.2. LAN interface.
tun0 // IP 10.8.0.1. First VPN interface for VPN clients connecting to first WAN interface.
tun1 // IP 10.9.0.1. Second VPN interface for VPN clients connecting to second WAN interface.

# vim /etc/rc.conf
ifconfig_wan0="inet 11.11.11.11 netmask 255.255.255.0"
ifconfig_wan1="inet 22.22.22.22 netmask 255.255.255.0"

ifconfig_dmz0="inet 192.168.100.1 netmask 255.255.255.0"
ifconfig_dmz0_alias0="inet 192.168.100.2 netmask 255.255.255.255"

ifconfig_lan0="inet 192.168.200.1 netmask 255.255.255.0"
ifconfig_lan0_alias0="inet 192.168.200.2 netmask 255.255.255.255"

// Note: do this if you want to run one instance of OpenVPN on each of two interfaces.
# ln -s /usr/local/etc/rc.d/openvpn /usr/local/etc/rc.d/openvpn_wan0
# ln -s /usr/local/etc/rc.d/openvpn /usr/local/etc/rc.d/openvpn_wan1

Sample configuration files can be found in:
# ls -l /usr/local/share/doc/openvpn/sample-config-files

Copy the OpenVPN config file
# cp /usr/local/share/doc/openvpn/sample-config-files/server.conf /usr/local/etc/openvpn/openvpn_wan0.conf

# cp /usr/local/share/doc/openvpn/sample-config-files/server.conf /usr/local/etc/openvpn/openvpn_wan1.conf

Note: The reason why we need to rename the config filename from server.conf to openvpn_foo.conf is because the /usr/local/etc/rc.d/openvpn script supports running multiple instances of openvpn. The openvpn script will try to read the config from the SCRIPT_NAME.conf. For example:

If you are startup script is called /usr/local/etc/rc.d/openvpn_wan0, it will read config file from /usr/local/etc/openvpn/openvpn_wan0.conf.

Edit OpenVPN config file:
# vim /usr/local/etc/openvpn/openvpn_wan0.conf
### Specify device
dev tun

### Which local IP address should OpenVPN
### listen on? (optional)
local 11.11.11.11

### Certificates for VPN Authentication
ca /usr/local/etc/openvpn/keys/ca.crt
cert /usr/local/etc/openvpn/keys/server.crt
key /usr/local/etc/openvpn/keys/server.key # This file should be kept secret

### Diffie hellman parameters
dh /usr/local/etc/openvpn/keys/dh1024.pem

### Server and client IP and Pool
### The server will take 10.8.0.1 for itself,
### the rest will be made available to clients.
server 10.8.0.0 255.255.255.0

# Maintain a record of client <-> virtual IP address
# associations in this file. If OpenVPN goes down or
# is restarted, reconnecting clients can be assigned
# the same virtual IP address from the pool that was
# previously assigned.
ifconfig-pool-persist ipp.txt

### Routes to push to the client.
### The specified network will be added automatically on the VPN client.
push "route 192.168.0.0 255.255.255.0"

### Enable compression on the VPN link.
### If you enable it here, you must also
### enable it in the client config file.
comp-lzo

### Make the link more resistant to connection failures
keepalive 10 120
persist-tun
persist-key

### optional ?
#ping-timer-rem

# It's a good idea to reduce the OpenVPN
# daemon's privileges after initialization.
#
# You can uncomment this out on non-Windows systems.
# By specifying 'nobody' OpenVPN service privileges are
# dropped to nobody. This increases system security.
user nobody
group nobody

# By default, log messages will go to the syslog (or
# on Windows, if running as a service, they will go to
# the "\Program Files\OpenVPN\log" directory).
# Use log or log-append to override this default.
# "log" will truncate the log file on OpenVPN startup,
# while "log-append" will append to it. Use one
# or the other (but not both).
;log openvpn.log
log-append /var/log/openvpn_wan0.log

# Set the appropriate level of log
# file verbosity.
#
# 0 is silent, except for fatal errors
# 4 is reasonable for general usage
# 5 and 6 can help to debug connection problems
# 9 is extremely verbose
verb 3

For openvpn_wan1.conf, most settings are similar to the previous openvpn_wan0.conf file, except:

# vim /usr/local/etc/openvpn/openvpn_wan1.conf
### Which local IP address should OpenVPN
### listen on? (optional)
local 22.22.22.22

### Server and client IP and Pool
### The server will take 10.9.0.1 for itself,
### the rest will be made available to clients.
server 10.9.0.0 255.255.255.0

log-append /var/log/openvpn_wan1.log

Review the difference between openvpn_wan0.conf and openvpn_wan1.conf:
# diff /usr/local/etc/openvpn/openvpn_wan0.conf /usr/local/etc/openvpn/openvpn_wan1.conf

Logging
# touch /var/log/openvpn_wan0.log
# touch /var/log/openvpn_wan1.log

Rotate OpenVPN log files:
# vim /etc/newsyslog.conf
/var/log/openvpn_wan0.log 600 9 100000 * JC /var/run/openvpn_wan0.pid
/var/log/openvpn_wan1.log 600 9 100000 * JC /var/run/openvpn_wan1.pid

# /etc/rc.d/newsyslog restart

Copy easy-rsa script to the home directory
# cp -r /usr/local/share/doc/openvpn/easy-rsa ~
# find ~/easy-rsa/ -type d -print0 | xargs -0 -I @ chmod 700 @
# find ~/easy-rsa/ -type f -print0 | xargs -0 -I @ chmod 400 @

Make sure these scripts are executable:
# find ~/easy-rsa/2.0/ -type f -print0 | xargs -0 -I @ chmod u+x @

Change follow lines in vars file to reflect your setting:
# cd ~/easy-rsa/2.0/
# vim ~/easy-rsa/2.0/vars
### These are the default values for fields
### which will be placed in the certificate.
### Don't leave any of these fields blank.
export KEY_COUNTRY="CA"
export KEY_PROVINCE="BC"
export KEY_CITY="Vancouver"
export KEY_ORG="Fort-Funston Ltd"
export KEY_EMAIL="me@myhost.mydomain"
export KEY_CN="CommonName_Can_Be_YourName_or_HostName"
export KEY_NAME="YourName"
export KEY_OU="UnitName_or_DepartmentName"
export PKCS11_MODULE_PATH="dummy"
export PKCS11_PIN="A_RANDOM_PASSWORD"

Very Important Step for FreeBSD/TCSH users. FreeBSD ships with tcsh as its native shell, at the time of writing the following scripts do not work. To get around this you must drop down to a bourne shell. To do this just type the following at a prompt:

# sh
# cd ~/easy-rsa/2.0/

Now you can carry on with building the certificates, once you have built them you can exit back out to tcsh.

Sourcing the vars file and other scripts:
# . vars
# ./clean-all
# ./build-ca

You will have to answer a few questions on the last step, once this has been done your CA certs will be created in the keys subdirectory.

Generate certificate & key for server:
# ./build-key-server server
A challenge password []: LEAVE IT BLANK AND PRESS ENTER
An optional company name []: LEAVE IT BLANK AND PRESS ENTER

Again answer the questions and the certs will be placed in the keys subdirectory.

Generate certificates & keys for 3 clients (each client will require their own certificates, if multiple clients log in with the same certs then they will be assigned the same ips and will kick each other off the network):

Generating client certificates is very similar to the previous step. You need to ensure that all your details are the same as for the CA, apart from the common name, which needs to be different for each client. For the sake of clarity this should relate to person who is assigned this vpn certificate. All of these details can be found in keys/server.crt for the server and keys/client*.crt for the client details.

# ./build-key client1
# ./build-key client2
# ./build-key client3

Generate Diffie Hellman parameters

Diffie Hellman parameters must be generated for the OpenVPN server:

# ./build-dh

Exit the sh shell:
# exit

Now move the whole keys directory to /usr/local/etc/openvpn:

# mv ~/easy-rsa/2.0/keys /usr/local/etc/openvpn/

Protect our certificate keys directory and config files for only root can see it.
# find /usr/local/etc/openvpn/keys/ -type d -print0 | xargs -0 -I @ sh -c 'chmod 700 @ ; chown root:wheel @'
# find /usr/local/etc/openvpn/keys/ -type f -print0 | xargs -0 -I @ sh -c 'chmod 400 @ ; chown root:wheel @'
# find /usr/local/etc/openvpn/ccd -type d -print0 | xargs -0 -I {} chmod 755 {}
# find /usr/local/etc/openvpn/ccd -type f -print0 | xargs -0 -I {} chmod 644 {}
# find /usr/local/etc/openvpn/ -type f -name '*.conf' -print0 | xargs -0 -I @ sh -c 'chmod 400 @ ; chown root:wheel @'

Note: ccd directory and files under the ccd directory must be readable.

You need to edit /etc/rc.conf if you set up single instance of OpenVPN with single interface:

Note: I have commented out following lines because I set to start OpenVPN daemon in /etc/rc.local later.

# vim /etc/rc.conf
#openvpn_wan0_enable="YES"
#openvpn_wan0_configfile="/usr/local/etc/openvpn/openvpn_wan0.conf"

#openvpn_wan1_enable="YES"
#openvpn_wan1_configfile="/usr/local/etc/openvpn/openvpn_wan1.conf"

We will be using the setfib command to run our utilities with an different routing table: 

Note: You do not need the setfib command if you are hosting your OpenVPN server with single WAN interface.

# cp /etc/ssh/sshd_config /etc/ssh/sshd_config.rtable0
# cp /etc/ssh/sshd_config /etc/ssh/sshd_config.rtable1

Edit sshd_config.* config file:
# vim /etc/ssh/sshd_config.rtable0
### IP address of first WAN interface
ListenAddress 11.11.11.11
### IP address of DMZ interface
ListenAddress 192.168.100.1
### IP address of LAN interface
ListenAddress 192.168.200.1

# vim /etc/ssh/sshd_config.rtable1
### IP address of second WAN interface
ListenAddress 22.22.22.22
### IP address of DMZ interface
ListenAddress 192.168.100.2
### IP address of LAN interface
ListenAddress 192.168.200.2

Note: Multiple ListenAddress options are permitted.

Note: you can let sshd to listen to the IP address of the tunnel interface. However, I do not recommend you do so. Because if OpenVPN did not start properly, sshd will have problem to start as well (because it could not listen to the specified IP address).

Edit rc.local:
# vim /etc/rc.local
### add first routing table for first WAN interface for first ISP network.
/usr/sbin/setfib 0 /sbin/route delete default
/usr/sbin/setfib 0 /sbin/route add default 11.11.11.11

### add second routing table for second WAN interface for second ISP network.
/usr/sbin/setfib 1 /sbin/route delete default
/usr/sbin/setfib 1 /sbin/route add default 22.22.22.22

### start OpenVPN on the first WAN interface.
/usr/sbin/setfib 0 /usr/local/etc/rc.d/openvpn_wan0 onestart

### start OpenVPN on the second WAN interface.
/usr/sbin/setfib 1 /usr/local/etc/rc.d/openvpn_wan1 onestart

### Use different routing table for each sshd daemon.
### Note: we need to start SSH after OpenVPN started
### since the IP address of tunnel interface (for VPN) has been listened by sshd,
### which is defined in the sshd_config.rtable0 and sshd_config.rtable1 config file.
### Note: make sure the line 'sshd_enable="YES"' has bee commented out
### or removed from /etc/rc.conf file. We will start sshd in /etc/rc.local file.
/usr/sbin/setfib 0 /usr/sbin/sshd -f /etc/ssh/sshd_config.rtable0
/usr/sbin/setfib 1 /usr/sbin/sshd -f /etc/ssh/sshd_config.rtable1

### Flush PF rules after OpenVPN and SSH daemons started
### Note: the reason is because there are some settings related to these VPN
### interface tun0 and tun1. So we need to flush the PF rules after OpenVPN loaded.
/sbin/pfctl -f /etc/pf.conf

Comment out or remove sshd_enable="YES" line in /etc/rc.conf:
# vim /etc/rc.conf
### Note: commented out for multiple WAN routes setup. SSH daemon will be started in /etc/rc.local file.
#sshd_enable="YES"

Let's start OpenVPN server manually now:

# setfib 0 /usr/local/etc/rc.d/openvpn_wan0 onestart
Starting openvpn_wan0.
add net 10.8.0.0: gateway 10.8.0.2

# setfib 1 /usr/local/etc/rc.d/openvpn_wan1 onestart
Starting openvpn_wan1.
add net 10.9.0.0: gateway 10.9.0.2

Make sure the network and the gateway have been correctly added:

# setfib 0 netstat -rn | egrep '10.[8|9].0'
10.8.0.0/24 10.8.0.2 UGS 0 0 tun0
10.8.0.1 link#6 UHS 0 0 lo0
10.8.0.2 link#6 UH 0 0 tun0
10.9.0.1 link#7 UHS 0 0 lo0
10.9.0.2 link#7 UH 0 0 tun1

# setfib 1 netstat -rn | egrep '10.[8|9].0'
10.8.0.2 link#6 UH 0 0 tun0
10.9.0.0/24 10.9.0.2 UGS 0 0 tun1
10.9.0.2 link#7 UH 0 0 tun1

In some cases, the network did not be added successfully, you will need to add the network maually:
# setfib 0 route add 10.8.0.0/24 10.8.0.2
# setfib 1 route add 10.9.0.0/24 10.9.0.2

You should have seen two different IP addresses are listening port 1194:

# netstat -an | grep 1194
udp4 0 0 11.11.11.11.1194 *.*
udp4 0 0 22.22.22.22.1194 *.*

You should have seen two different process IDs are running:

# ls -l /var/run/openvpn*.pid
-rw-r--r-- 1 root wheel 6 Dec 5 15:49 /var/run/openvpn_wan1.pid
-rw-r--r-- 1 root wheel 6 Dec 5 15:44 /var/run/openvpn_wan0.pid

# ifconfig | grep tun
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
tun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500

Let's start ssh daemon now:
# /usr/sbin/setfib 0 /usr/sbin/sshd -f /etc/ssh/sshd_config.rtable0
# /usr/sbin/setfib 1 /usr/sbin/sshd -f /etc/ssh/sshd_config.rtable1

See port 22 is binding to which IP addresses:
# netstat -an | grep 22
tcp4 0 0 11.11.11.11.22 *.* LISTEN
tcp4 0 0 192.168.100.1.22 *.* LISTEN
tcp4 0 0 192.168.200.1.22 *.* LISTEN
tcp4 0 0 10.8.0.1.22 *.* LISTEN
tcp4 0 0 22.22.22.22.22 *.* LISTEN
tcp4 0 0 192.168.100.2.22 *.* LISTEN
tcp4 0 0 192.168.200.2.22 *.* LISTEN
tcp4 0 0 10.9.0.1.22 *.* LISTEN
tcp4 0 0 *.22 *.* LISTEN

To show listening/opening TCP port:
# sockstat -Ptcp

To show listening/opening UDP port:
# sockstat -Pudp

Note: man sockstat

Restart the machine and re-check everything is fine after reboot:
# sync; sync; sync; reboot

Edit pf.conf PF firewall setting:
# vim /etc/pf.conf
wan_if0 = "wan0"
wan_if1 = "wan1"

dmz_if = "dmz0"
lan_if = "lan0"

### Note: the reason why we specified VPN network below is because we want to avoid
### PF parse host specification error. Since PF runs before OpenVPN starts,
### PF could not figure it out the VPN network until OpenVPN started.
vpn_if0 = "tun0"
vpn_net0 = '"10.8.0.0/24"'
vpn_if1 = "tun1"
vpn_net1 = '"10.9.0.0/24"'

icmp_types = "{echoreq echorep unreach}"

### [NAT] the VPN connections (for access to the remote secure networks)
nat on $wan_if0 from $vpn_net0to any -> $wan_if0
nat on $wan_if1 from $vpn_net1 to any -> $wan_if1

### [VPN] Inbound from Outside
### Establish VPN connections on each WAN interface.
pass in quick on $wan_if0 proto udp from any to $wan_if0 port 1194 keep state rtable 0
pass in quick on $wan_if1 proto udp from any to $wan_if1 port 1194 keep state rtable 1

### [SSH] Inbound from VPN to ANY
pass in quick log on $vpn_if0 proto tcp from $vpn_net0to any port 22 flags S/SA keep state rtable 0
pass in quick log on $vpn_if1 proto tcp from $vpn_net1 to any port 22 flags S/SA keep state rtable 1

### [SSH] Outbound to LAN
pass out quick log on $lan_if proto tcp from {$dmz_if/24 $lan_if/24 $vpn_if0/24} to $lan_if/24 port 22 flags S/SA keep state rtable 0
pass out quick log on $lan_if proto tcp from {$vpn_net1} to $lan_if/24 port 22 flags S/SA keep state rtable 1

### [SSH] Outbound to DMZ
pass out quick log on $dmz_if proto tcp from {$dmz_if/24 $lan_if/24 $vpn_if0/24} to $dmz_if/24 port 22 flags S/SA keep state rtable 0
pass out quick log on $dmz_if proto tcp from {$vpn_net1} to $dmz_if/24 port 22 flags S/SA keep state rtable 1

### [ICMP] Inbound from VPN
pass in quick on $vpn_if0 proto icmp from $vpn_net0to any icmp-type $icmp_types rtable 0
pass in quick on $vpn_if1 proto icmp from $vpn_net1 to any icmp-type $icmp_types rtable 1

### [ICMP] Inbound from Outside
pass in quick log on $wan_if0 proto icmp from any to $wan_if0 icmp-type $icmp_types rtable 0
pass in quick log on $wan_if1 proto icmp from any to $wan_if1 icmp-type $icmp_types rtable 1

### [ICMP] Outbound to Outside
pass out quick on $wan_if0 proto icmp from $wan_if0 to any icmp-type $icmp_types rtable 0
pass out quick on $wan_if1 proto icmp from $wan_if1 to any icmp-type $icmp_types rtable 1

### [ICMP] Outbound to LAN
pass out quick log on $lan_if proto icmp from {$lan_if $dmz_if/24 $vpn_if0/24} to $lan_if/24 icmp-type $icmp_types rtable 0
pass out quick log on $lan_if proto icmp from {$vpn_net1} to $lan_if/24 icmp-type $icmp_types rtable 1

### [ICMP] Outbound to DMZ
pass out quick log on $dmz_if proto icmp from {$dmz_if $lan_if/24 $vpn_if0/24} to $dmz_if/24 icmp-type $icmp_types rtable 0
pass out quick log on $dmz_if proto icmp from {$vpn_net1} to $dmz_if/24 icmp-type $icmp_types rtable 1

Watch the pflog logged packets in real time:
# tcpdump -n -e -ttt -i pflog0

Watch the icmp packect of an interface:
# tcpdump -ni wan0 icmp
# tcpdump -ni wan1 icmp
# tcpdump -ni dmz0 icmp
# tcpdump -ni tun0 icmp
# tcpdump -ni tun1 icmp

# tcpdump -tt -i tun0

# tail /usr/local/etc/openvpn/openvpn-status.log

# tail /var/log/openvpn_wan0.log

# tail /var/log/openvpn_wan1.log

# tail /var/log/messages

Download OpenVPN 2.2.1 client for Windows:
http://openvpn.net/index.php/open-source/downloads.html

Once this is installed you will need to copy the following files from your server /usr/local/etc/openvpn/keys directory to the Windows PC C:\Program Files\Openvpn\config directory (this should be done in as secure a manner as possible, i.e. USB Stick or floppy rather than email!!!):

ca.crt
client1.crt
client1.key

Note: For the next client you will need to copy the client2.crt and client2.key files to prevent issues later.

Create VPN config file:

create a myvpn.ovpn file in C:\Program Files\Openvpn\config and insert the following:

client
remote nic1.myserver.com 1194
#remote nic2.myserver.com 1194
dev tun
comp-lzo

ca ca.crt
cert client1.crt
key client1.key

# Set log file verbosity.
verb 3

Turn off the firewall for the new Interface:

On Windows XP, the firewall can be accessed by:
Control Panel -> Security Center -> Windows Firewall -> Advanced. In the Network Connection Settings control, uncheck the box corresponding to the TAP-Win32 adapter.

Now right-click the OpenVPN Icon in your Taskbar and click "connect". Once connected try pinging the remote interface and check (using tracert) that the remote network is available. Use tcpdump on the server to check traffic too:

On Windows 7, you must run OpenVPN as an administrator by:

right click on openvpn-gui-1.0.3.exe > Property > Shortcut > Run this program as an administrator

or

right click on openvpn-gui-1.0.3.exe > Property > Compatibility > Run this program as an administrator

cmd> tracert

cmd> ping 10.8.0.1
cmd> ping 10.9.0.1

Use Firewall's VPN IP address to connecto the firewall:
cmd> putty.exe username@10.8.0.1
cmd> putty.exe username@10.9.0.1

Note: If you want to ssh to the IP address of the firewall's LAN/DMZ interface, make sure you do set up your sshd to listen to these IP addresses with proper routing table.

Use FreeBSD as a VPN client:

# cd /usr/ports/security/openvpn
# make config-recursive
# make config-recursive
# make config-recursive

Note: run "make config-recursive" few times. You may enable a dependency the first time through that has its own configuration options.

# make install

Link the openvpn startup script:
# ln -s /usr/local/etc/rc.d/openvpn /usr/local/etc/rc.d/openvpn_client

Create OpenVPN directory:
# mkdir -p /usr/local/etc/openvpn/keys

Put following three files to /usr/local/etc/openvpn/keys:
ca.crt
client1.crt
client1.key

Protect our certificate keys directory and config files for only root can see it.
# find /usr/local/etc/openvpn/keys/ -type d -print0 | xargs -0 -I @ sh -c 'chmod 700 @ ; chown root:wheel @'
# find /usr/local/etc/openvpn/keys/ -type f -print0 | xargs -0 -I @ sh -c 'chmod 400 @ ; chown root:wheel @'
# find /usr/local/etc/openvpn/ -type f -name '*.conf' -print0 | xargs -0 -I @ sh -c 'chmod 400 @ ; chown root:wheel @'

You will need to copy the client.conf instead of server.conf from /usr/local/share/doc/openvpn/sample-config-files directory:
# cp /usr/local/share/doc/openvpn/sample-config-files/client.conf /usr/local/etc/openvpn/openvpn_client.conf

Edit openvpn_client.conf:
# vim /usr/local/etc/openvpn/openvpn_client.conf
client
dev tun
proto udp

# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.
remote 11.11.11.11 1194
;remote my-server-2 1194

# Downgrade privileges after initialization (non-Windows only)
user nobody
group nobody

# Try to preserve some state across restarts.
persist-key
persist-tun

# Certificates for VPN Authentication
ca /usr/local/etc/openvpn/keys/ca.crt
cert /usr/local/etc/openvpn/keys/client1.crt
key /usr/local/etc/openvpn/keys/client1.key

# Verify server certificate by checking
# that the certicate has the nsCertType
# field set to "server". This is an
# important precaution to protect against
# a potential attack discussed here:
# http://openvpn.net/howto.html#mitm
ns-cert-type server

# vim /etc/rc.conf
openvpn_client_enable="YES"
openvpn_client_configfile="/usr/local/etc/openvpn/openvpn_client.conf"

Start OpenVPN client:
# /usr/local/etc/rc.d/openvpn_client start

# tail -F /var/log/messages

# ifconfig
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
options=80000<LINKSTATE>
inet 10.8.0.6 --> 10.8.0.5 netmask 0xffffffff
Opened by PID 98483

Display the full output line of ps process status command:
# ps -auxww | grep openvpn
nobody 1015 /usr/local/sbin/openvpn --cd /usr/local/etc/openvpn --daemon openvpn_wan0 --config /usr/local/etc/openvpn/openvpn_wan0.conf --writepid /var/run/openvpn_wan0.pid
nobody 1035 /usr/local/sbin/openvpn --cd /usr/local/etc/openvpn --daemon openvpn_wan1 --config /usr/local/etc/openvpn/openvpn_wan1.conf --writepid /var/run/openvpn_wan1.pid

# ls -l /var/run/openvpn*
-rw-r--r-- 1 root wheel 6 Dec 21 12:53 /var/run/openvpn_client.pid

===
# If enabled, this directive will configure
# all clients to redirect their default
# network gateway through the VPN, causing
# all IP traffic such as web browsing and
# and DNS lookups to go through the VPN
# (The OpenVPN server machine may need to NAT
# or bridge the TUN/TAP interface to the internet
# in order for this to work properly).

push "redirect-gateway def1 bypass-dhcp"
===
Fixed IP addresses for OpenVPN clients

# vim /usr/local/etc/openvpn.conf
# EXAMPLE: Suppose you want to give
# Thelonious a fixed VPN IP address of 10.9.0.1.
# First uncomment out these lines:
client-config-dir ccd
route 10.8.0.0 255.255.255.252
# Then add this line to ccd/Thelonious:
# ifconfig-push 10.9.0.1 10.9.0.2

# mkdir /usr/local/etc/openvpn/ccd

Modify the permission:
# find /usr/local/etc/openvpn/ccd -type d -print0 | xargs -0 -I {} chmod 755 {}
# find /usr/local/etc/openvpn/ccd -type f -print0 | xargs -0 -I {} chmod 644 {}

The ifconfig push pushes addresses in a /30 network unless you are using
infrastructure mode.

the correct notation should be in a /30 network e.g.

ifconfig-push 10.200.200.9 10.200.200.10
http://openvpn.net/archive/openvpn-users/2007-07/msg00084.html

In default mode openvpn assigns miniature /30 networks to each VPN client:

server
10.8.0.0 : network address
10.8.0.1 : server IP address
10.8.0.2 : virtual remote endpoint; only used for routing
10.8.0.3 : network broadcast address

first client
10.8.0.4 : network address
10.8.0.5 : virtual remote endpoint; non pingable; only used for routing
10.8.0.6 : client IP address
10.8.0.7 : network broadcast address

second client : 10.8.08 - 10.8.0.11
third client : 10.8.012 - 10.8.0.15

etc. So a valid network block for a client is 10.8.0.24 - 10.8.0.27:
10.8.0.24 : network address
10.8.0.25 : virtual remote endpoint; non pingable; only used for routing
10.8.0.26 : client IP address
10.8.0.27 : network broadcast address

to use this network the ccd file needs to contain
Code:
ifconfig-push 10.8.0.26 10.8.0.25

(note that the HOWTO on the openvp.net erroneously swaps the IPs!)
http://forums.openvpn.net/topic8215.html
===
Difference Between TUN and TAP

In computer networking, TUN and TAP are virtual network kernel devices. They are network devices that are supported entirely in software, which is different from ordinary network devices that are backed up by hardware network adapters.

TAP (as in network tap) simulates an Ethernet device and it operates with layer 2 packets such as Ethernet frames. TUN (as in network TUNnel) simulates a network layer device and it operates with layer 3 packets such as IP packets. TAP is used to create a network bridge, while TUN is used with routing.

Packets sent by an operating system via a TUN/TAP device are delivered to a user-space program that attaches itself to the device. A user-space program may also pass packets into a TUN/TAP device. In this case TUN/TAP device delivers (or "injects") these packets to the operating system network stack thus emulating their reception from an external source.
===
As far as I could see, tap allows netbios broadcast to propagate across the
VPN so Windows clients can find network shares by PC name even if no WINS
server is being used; with tun, either you find network shares in some other
way (by IP or DNS, for example) or you need to have WINS running (which often
amounts to "wins proxy = yes" in smb.conf).

On the other hand, I do not feel comfortable in having VPN clients appear as
if physically attached to the LAN (this is what bridging with TAP amounts to)
and prefer routing with tun as it makes easier to write appropriate firewall
rules for VPN clients.
===
if it's ok to create vpn on layer 3 [ one more hop between subnets ] - go for tun.

if you need to bridge two ethernet segments in two different locations - then use tap. in such setup you can have computers in the same ip subnet [ eg 10.0.0.0/24 ] on both ends of vpn, and they'll be able to 'talk' to each other directly without any changes in their routing tables. vpn will act like ethernet switch. this might sound cool and is useful in some cases but i would advice not to go for it unless you really need it. if you choose such layer 2 bridging setup - there will be a bit of 'garbage' [ that is broadcast packets ] going across your vpn.
===
I always set up tun. Tap is used by ethernet bridging in OpenVPN and introduces an unprecendented level of complexity that is simply not worth bothering with. Usually when a VPN needs to be installed, its needed now, and complex deployments don't come fast.
===
I chose "tap" when setting up a VPN for a friend who owned a small business because his office uses a tangle of Windows machines, commercial printers, and a Samba file server. Some of them use pure TCP/IP, some seem to only use NetBIOS (and thus need Ethernet broadcast packets) to communicate, and some I'm not even sure of.

If I had chosen "tun", I would probably have faced lots of broken services — lots of things that worked while you are in the office physically, but then would break when you went off-site and your laptop couldn't "see" the devices on the Ethernet subnet anymore.

But by choosing "tap", I tell the VPN to make remote machines feel exactly like they're on the LAN, with broadcast Ethernet packets and raw Ethernet protocols available for communicating with printers and file servers and for powering their Network Neighborhood display. It works great, and I never get reports of things that don't work offsite!
===
I started out using tun, but switched to tap since I didn't like the use of a /30 subnet for each PC (I need to support Windows). I found that to be wasteful and confusing.

Then I discovered the "topology subnet" option on the server. Works with the 2.1 RCs (not 2.0), but it gives me all the advantages of tun (no bridging, performance, routing, etc) with the convenience of one (sequential) IP address per (windows) machine.
===
What All Ports Are Rrequired By Domain Controllers And Client Computers?

Active Directory communication takes place using several ports. These ports are required by both client computers and Domain Controllers. As an example, when a client computer tries to find a domain controller it always sends a DNS Query over Port 53 to find the name of the domain controller in the domain.

The following is the list of services and their ports used for Active Directory communication:

UDP Port 88 for Kerberos authentication
UDP and TCP Port 135 for domain controllers-to-domain controller and client to domain controller operations.
TCP Port 139 and UDP 138 for File Replication Service between domain controllers.
TCP and UDP Port 389 for LDAP to handle normal queries from client computers to the domain controllers.
TCP and UDP Port 445 for File Replication Service
TCP and UDP Port 464 for Kerberos Password Change
TCP Port 3268 and 3269 for Global Catalog from client to domain controller.
TCP and UDP Port 53 for DNS from client to domain controller and domain controller to domain controller.
Opening above ports in Firewall between client computers and domain controllers, or between domain controllers, will enable Active Directory to function properly.

http://www.windowsnetworking.com/kbase/WindowsTips/Windows2000/AdminTips/ActiveDirectory/WhatAllPortsAreRrequiredByDomainControllersAndClientComputers.html
===
Reference:
http://blog.ijun.org/2011/12/set-up-openvpn-server-on-freebsd.html
http://kuapp.com/2010/07/01/openvpn-with-freebsd-pf-and-windows-xp.html
http://www.secure-computing.net/wiki/index.php/FreeBSD_OpenVPN_Server/Routed
http://en.wikipedia.org/wiki/TUN/TAP
http://openvpn.net/archive/openvpn-users/2007-02/msg00184.html
http://serverfault.com/questions/21157/should-i-use-tap-or-tun-for-openvpn
http://forums.freebsd.org/showthread.php?t=15213
http://en.wikipedia.org/wiki/OpenVPN

Install OpenVPN Remote Access (TLS + User Auth) on pfSense 2.0

Install OpenVPN Remote Access (TLS + User Auth) on pfSense 2.0

Install OpenVPN Client Export Utility Package
Go to System > Packages > "Available Packages" tab > install "OpenVPN Client Export Utility" package.

Create CA (Certificate Authority)
Go to System > Cert Manager > "CAs" tab:

Descriptive name: Road Warrior CA
Method: "Create an internal Certificate Authority".
Key length: 4096 bits.
Lifetime: 3650 days.
Country Code: CA
State or Province: British Columbia
City: Port Coquitlam
Organization: YOUR_COMPANY_NAME Inc
Email Address: test@example.com
Common Name: Road Warrior CA

Create a OpenVPN Group
Go to System > User Manager > "Groups" tab > Add Group:

Group name: OpenVPN
Description: OpenVPN

Click on "Save" button.

Create a OpenVPN User
Go to System > User Manager > "Users" tab > Add User:

Username: openvpn_client1
Password: ********
Group Memberships: OpenVPN

Click on "Save" button.

Edit the user we just created > User Certificates: Add:

Method: Create an internal Certificate
Descriptive name: openvpn_client1
Certificate authority: Road Warrior CA
Key length: 4096 bits
Certificate Type: User Certificate
Lifetime: 3650 days

Distinguished name:
Country Code: CA
State or Province: British Columbia
City: Port Coquitlam
Organization: YOUR_COMPANY_NAME Inc
Email Address: test@example.com
Common Name: openvpn_client1

Click on "Save" button.

Service configuration
Go to VPN > click on "OpenVPN" > click on "Wizards" tab > Type of Server "Local User Access" > click on "Next" button
> Certificate Authority "Road Warrior CA" > click on "Next" button
> for server certificate, click on "Add new Certificate" button:

Descriptive Name: Road Warrior Server Certificate
Key length: 4096 bits
Lifetime: 3650
Country Code: CA
State or Province: British Columbia
City: Port Coquitlam
Organization: YOUR_COMPANY_NAME Inc
Email Address: test@example.com

Click on "Craete New Certificate" button.

Cryptographic Settings:
TLS Authentication: check "enable authentication of TLS packets".
Generate TLS Key: check "Automatically generate a shared TLS authentication key".
DH Parameters Length: 4096 bit.
Encryption Algorithm: AES-256-CBC (256-bit)
Hardware Crypto: No Hardware Crypto Acceleration.

Tunnel Settings:
Tunnel Network: 10.0.8.0/24
Redirect Gateway: check "Force all client generated traffic through the tunnel".
Concurrent connections: 10
Compression: check "Compress tunnel packets using the LZO algorithm".

Client Settings:
Dynamic IP: check "Allow connected clients to retain their connections if their IP address changes".
Address Pool: check "Provide a virtual adapter IP address to clients (see Tunnel Network)".
DNS Servers: check "Provide a DNS server list to clients".
DNS Servers: Server #1: 8.8.8.8
DNS Servers: Server #2: 8.8.4.4

Click on "Next" button.

Firewall Rule: check "Add a rule to permit traffic from clients on the Internet to the OpenVPN server process.

Make sure following is unchecked:
OpenVPN Rule: uncheck "Add a rule to allow all traffic from connected clients to pass across the VPN tunnel.

Click on "Next" button.
Click on "Finish" button.

OpenVPN: Client Export Utility
Go to VPN > OpenVPN > "Client Export" Tab > look for a user > click on "Configuration archive" link.

Firewall Rules
Go to Firewall > Rules > OpenVPN tab > Add rule:
Interface: OpenVPN
Protocol: any
Source: any
Destination: check "not"
Destination: type "LAN subnet" (we don't want VPN clients to access LAN subnet).
Description: OpenVPN Road Warrior

Click on "Save" Button.

Go to Firewall > NAT > Outbound tab > click on "Manual outbound NAT rule generation" > Save Button > Add a new mapping rule:
Interface: WAN.
Protocol: any.
Source: type "network".
Source: address "10.0.8.0 / 24".
Destination: check "not" (we don't want VPN clients to access LAN subnet).
Destination: type "Network".
Destination: address 192.168.1.0 / 24.

Click on "Save" button.
Click on "Apply changes" button.

Reference:
http://www.packetwatch.net/documents/guides/2012050801.php

Difference between OpenVPN, PPTP, L2TP, IPSec

Difference between OpenVPN, PPTP, L2TP, IPSec

Why SSL VPN?

Does OpenVPN support IPSec or PPTP?

There are three major families of VPN implementations in wide usage today: SSL, IPSec, and PPTP. OpenVPN is an SSL VPN and as such is not compatible with IPSec, L2TP, or PPTP.

The IPSec protocol is designed to be implemented as a modification to the IP stack in kernel space, and therefore each operating system requires its own independent implementation of IPSec.

By contrast, OpenVPN's user-space implementation allows portability across operating systems and processor architectures, firewall and NAT-friendly operation, dynamic address support, and multiple protocol support including protocol bridging.

There are advantages and disadvantages to both approaches. The principal advantages of OpenVPN's approach are portability, ease of configuration, and compatibility with NAT and dynamic addresses. The learning curve for installing and using OpenVPN is on par with that of other security-related daemon software such as ssh.

Historically, one of IPSec's advantages has been multi-vendor support, though that is beginning to change as OpenVPN support is beginning to appear on dedicated hardware devices.

While the PPTP protocol has the advantage of a pre-installed client base on Windows platforms, analysis by cryptography experts has revealed security vulnerabilities.

http://openvpn.net/index.php/open-source/339-why-ssl-vpn.html
http://www.ivpn.net/knowledgebase/62/PPTP-vs-L2TP-vs-OpenVPN.html

OpenVPN client - Viscosity on Mac OS X and Windows

OpenVPN client - Viscosity on Mac OS X and Windows
http://www.thesparklabs.com/viscosity/

VPN VS SSH.... what's the difference?

DaveHowe:SSH *as* ssh is just a replacement for telnet - its encrypted, it uses serverside (and optionally, clientside) PKI, but its basically just telnet.

Where SSH overlaps into VPN's duty space is in its support for tunnelling - effectively, you can open a port on one end of the ssh link, and have the other end automatically connect to a port and IP address visible to that end of the link.

lets take an example. you are on your lan, at address (say) 192.168.1.20

you connect using ssh to a server on another lan across the internet, whose local (not internet) address is 192.168.2.20

you have on your network a webserver on 192.168.1.50, and they have one on 192.168.2.50

you can do the following:

you can open a port (say, 8080) on your machine, to connect to the remote webserver. the command would be -L 8080:192.168.2.50:80

anyone who connects to port 8080 on your machine actually connects to the remote webserver

second, you can open a port (say, 8080) on the REMOTE server, and connect to the local webserver. the command would be -R 8080:192.168.1.50:80

THIS tunnel would allow users on the remote lan to connect to 8080 on the remote server, and they would actually connect to YOUR webserver.

finally, you can open a dynamic tunnel, say on port 8080; this will act like a web proxy server, of type "socks 4a". the command would be -D 8080

anyone on your lan who configures their web browser to use a proxy on port 8080 on your machine, will be able to surf the web, however all the network traffic will appear to come from the remote server. consider however a type -D tunnel to be a set of arbitrary tunnels of type -L or -R on-demand; further, software that is "socks aware" knows which port is being opened at the remote site, so provided it also knows what the IP of the remote server is, it can instruct connections back to use the tunnel that gets to itself. socks is the most powerful mode of the three, but is difficult to configure properly so is least used (apart from anonymizing web browsing :)

Now, vpn is a different technology, and works at the router (packet) level not the port level. in essence, it inspects every network packet as it goes past to see if it matches a list of traffic it has been told to pass down the vpn; if it does, it wrappers that one packet in an encrypted "envelope" and sends that envelope to the vpn endpoint where it is decrypted and treated as any other outbound packet from that machine. the main difference is that the packet that leaves the remote vpn endpoint will still have as its source IP the original sender machine, not the endpoint (which is the case with ssh) so any replies to that packet will need to have been told how to route back to the vpn endpoint, or they can't be encrypted to be returned to the original machine.

open a tunn

Reference: http://www.experts-exchange.com/Security/Vulnerabilities/Q_24174061.html

What are the differences between a site-to-site VPN and a VPN client connecting to a VPN server? What protocols are used for these?

What are the differences between a site-to-site VPN and a VPN client connecting to a VPN server? What protocols are used for these?

Site-to-site VPNs connect entire networks to each other -- for example, connecting a branch office network to a company headquarters network. In a site-to-site VPN, hosts do not have VPN client software; they send and receive normal TCP/IP traffic through a VPN gateway. The VPN gateway is responsible for encapsulating and encrypting outbound traffic, sending it through a VPN tunnel over the Internet, to a peer VPN gateway at the target site. Upon receipt, the peer VPN gateway strips the headers, decrypts the content, and relays the packet towards the target host inside its private network.

Remote access VPNs connect individual hosts to private networks -- for example, travelers and teleworkers who need to access their company's network securely over the Internet. In a remote access VPN, every host must have VPN client software (more on this in a minute). Whenever the host tries to send any traffic, the VPN client software encapsulates and encrypts that traffic before sending it over the Internet to the VPN gateway at the edge of the target network. Upon receipt, that VPN gateway behaves as described above for site-to-site VPNs. If the target host inside the private network returns a response, the VPN gateway performs the reverse process to send an encrypted response back to the VPN client over the Internet.

The most common secure tunneling protocol used in site-to-site VPNs is the IPsec Encapsulating Security Payload (ESP), an extension to the standard IP protocol used by the Internet and most corporate networks today. Most routers and firewalls now support IPsec and so can be used as a VPN gateway for the private network behind them. Another site-to-site VPN protocol is Multi-Protocol Label Switching (MPLS), although MPLS does not provide encryption.

Remote access VPN protocols are more varied. The Point to Point Tunneling Protocol (PPTP) has been included in every Windows operating system since Windows 95. The Layer 2 Tunneling Protocol (L2TP) over IPsec is present in Windows 2000 and XP and is more secure than PPTP. Many VPN gateways use IPsec alone (without L2TP) to deliver remote access VPN services. All of these approaches require VPN client software on every host, and a VPN gateway that supports the same protocol and options/extensions for remote access.

Over the past few years, many vendors have released secure remote access products that use SSL and ordinary web browsers as an alternative to IPsec/L2TP/PPTP VPNs. These "SSL VPNs" are often referred to as "clientless," but it is more accurate to say that they use web browsers as VPN clients, usually in combination with dynamically-downloaded software (Java applet, ActiveX control, or temporary Win32 program that is removed when the session ends). Also, unlike PPTP, L2TP, and IPsec VPNs, which connect remote hosts to an entire private network, SSL VPNs tend to connect users to specific applications protected by the SSL VPN gateway.

To learn more about VPN protocols and topologies, watch my New directions in VPN searchSecurity webcast, or read this InfoSec Magazine article on SSL VPNs.

Windows VPN connection

Open Ports: 1723, 500, 1701

Slow VPN Connections

General Print Discussion

Slow VPN Connections

From: (cruzantom) Last Visit: 1/9/04 Posts: 5 Print Email

To: All Posted: Oct 31 01 08:26 AM Message: 1528.1 (1 of 5)

I am using MS VPN client to connect to a Windows NT 4.5 Server but I have sloooow connections. I access the internet via a ADSL FastAccess modem that show a 1,400,000+ connection speed. Without the VPN client it is truly fast but as soon as I use the VPN client it slows down. A recent speed test showed only 14.3 kbps, and that was a good day! Other times it creeps along at 2400 to 9600 baud, even though the speed on the icon shows 1,400,000. Any ideas on how to tweak my settings to speed things up?

Report abuse

From: FalseID4534 (FalseID4534) Last Visit: 1/9/04 Posts: 1 Print Email

To: cruzantom Posted: Jan 09 04 12:58 PM Message: 1528.2 (2 of 5) Reply to 1528.1

it is really slow becasue you are accessing the internet remotely instead of using your own connection...if you have access to the server try using this as a reference http://www.microsoft.com/technet/community/columns/cableguy/cg0103.mspx hope that was what you were looking for --ryan Edited 2/5/06 by Bradley

Report abuse

From: (cruzantom) Last Visit: 1/9/04 Posts: 5 Print Email

To: FalseID4534 Unread Posted: Jan 09 04 01:59 PM Message: 1528.3 (3 of 5) Reply to 1528.2

Thanks for the reference. I had finally figured out the problem after many unsuccessful tries. After unchecking the "Use default . . ." it worked normally.

Report abuse

From: bwad12 (bwad12) Last Visit: 1/31/06 Posts: 1 Print Email

To: cruzantom Unread Posted: Jan 31 06 04:32 PM Message: 1528.4 (4 of 5) Reply to 1528.1

Oh my gosh, I have the same problem and because I am computer dumb, I can't follow what you did, what default did you turn off??? Can you give me step by step...thank you.

Report abuse

From: TheGarrote (TheGarrote) Last Visit: 2/12/06 Posts: 1 Print Email

To: bwad12 Unread Posted: Feb 12 06 01:21 PM Message: 1528.5 (5 of 5) Reply to 1528.4

Here you go. This should be straightforward enough. Bring up the properties window for your VPN connection. Click the Network tab. Select "Internet Protocol (TCP/IP)" Click Properties. Click the Advanced button Uncheck "Use default gateway on remote network". That should do it. If this box is checked, then all of your Internet activity passes through your VPN connection. Not what you'd normally want. Good luck

Event ID 20111, Error 792 or Error 781 When Establishing an L2TP/IPSec Connection

View products that this article applies to.

Article ID	:	247231
Last Review	:	February 28, 2007
Revision	:	3.2

This article was previously published under Q247231

SYMPTOMS

When you attempt to manually establish a Layer 2 Tunneling Protocol (L2TP)/IP Security Protocol (IPSec) connection with a Windows 2000-based server by using the Routing and Remote Access snap-in, you may be unable to do so, and the initiator computer may display the following error message:

Routing and Remote Access
An error occurred during connection of the interface.
The L2TP connection attempt failed because security negotiation timed out.

In addition, the following event is logged in the System event log of the initiator computer:

Source: RemoteAccess
Event ID: 20111
Description: A Demand Dial connection to the remote interface on port VPNx-y was successfully initiated but failed to complete successfully because of the following error: The L2TP connection attempt failed because security negotiation timed out.

NOTE: If the connection is triggered by demand-dial traffic, then only Event 20111 is logged.

When you attempt to establish an L2TP/IPSec connection by using Network and Dial-up Connections, you are unable to do so, and the initiator computer may display the following error message:

Error Connecting to
Connecting to ...
Error 792: The L2TP connection attempt failed because security negotiation timed out.

-or-

Error Connecting to
Connecting to ...
Error 781: Encryption failed because no valid certificate was found.

NOTE: That Event 20111 is not logged at either the client or server when you attempt to establish the connection by using Network and Dial-up Connections.

Back to the top

CAUSE

This issue can occur because of one of the following reasons:

•	The certificate on the virtual private networking (VPN) server is not a valid machine certificate or is missing. If the VPN server got a certificate during the Certificate Authority installation, this certificate is not valid for IPSec machine authentication.
•	The IPSec Policy Agent service is stopped and started without stopping and starting the Routing and Remote Access service on the remote computer.
•	The IPSec Policy Agent service is not running when you start the Routing and Remote Access service.

Back to the top

RESOLUTION

To resolve this issue, do one of the following:

•

Install a valid machine certificate on the VPN server.

•

Stop and start the IPSec Policy Agent service, and then stop and start the Routing and Remote Access service on the remote computer. To do so, use one of the following methods. Back to the top Method 1 1. Click Start, point to Programs, point to Administrative Tools, and then click Computer Management. 2. Double-click Services and Applications, double-click Services, double-click IPSEC Policy Agent, click Stop, click Start, and then click OK. 3. Double-click Routing and Remote Access, click Stop, click Start, and then click OK. Back to the top Method 2 At a command prompt, type the following commands pressing ENTER after each command: net stop policyagent net start policyagent net stop remoteaccess net start remoteaccess NOTE: The IPSec Policy Agent service must be started when the Routing and Remote Access service initializes.

Back to the top

MORE INFORMATION

When you stop and start the IPSec Policy Agent service without stopping and starting the Routing and Remote Access service, the automatic IPSec policy that is usually created for the L2TP/IPSec connection is not created and the connections are not successful.

If you stop the IPSec Policy Agent service while you have active tunnel connections without first stopping the Routing and Remote Access service, the tunnels are unsecured, and data is exposed in the clear. It is recommended that you stop active tunnel connections before you stop the IPSec Policy Agent service.

Note that stopping the IPSec Policy Agent and the Routing and Remote Access services may remove filters that are critical to protecting your computers, and to prevent this downtime in security, it is recommended that you disconnect the network cable.

Back to the top

---

APPLIES TO

•	Microsoft Windows 2000 Server
•	Microsoft Windows 2000 Advanced Server

Back to the top