Re: Problem With Default Route Over IPSEC Site-To-Site Tunnel VPN
ing 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 Router 1> dstid type use flow esp out from 0.0.0.0/0 to
> 172.16.5.2 peer 172.16.5.2 srcid Router 1> dstid type require flow esp in from
> 172.16.7.0/24
> to 0.0.0.0/0 peer 172.16.5.2 srcid Router 1> dstid type use flow esp out from 0.0.0.0/0 to
> 172.16.7.0/24 peer 172.16.5.2 srcid Router 1> dstid type require flow esp in from
> 172.16.6.0/24
> to 0.0.0.0/0 peer 172.16.5.2 srcid Router 1> dstid type use flow esp out from 0.0.0.0/0 to
> 172.16.6.0/24 peer 172.16.5.2 srcid Router 1> 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 Router 2> dstid type use flow esp out from 172.16.5.2 to
> 0.0.0.0/0 peer 172.16.5.1 srcid Router 2> dstid type require flow esp in from 0.0.0.0/0
> to
> 172.16.7.0/24 peer 172.16.5.1 srcid Router 2> dstid type use flow esp out from 172.16.7.0/24
> to
> 0.0.0.0/0 peer 172.16.5.1 srcid Router 2> dstid type require flow esp in from 0.0.0.0/0
> to
> 172.16.6.0/24 peer 172.16.5.1 srcid Router 2> dstid type use flow esp out from 172.16.6.0/24
> to
> 0.0.0.0/0 peer 172.16.5.1 srcid Router 2> 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 h
Re: Problem With Default Route Over IPSEC Site-To-Site Tunnel VPN
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
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
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 blackh
