Hi,
I have a VPN running that roughly looks like this:
LOCAL REMOTE
-----------------------------------------------------
10.0.0.0/16 \ / mobile users
10.1.0.0/16 +- gateway - Internet -+- other users
10.6.0.0/16/ \ subsidiary
Please assume that the gateway has the IP number 1.2.3.4. The VPN has a
hub-and-spoke topology, generally speaking.
The central gateway runs OpenBSD 4.3, the gateway at the subsidiary
site runs OpenBSD 4.2. I've configured everything using
isakmpd.conf+isakmpd.policy, and didn't yet figure out a way to move to
ipsec.conf, with my mix of certificates, shared secrets, fixed and
variable IP numbers, distinctive encryption algorithms, etc.
The mobile users are configured via IKE to get one IP address out of
10.3.0.0, with a default route through the gateway on the other side.
The other users get various IP addresses assigned, or provide their own
networks, and the subsidiary has 10.4.0.0/16.
I attach one network per location, so, for the connection with the
subsidiary, routing looks like this, when saying "netstat -rnf encap":
Source Destination SA...
10.0.0.0/15 10.4.0.0/16 1.2.3.4 and
10.4.0.0/16 10.0.0.0/15 1.2.3.4
Routing for mobile clients looks like this:
10.3.1.1 default 1.2.3.4 and
default 10.3.1.1 1.2.3.4
(one pair per client)
Everything worked very well so far...
The problem:
I'd like to establish reachability between 10.4.0.0/16 and 10.6.0.0/16.
So I thought I'd configure the subsidiary to have a default route to
the VPN in the same way that I announce a default route to the mobile
clients. I use the following stanza for this purpose:
[default-route]
ID-type= IPV4_ADDR_SUBNET
Network= 0.0.0.0
Netmask= 0.0.0.0
On the gateways, I switched the Phase2 IDs from
[east]
ID-type= IPV4_ADDR_SUBNET
Network= 10.0.0.0
Netmask= 255.254.0.0
to 'default-route' ('east' = central site).
But while doing so enables connectivity from the subsidiary to all
other nets (as could be confirmed using 'ping'), most applications
between the subsidiary and the central site, even in 10.0.0.0/15, break
horribly, and in unforseeable ways. Eg. telnet sessions breaking
half-way through, or other applications working only partially.
Reverting the change to only route to one network immediately "fixed"
the problem, sans the missing route to 10.6.0.0/16.
While debugging, I saw weird things like the gateway on the remote side
sending bogus (!) fragmentation messages for MTUs much smaller than the
default MTUs I've configured, to clients at the remote side, which
should have stayed in the remote network, over the VPN to the central
network, or clients in the remote network suddenly sending floods of
RST packets, where I couldn't discover the reason why they were sent,
for otherwise running applications.
The question:
How can I enable routing to discontiguous networks over VPN, and/or
what can I do to debug this problem further?
Kind regards,
--Toni++
