| VPN policy can now be determined via routing
| | Change: |
Before v8.20.00, the only way to tell the firewall that a particular
connection should be encrypted, was to use the "Secure" flag in the
ruleset.
As of v8.20.00, it is also possible to specify VPN tunnels as
destination interfaces in the routing table(s).
| | Enables: |
In addition to the configuration becoming more intuitive in the
common case, this change also enables the following:
| » | Logging through VPN connections
However, note that directing log data over VPN tunnels means
that all log events that occur while the VPN tunnel is down will be lost.
| | » | Automatic Access list handling for VPNs
Routed VPN connections are automatically included in automatic
Access list lookups just like any other route -- no need to
manually add Accept/Expect rules for routed VPN connections.
| | » | DHCP relaying over LAN-to-LAN tunnels.
Simply create relaying rules in the DHCP relayer like you
would for normal interfaces. It is even possible to use
the same local and remote network and let the relayer add
proxy ARPed routes.
| | » | "Virtual IP" (DHCP over IPsec) for VPN clients.
In addition to creating DHCP relaying rules, check the "Allow
DHCP over IPsec for single-host clients" checkbox in the VPN
properties dialog. This second step is needed because DHCP
needs a separate tunnel for the initial IP address "0.0.0.0".
| | » | Ruleset filtering using VPN destination interfaces.
The same way that it is possible to filter on physical
destination interfaces, it is possible to filter on
VPN destination interfaces, as long as routing is used
rather than "Secure" rules.
| | » | Connections back to roaming clients.
With a route pointing back to the client, either through
routes created by the DHCP relayer, or through routes
automatically created when the client connects (see VPN
tunnel properties -> routing), it is possible to allow
connections back to roaming clients even though one
does not know their IP addresses. Just filter on
the destination VPN interface in the ruleset.
|
| | Note: |
When you route traffic through a VPN tunnel, you should not use the
"Secure" flag in the ruleset for this traffic. Doing so will work,
but will bypass the routing information and attempt to figure out
which tunnel to use by looking in the VPN connections list, just
like it used to before 8.20.00.
| | Hint: |
To make an exception for traffic that is normally routed over
a VPN tunnel, simply use policy based routing to specify
different routing information for the traffic in question.
|
| "Always-up" VPN tunnels with improved keepalives
| | Change: |
New keepalive options have been added for VPN tunnels, that
monitor the health of the actual IPsec tunnel. If the tunnel
is non-operational for some reason (i.e. the remote peer has
rebooted and lost all SAs), the tunnel will quickly be closed
and re-established.
This is implemented through pinging an IP address on the
other side of the tunnel, preferably the IP address of
the remote gateway. When both gateways are Clavister Firewall
v8.20+, the addresses can be computed automatically. When
other gateways are involved, they can be specified manually.
| | Enables: |
Since this form of keepalives always ensures that the tunnel
is operational, it can be enabled on roaming gateways to
always ensure connectivity from the main network to the
remote network without having to resort to DNS resolution
and DynDNS registration of the roaming gateway; tunnels never
need to be initiated by the main gateway to the
roaming gateway.
Enabling keepalives on all lan-to-lan tunnels is likely
also a good idea in general, to avoid problems that can
otherwise result when e.g. one of the gateways is rebooted.
|
| Multiple VPN tunnels using the same local/remote networks now possible
| | Issue: |
When using certificate based authentication, it may be desirable
to have multiple VPN tunnels (with the same local and remote
network settings) for purposes of logical separation in the ruleset.
This is a non-issue with PSK based authentication, as there is
no way to separate which peer should use which tunnel.
| | Change: |
As of v8.20.00, having multiple VPN connections with the same
local/remote networks is possible.
|
| IPsec NAT traversal made controllable
| | Issue: |
When NAT traversal was implemented, we assumed that automatic sensing of
whether or not it was needed (and supported by the other end) would be
enough. This has not not been the case.
| » | Many broadband routers and other NATing gateways implement special
"IPsec passthrough" NAT code which assumes that only plain ESP encapsulation
is used, and will misbehave fatally when UDP encapsulation is actually used.
This is ironic, seeing as how IPsec UDP encapsulation is specifically designed to
traverse NATing gateways without requiring the gateway to have specific knowledge
of IPsec.
This scenario is solved by disabling NAT-T for such tunnels.
| | » | Some IPsec gateways become confused when they see a peer that advertises
NAT traversal support, but deems its use unnecessary, and does not request NAT-T.
Sonicwall gateways reportedly have this problem.
This scenario is solved by either disabling NAT-T, or forcing it to on.
|
| | Change: |
As of v8.10.02 and v8.20.00, there is a setting in the VPN tunnel properties
dialog, which allows NAT traversal to be configured as follows:
| » | Always off, even if a NAT is detected.
| | » | On, if a NAT is detected, and the peer supports it (this is the default).
| | » | On, regardless of the presence of a NAT, as long as the peer supports it.
|
|
|