I was able to resolve my own problem.
The solution I found was to create a gre tunnel between the two routers
using the gre(4) pseudo-device. Once I had that working, I used IPSEC
transport mode to protect the GRE tunnel. This method eliminates all default
encap routes from both routers; which was the root cause of the problem.
-Joe
-Original Message-
From: Joe Crivello [mailto:josephcrive...@gmail.com]
Sent: Monday, December 15, 2014 2:24 PM
Subject: Problem With Default Route Over IPSEC Site-To-Site Tunnel VPN
Hello,
I am having a problem with a particular aspect of my attempt to establish an
IPSEC site-to-site tunnel between two gateways using ISAKMPD/IKEv1. I seem
to be doing something wrong, but I have exhausted all of the resources that
I know of in my quest to fix the problem (MAN pages, OpenBSD.org FAQ,
Google, etc). I am hoping that someone with more OpenBSD experience than
myself will be able to help me... either way, thanks so much for your time!
The routers in question both run OpenBSD 5.6, situated at either end of long
range wifi bridge link. Router "1" also has a interface connecting to an ISP
router, which provides a route to the Internet:
Internet <==> Router 1
172.16.5.1
||
Wifi
||
172.16.5.2
Router 2 <==> Local Networks
(172.16.6.1/24, 172.16.7.1/24)
The intention is to establish an IPSEC tunnel between Router 1 and Router 2,
over which Router 2 should send all traffic not destined for one of it's
local networks. Accordingly, I set the default route of Router 2 to
172.16.5.1, and I configured the tunnel like so:
## Router 1
ike passive esp \
from any to { 172.16.5.2/32, 172.16.6.0/24, 172.16.7.0/24 } \
local 172.16.5.1 peer 172.16.5.2 \
main auth hmac-sha2-512 enc aes-256 group modp2048 \
quick auth hmac-sha2-512 enc aes-256-ctr group modp2048 \
srcid "" \
dstid ""
## Router 2
ike active esp \
from { 172.16.5.2/32, 172.16.6.0/24, 172.16.7.0/24 } to any \
local 172.16.5.2 peer 172.16.5.1 \
main auth hmac-sha2-512 enc aes-256 group modp2048 \
quick auth hmac-sha2-512 enc aes-256-ctr group modp2048 \
srcid "" \
dstid ""
This configuration (correctly) causes six SAs to be established:
## Router 1
# ipsecctl -sa
FLOWS:
flow esp in from 172.16.5.2 to 0.0.0.0/0 peer 172.16.5.2 srcid dstid type use flow esp out from 0.0.0.0/0 to
172.16.5.2 peer 172.16.5.2 srcid dstid type require flow esp in from 172.16.7.0/24
to 0.0.0.0/0 peer 172.16.5.2 srcid dstid type use flow esp out from 0.0.0.0/0 to
172.16.7.0/24 peer 172.16.5.2 srcid dstid type require flow esp in from 172.16.6.0/24
to 0.0.0.0/0 peer 172.16.5.2 srcid dstid type use flow esp out from 0.0.0.0/0 to
172.16.6.0/24 peer 172.16.5.2 srcid dstid type require
SAD:
esp tunnel from 172.16.5.2 to 172.16.5.1 spi 0x0eec4a02 auth hmac-sha2-512
enc aes-256-ctr esp tunnel from 172.16.5.1 to 172.16.5.2 spi 0x1cde0906 auth
hmac-sha2-512 enc aes-256-ctr esp tunnel from 172.16.5.2 to 172.16.5.1 spi
0x6769c99e auth hmac-sha2-512 enc aes-256-ctr esp tunnel from 172.16.5.2 to
172.16.5.1 spi 0xad29e69c auth hmac-sha2-512 enc aes-256-ctr esp tunnel from
172.16.5.1 to 172.16.5.2 spi 0xaf8c3502 auth hmac-sha2-512 enc aes-256-ctr
esp tunnel from 172.16.5.1 to 172.16.5.2 spi 0xcdad877e auth hmac-sha2-512
enc aes-256-ctr
## Router 2
# ipsecctl -sa
FLOWS:
flow esp in from 0.0.0.0/0 to 172.16.5.2 peer 172.16.5.1 srcid dstid type use flow esp out from 172.16.5.2 to
0.0.0.0/0 peer 172.16.5.1 srcid dstid type require flow esp in from 0.0.0.0/0 to
172.16.7.0/24 peer 172.16.5.1 srcid dstid type use flow esp out from 172.16.7.0/24 to
0.0.0.0/0 peer 172.16.5.1 srcid dstid type require flow esp in from 0.0.0.0/0 to
172.16.6.0/24 peer 172.16.5.1 srcid dstid type use flow esp out from 172.16.6.0/24 to
0.0.0.0/0 peer 172.16.5.1 srcid dstid type require
SAD:
esp tunnel from 172.16.5.2 to 172.16.5.1 spi 0x0eec4a02 auth hmac-sha2-512
enc aes-256-ctr esp tunnel from 172.16.5.1 to 172.16.5.2 spi 0x1cde0906 auth
hmac-sha2-512 enc aes-256-ctr esp tunnel from 172.16.5.2 to 172.16.5.1 spi
0x6769c99e auth hmac-sha2-512 enc aes-256-ctr esp tunnel from 172.16.5.2 to
172.16.5.1 spi 0xad29e69c auth hmac-sha2-512 enc aes-256-ctr esp tunnel from
172.16.5.1 to 172.16.5.2 spi 0xaf8c3502 auth hmac-sha2-512 enc aes-256-ctr
esp tunnel from 172.16.5.1 to 172.16.5.2 spi 0xcdad877e auth hmac-sha2-512
enc aes-256-ctr
The problem is that as soon as these flows are established, Router 2 becomes
unreachable from all of it's local networks (and vice-versa). This appears
to occur because the flows specify that all traffic originating from Router
2's IP addresses (172.16.5.2, 172.16.6.1, and 172.16.7.1) should be
protected with ESP. Thus, Router 2 starts to encapsulate all traffic
originating from it's IPs, even if it is destined for one of it's lo
