The URL:
http://digitalfreaks.org/~lavalamp/openbsd_ipsec_generic.png
Outlines the generic cookie-cutter configuration from vpn(8) with
addressing changes. A couple of comments on that document:
*) The output of 'netstat -rn -f encap' should probably be included at the
end.
*) ...possibly in combination with mentioning enc(4) and some example
output of 'tcpdump -n -i enc0' watching ping(8) traffic. I can submit
patches if needed.
*) One thing that is not obvious is the nature of the routing behavior.
Similar to Cisco ACLs, the isakmpd(8) Remote-ID and Local-ID definitions
designate traffic to encrypt, but they're also used as one of many factors
in choosing a proposal.
*) Hosts on 192.168.0.0/24 can reach hosts in 192.168.10.0/24 & vice-
versa, Hosts on 192.168.1.0/24 can reach hosts in 192.168.10.0/24 &
vice-versa.
*) Neither router/vpn termination point can communicate with the remote
subnet via the tunnel unless the application specifically binds to the
Inet address on the Lan0 side of the host. For example:
# ping -I [Lan0] [Remote Lan0]
# traceroute -s [Lan0] [Remote Lan0]
... thereby creating traffic with a IP Source Address that matches the
ACL.
This caveat is not at all obvious and probably should be explicitly
pointed out in vpn(8) or elsewhere.
Another Hypothetical Situation (Routing/Subnets/GRE)
http://digitalfreaks.org/~lavalamp/openbsd_ipsec_sit1.png
http://digitalfreaks.org/~lavalamp/openbsd_ipsec_sit2.png
Let's say Facility 2 as depicted assumes the role of a "VPN Concentrator
", i.e.:
*) A second subnet is added to Facility 1's Lan1 Interface
*) A 2nd remote facility's VPN, Facility 3, becomes terminated here.
*) A tunnel between Facilities 1 and 3 is not available.
*) Because of the poor addressing scheme used in such a network, the two
/24s located at Location 1 cannot both be visible via the Tunnel between
Location 2 and Location 1 because *only one subnet* per Phase1/Phase2
connection , can be specified in the Remote-ID/Local-ID.
*) Of course, if 192.168.0.0/24 and 192.168.0.1/24 were located at Site 1
and 192.168.2.0/24 was located at at Site 3, an IPV4_ADDR_SUBNET with a
Subnet=255.255.254.0 could simply be used to specify the aggregate of two
/24s (a /23)
*) Per Andre Ruppert <[EMAIL PROTECTED]>:
http://www.monkey.org/openbsd/archive/misc/0302/msg01895.html
...a work-around to this would be a separate Phase 1 and Phase 2
connection must be built between Location 1 and Location 2 for every
Discontinuous subnet, which does not scale well.
*) Although the remote networks of each tunnel are known via 'netstat -rn
-f encap' on each machine, authentic routes do not exist in "route(8)
print" output; -- possibly because instead of a route being associated
with an Interface or a Next-Hop gateway, they are known via an SA?
*) Therefore, it is not possible to add static routes that reference the
tunnel.
Example, if Location 2 were to try to add a route to 192.168.2.0/24 via
192.168.0.1 (a Lan0 interface in Location 1, which is reachable via the
Tunnel / SA, and would be happy to forward traffic to 192.168.2.0/24), the
route add would fail:
# route add -net 192.168.2.0 192.168.0.1 255.255.255.0
route: writing to routing socket: Network is unreachable
add net 192.168.2.0: gateway 192.168.0.1: Network is unreachable
...which makes sense because the routing process would traditionally need
to know a directly connected interface with an address in a subnet to
forward to, in this case, no interface exists.
Additionally, even if there was a static route, the source-address of
packets from subnet 192.168.2.0/24 would not match the SA's ACL and would
be dropped anyway.
*) This presents a dilemma. Location 2 cannot act in the capacity of a
"VPN Concentrator" if it cannot advertise routes into a larger network
environment because any number of subnets could exist at any location
which may want to access resources at any other location. The source and
destination addresses vary greatly, but if my understanding is correct,
only one subnet can be specified per tunnel using ISAKMPD in OpenBSD
*) One cheap hack would be to use NAT to change up the source addresses,
but then pf(4) ACLs become harder to control access.
*) In a Cisco IOS environment, IP extended ACLs are used to designate
crypto maps of interesting traffic. The syntax is comparable in
flexibility to pf.conf(5) and any number of source/destinations can be
included flagged per tunnel.
*) Another option would be to change from TUNNEL mode to TRANSPORT mode in
Quick mode transforms/suites and then create GRE tunnels between all of
the routers. The Remote/Local-ID Definition could specifically designate
IP Protocol 47 (GRE) for encryption:
[machineB-to-machineA]
ID-type= IPV4_ADDR
Address= 10.0.99.0
Protocol= 47
This configuration works well under minimal load. All GRE traffic is
encrypted, but TCP/UDP/ISAKMP control traffic (UDP/500), and ESP/AH, are
free to flow unencrypted.
However, it seems to be the best solution for mature networks where
addressing schemes are less than optimal. For example in the example
above...:
....if Location 1 had a GRE tunnel to Location 2 as 10.0.0.0/30, .1 being
at Location 1, .2 at Location 2,
....and Location 3 had a tunnel to Location 2, 10.0.0.4/30, .5 at Location
3, .6 at Location 2:
The routing tables would resemble (GRE interface routes excluded):
[Location 1]
192.168.0.0/24 via [EMAIL PROTECTED]
192.168.2.0/24 via [EMAIL PROTECTED]
192.168.10.0/24 via 10.0.0.2/32 @ gre0
192.168.1.0/24 via 10.0.0.2/32 @ gre0
[Location 2]
192.168.10.0/24 via [EMAIL PROTECTED]
192.168.0.0/24 via 10.0.0.1/32 @ gre0
192.168.2.0/24 via 10.0.0.1/32 @ gre0
192.168.1.0/24 via 10.0.0.5/32 @ gre1
[Location 3]
192.168.1.0/24 via [EMAIL PROTECTED]
192.168.10.0/24 via 10.0.0.6/32 @ gre0
192.168.0.0/24 via 10.0.0.6/32 @ gre0
192.168.2.0/24 via 10.0.0.6/32 @ gre0
Then any number of subnets behind each location's respective routers could
access resources across a VPN enabled WAN, because as the packet enters
the GRE tunnel, the source address gets re-written and is automatically
encrypted by egressing the GRE.
However I'm having a lot of panic's in this configuration under heavy
load(*).
*) A better solution would be more flexible ACLs in isakmpd(8). How hard
would it be to modify isakmp(8) to permit multiple source /destination
ACLs to be exchanged per tunnel (phase1/phase2).
l8*
-lava
x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8
