On Sat, 23 Jul 2005, Hans-Joerg Hoexer wrote:
Hi,
On Fri, Jul 22, 2005 at 06:43:34PM -0400, Brian A. Seklecki wrote:
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:
[...]
yes, please.
For the record, before I submit this PR, here is the generic isakmpd.conf
from my lab:
---------------
[General]
Listen-on= 192.168.100.2
Default-Phase-1-Lifetime= 600,60:900
Default-Phase-2-Lifetime= 300,60:900
[Phase 1]
192.168.100.1= ISAKMP-peer-Concentrator
[Phase 2]
Connections= IPsec-PghToConcentrator
[ISAKMP-peer-Concentrator]
Phase= 1
Transport= udp
Address= 192.168.100.1
Configuration= Default-main-mode
Authentication= lies
[IPsec-PghToConcentrator]
Phase= 2
ISAKMP-peer= ISAKMP-peer-Concentrator
Configuration= Default-quick-mode
Local-ID= Net-Pgh
Remote-ID= Net-Concentrator
[Net-Pgh]
ID-type= IPV4_ADDR
Address= 192.168.100.2
Protocol= 47
[Net-Concentrator]
ID-type= IPV4_ADDR
Address= 192.168.100.1
Protocol= 47
[Default-main-mode]
DOI= IPSEC
EXCHANGE_TYPE= ID_PROT
Transforms= 3DES-SHA
[Default-quick-mode]
DOI= IPSEC
EXCHANGE_TYPE= QUICK_MODE
Suites= QM-ESP-TRP-3DES-MD5-SUITE
------
The otherside is understandably opposite in respective places.
I create my tunnels:
# ifconfig gre0 create
# ifconfig gre0 192.168.200.2 192.168.200.1 netmask 0xffffffff link0 up
# ifconfig gre0 tunnel 192.168.100.2 192.168.100.1
-----------
Routing tables
Encap: Source Port Destination Port Proto SA(Address/Proto/Type/Direction)
192.168.100.1/32 0 192.168.100.2/32 0 47 192.168.100.1/50/use/in
192.168.100.2/32 0 192.168.100.1/32 0 47 192.168.100.1/50/require/out
sadb_dump: satype esp vers 2 len 39 seq 0 pid 0
errno 89: Unknown error: 89
sa: spi 0x2f88fffb auth hmac-md5 enc 3des-cbc
state larval replay 16 flags 0
lifetime_cur: alloc 0 bytes 0 add 1122327771 first 0
lifetime_soft: alloc 0 bytes 0 add 1080 first 0
lifetime_hard: alloc 0 bytes 0 add 1200 first 0
address_src: 192.168.100.2
address_dst: 192.168.100.1
identity_src: type prefix id 0: 192.168.100.2/32
identity_dst: type prefix id 0: 192.168.100.1/32
key_auth: bits 128: 0a4e518fdb7dfdf5d3a32b1e486490a7
key_encrypt: bits 192:
d11e3b020f96c8160fdd8bee9778e2acee2790cd5be31e86
sadb_dump: satype esp vers 2 len 39 seq 0 pid 0
errno 89: Unknown error: 89
sa: spi 0xf75988c3 auth hmac-md5 enc 3des-cbc
state larval replay 0 flags 0
lifetime_cur: alloc 0 bytes 0 add 1122327768 first 0
lifetime_soft: alloc 0 bytes 0 add 1080 first 0
lifetime_hard: alloc 0 bytes 0 add 1200 first 0
address_src: 192.168.100.1
address_dst: 192.168.100.2
identity_src: type prefix id 0: 192.168.100.1/32
identity_dst: type prefix id 0: 192.168.100.2/32
key_auth: bits 128: 6d4096f6a3971b31b2a1642fb6563cc8
key_encrypt: bits 192:
4e833ca770b3c9409c7308522fa2ed8ad73a05911beaacab
sadb_dump: satype esp vers 2 len 39 seq 0 pid 0
errno 89: Unknown error: 89
sa: spi 0x0e22792c auth hmac-md5 enc 3des-cbc
state larval replay 16 flags 0
lifetime_cur: alloc 0 bytes 0 add 1122327771 first 0
lifetime_soft: alloc 0 bytes 0 add 1080 first 0
lifetime_hard: alloc 0 bytes 0 add 1200 first 0
address_src: 192.168.100.1
address_dst: 192.168.100.2
identity_src: type prefix id 0: 192.168.100.1/32
identity_dst: type prefix id 0: 192.168.100.2/32
key_auth: bits 128: aaab5a489fe9c6fe7f950ecd7e8665c6
key_encrypt: bits 192:
aabf088d4bb7928dd5d3515359fdc0a0c7bbd1bc11a705ab
sadb_dump: satype esp vers 2 len 39 seq 0 pid 0
errno 89: Unknown error: 89
sa: spi 0x61def2ad auth hmac-md5 enc 3des-cbc
state larval replay 0 flags 0
lifetime_cur: alloc 0 bytes 0 add 1122327768 first 0
lifetime_soft: alloc 0 bytes 0 add 1080 first 0
lifetime_hard: alloc 0 bytes 0 add 1200 first 0
address_src: 192.168.100.2
address_dst: 192.168.100.1
identity_src: type prefix id 0: 192.168.100.2/32
identity_dst: type prefix id 0: 192.168.100.1/32
key_auth: bits 128: 96bcaad8da66a92d67247f1bcc8ab0e1
key_encrypt: bits 192:
1fe5ada905338811fa97ad1af009e11f2237c434a225fc00
When I start isakmpd(8), i can use tcpdump(8) to see that the only traffic
between 192.168.100.2 and 192.168.100.1 that is encrypted (seen via enc0)
is GRE encapsulated traffic:
At that point in time:
*) Both machines can scp(1) a 10mb file via thier 192.168.100.0/24
(ethernet) addresses w/ no problem
*) Both machines can ICMP ping each other via GRE tunnel addresses
(192.168.200.0/30) and the traffic is encrypted and encapsulated (see
above).
lan interface:
17:49:54.836478 192.168.100.1 > 192.168.100.2: icmp: echo request
17:49:54.836544 192.168.100.2 > 192.168.100.1: icmp: echo reply
17:50:54.861069 esp 192.168.100.1 > 192.168.100.2 spi 0x0E22792C seq 4 len124
17:50:54.861396 esp 192.168.100.2 > 192.168.100.1 spi 0x2F88FFFB seq 3 len124
enc0 interface:
17:51:09.725927 (authentic,confidential): SPI 0x0e22792c: 192.168.200.1 >
192.168.200.2: icmp: echo request (gre encap)
17:51:09.726007 (authentic,confidential): SPI 0x2f88fffb: 192.168.200.2 >
192.168.200.1: icmp: echo reply (gre encap)
*) If a high volume TCP socket like the above scp(1) occurs between the
machines GRE interfaces, the machine hard-resets.
- No KDB/GDB prompt
- No errors to the console
*) I've ran memtest86+ on both machines to eliminate hardware problems.
The two units are entirely different hardware on the i386 platform.
~BAS
...
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(*).
please file a bug report as described in http://www.openbsd.org/report.html
l8*
-lava
x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8
