Troubleshooting VPNs

You can collect more detailed information by enabling the IPsec diagnostics. For VPN
clients, also enable authentication and DHCP relay diagnostics.
Log messages generated by Access rules might also contain relevant information.
These logs contain information about the connections that the gateway processes, and
whether policy-based VPN traffic is directed correctly to VPN tunnels by the policy. Log
messages generated by Access rules are not included if you are filtering the logs to only
show IPsec logs.
A normal IPsec tunnel negotiation proceeds as follows:

1. The negotiations start when a connection matches a rule in the Firewall Policy
that triggers the VPN negotiation (or a similar mechanism at the other end).
2. The gateway at the source end of the connection or the VPN client (the initiator,
I) contacts the gateway at the other end (the responder, R). The gateways
establish trust and exchange keys in the IKE Phase 1 negotiations.
3. If Phase 1 negotiation succeeds, IKE Phase 2 negotiations begin. At this stage,
the gateways agree on further settings used for handling the connection.
4. If Phase 2 negotiations succeed, the VPN tunnel is ready and ESP or AH
packets (the actual traffic) can be seen in the logs. New connections that are
opened through the VPN are logged using a VPN-specific log message “New
Connection Through VPN.”

All shared servers are at the central office, and internal emails and other
communications are also handled by the central servers. There is no need for secure
connectivity between the remote offices.
All Firewalls have a public IP address toward the Internet. The internal networks at each
site use private IP addresses. There is no need to translate the VPN traffic, since all
offices use their own distinct address space.
The security policy of the company requires certificate-based authentication. The
administrators decide to use the Management Server’s Internal RSA CA for Gateways
for issuing the VPN certificates.
The administrators:

1. Select each engine’s public IP address as the VPN endpoint and activate
automatic certificate management.
2. Add Site elements for all gateways, and add the entire local internal network as
the content for each Site.
 3. Create a VPN Profile and select RSA Encryption as the authentication method.
RSA certificates are automatically generated for each gateway.
4. Create a Policy-Based VPN element called “Inter-Office VPN” that includes the
central office gateway as a central gateway and the two remote site gateways as
satellite gateways.
5. Add the following types of Access rules in the policy of the central office firewall:

An example of a policy-based VPN that allows mobile users to authenticate and connect
to internal networks.
Company A has service technicians and salespeople who must be able to connect to
their office networks to access information when they are on customer visits. The
administrators need to add VPN client access to the existing VPN infrastructure. The
administrators decide to use Stonesoft VPN Client. As the authentication method, the
administrators decide to use passwords stored in the Management Server’s internal
database.
The administrators also want to provide only one point of access so that the users do
not have to select which gateway to connect to. The central office has site-to-site VPN
tunnels to both remote offices that can be used for forwarding traffic to those sites as
needed. The existing DHCP server at the central office can be used for assigning IP
addresses to the VPN clients’ Virtual Adapter. A Virtual Adapter is required for this type
of forwarding.
The administrators:

1. Edit the central office firewall element and activate the Virtual Adapter method for
VPN client address management.
2. Edit the VPN Profile to use Hybrid Authentication for authenticating the VPN
client users.
3. Create a Policy-Based VPN element called “Remote User VPN” that includes the
central office gateway as a Central Gateway.
4. Select the Only central Gateways from overall topology option on the Mobile
VPN tab.
5. Create a “Forward Addresses” Site element under the central office gateway.
6. Populate the site with the remote office networks to route those IP addresses
through the “Remote User VPN”.
7. Disable the “Forward Addresses” Site in the existing “Inter-Office VPN” between
the central office and the remote offices. Sites are global for all policy-based
VPNs, so this Site must be disabled to avoid a misconfiguration in the Inter-Office
VPN.
8. Create User Group and User elements to define the user names and passwords
for the VPN client users.
9. Add the following Access rules in the policy of the central office firewall: