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 "<SNIP: Router 1>" \ dstid "<SNIP: Router 2>" ## 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 "<SNIP: Router 2>" \ dstid "<SNIP: Router 1>" 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 <SNIP: Router 1> dstid <SNIP: Router 2> type use flow esp out from 0.0.0.0/0 to 172.16.5.2 peer 172.16.5.2 srcid <SNIP: Router 1> dstid <SNIP: Router 2> type require flow esp in from 172.16.7.0/24 to 0.0.0.0/0 peer 172.16.5.2 srcid <SNIP: Router 1> dstid <SNIP: Router 2> type use flow esp out from 0.0.0.0/0 to 172.16.7.0/24 peer 172.16.5.2 srcid <SNIP: Router 1> dstid <SNIP: Router 2> type require flow esp in from 172.16.6.0/24 to 0.0.0.0/0 peer 172.16.5.2 srcid <SNIP: Router 1> dstid <SNIP: Router 2> type use flow esp out from 0.0.0.0/0 to 172.16.6.0/24 peer 172.16.5.2 srcid <SNIP: Router 1> dstid <SNIP: Router 2> 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 <SNIP: Router 2> dstid <SNIP: Router 1> type use flow esp out from 172.16.5.2 to 0.0.0.0/0 peer 172.16.5.1 srcid <SNIP: Router 2> dstid <SNIP: Router 1> type require flow esp in from 0.0.0.0/0 to 172.16.7.0/24 peer 172.16.5.1 srcid <SNIP: Router 2> dstid <SNIP: Router 1> type use flow esp out from 172.16.7.0/24 to 0.0.0.0/0 peer 172.16.5.1 srcid <SNIP: Router 2> dstid <SNIP: Router 1> type require flow esp in from 0.0.0.0/0 to 172.16.6.0/24 peer 172.16.5.1 srcid <SNIP: Router 2> dstid <SNIP: Router 1> type use flow esp out from 172.16.6.0/24 to 0.0.0.0/0 peer 172.16.5.1 srcid <SNIP: Router 2> dstid <SNIP: Router 1> 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 local networks. Normally this wouldn't happen because the local networks wouldn't be included in the networks of the other side of the tunnel. For example, if I try to ping 172.16.5.21 (the wireless bridge local to Router 2) from Router 2, then it should send ICMP echo requests out over the local interface connecting to the wireless bridge. This works fine before ISAKMPD establishes the tunnel. After the tunnel is established, it starts encapsulating the ICMP echo packets and sending them down the tunnel, where they get blackholed: # ping 172.16.5.21 PING 172.16.5.21 (172.16.5.21): 56 data bytes --- 172.16.5.21 ping statistics --- 11 packets transmitted, 0 packets received, 100.0% packet loss # tcpdump -nvvvpi enc0 tcpdump: listening on enc0, link-type ENC tcpdump: WARNING: compensating for unaligned libpcap packets <SNIP> 13:21:13.960188 (authentic,confidential): SPI 0x67eec1f6: 172.16.5.2 > 172.16.5.1: 172.16.5.2 > 172.16.5.21: icmp: echo request (id:1370 seq:0) [icmp cksum ok] (ttl 255, id 35507, len 84) (ttl 255, id 35507, len 84) <SNIP> 13:21:14.960396 (authentic,confidential): SPI 0x67eec1f6: 172.16.5.2 > 172.16.5.1: 172.16.5.2 > 172.16.5.21: icmp: echo request (id:1370 seq:1) [icmp cksum ok] (ttl 255, id 39619, len 84) (ttl 64, id 24561, len 104) <SNIP> ^C 65 packets received by filter 0 packets dropped by kernel So, I think I understand the problem, but I don't have any idea what the solution would be. I tried adding manual "bypass" flows to the ipsec.conf of Router 2, to no avail: flow esp from 172.16.5.0/24 to 172.16.5.0/24 type bypass flow esp from 172.16.6.0/24 to 172.16.6.0/24 type bypass flow esp from 172.16.7.0/24 to 172.16.7.0/24 type bypass What is the correct way to implement this scenario, while still directing the default route over the IPSEC tunnel? Thanks so much...! Joe Crivello
