I can confirm this. Spent way too much time in my VMWare lab on this until I thought to add a default route to the host-only interfaces I was running the tunnel on. All you need is default route and it will work. I have found that "fleshed out" config for networking on OpenBSD is a sure way to clear up some of the more strange things that can happen.
On Thu, Feb 23, 2012 at 10:43 AM, Aner Perez <a...@ncstech.com> wrote: > See the thread titled "ipsec tunnel traffic getting icmp host unreachable" > on this same list. > > In short, the answer is that you need a standard route (in addition to the > encap route) to the destination networks. > > Any route that covers your destination network will do. In my case, instead > of adding routes for each of my ipsec tunnels, I just added a default route > and that fixed the problem. It won't actually use the gateway listed on > this route, for that it uses the encap route. > > - Aner > > > On 02/22/2012 05:22 PM, Morten Christensen wrote: >> >> Dear fellow OpenBSD friends. >> >> I'm setting up 2 FW's that should form a VPN tunnel securing the net >> behind each FW - simple >> >> NET x -> FW x -> WAN -> FW y -> NET y >> >> I'm using ipsec.conf / ipsecctl. OpenBSD 5, pf is disabled. >> >> On FW x >> # cat /etc/ipsec.conf >> ike esp from 10.21.35.0/24 to 10.20.0.0/16 peer 212.37.141.59 psk >> "lotsofFishs4meAndyou" >> >> netstat -rn >> Encap: >> Source Port Destination Port Proto >> SA(Address/Proto/Type/Direction) >> 10.20/16 0 10.21.35/24 0 0 >> 212.37.141.59/esp/use/in >> 10.21.35/24 0 10.20/16 0 0 >> 212.37.141.59/esp/require/out >> >> # ipsecctl -sa >> FLOWS: >> flow esp in from 10.20.0.0/16 to 10.21.35.0/24 peer 212.37.141.59 srcid >> 212.37.141.60/32 dstid 212.37.141.59/32 type use >> flow esp out from 10.21.35.0/24 to 10.20.0.0/16 peer 212.37.141.59 srcid >> 212.37.141.60/32 dstid 212.37.141.59/32 type require >> >> SAD: >> esp tunnel from 212.37.141.59 to 212.37.141.60 spi 0xc2e3c650 auth >> hmac-sha2-256 enc aes >> esp tunnel from 212.37.141.60 to 212.37.141.59 spi 0xc5853584 auth >> hmac-sha2-256 enc aes >> >> >> >> On FW y >> # cat /etc/ipsec.conf >> ike esp from 10.20.0.0/16 to 10.21.35.0/24 peer 212.37.141.60 psk >> "lotsofFishs4meAndyou" >> >> netstat -rn >> Encap: >> Source Port Destination Port Proto >> SA(Address/Proto/Type/Direction) >> 10.21.35/24 0 10.20/16 0 0 >> 212.37.141.60/esp/use/in >> 10.20/16 0 10.21.35/24 0 0 >> 212.37.141.60/esp/require/out >> >> # ipsecctl -sa >> FLOWS: >> flow esp in from 10.21.35.0/24 to 10.20.0.0/16 peer 212.37.141.60 srcid >> 212.37.141.59/32 dstid 212.37.141.60/32 type use >> flow esp out from 10.20.0.0/16 to 10.21.35.0/24 peer 212.37.141.60 srcid >> 212.37.141.59/32 dstid 212.37.141.60/32 type require >> >> SAD: >> esp tunnel from 212.37.141.59 to 212.37.141.60 spi 0xc2e3c650 auth >> hmac-sha2-256 enc aes >> esp tunnel from 212.37.141.60 to 212.37.141.59 spi 0xc5853584 auth >> hmac-sha2-256 enc aes >> >> Offcourse on both machines >> net.inet.ip.forwarding=1 >> >> Pinging from a host on NET x >> Request timeout for icmp_seq 1402 >> 36 bytes from 10.21.35.1: Destination Host Unreachable >> Vr HL TOS Len ID Flg off TTL Pro cks Src Dst >> 4 5 00 5400 736e 0 0000 40 01 cfa4 10.21.35.100 10.20.0.10 >> >> The gateway clearly answers that it can't route the packet!? >> >> Pinging directly from FWx to FWy WORKS !!! ??? >> >> # ping -I 10.21.35.1 10.20.0.1 >> PING 10.20.0.1 (10.20.0.1): 56 data bytes >> 64 bytes from 10.20.0.1: icmp_seq=0 ttl=255 time=1.185 ms >> 64 bytes from 10.20.0.1: icmp_seq=1 ttl=255 time=0.829 ms >> Dump while ping >> # tcpdump -i enc0 -n >> tcpdump: listening on enc0, link-type ENC >> 13:52:24.297384 (authentic,confidential): SPI 0xc5853584: 10.21.35.1> >> 10.20.0.1: icmp: echo request (encap) >> 13:52:24.297508 (authentic,confidential): SPI 0xc2e3c650: 10.20.0.1> >> 10.21.35.1: icmp: echo reply (encap) >> 13:52:25.299664 (authentic,confidential): SPI 0xc5853584: 10.21.35.1> >> 10.20.0.1: icmp: echo request (encap) >> 13:52:25.299760 (authentic,confidential): SPI 0xc2e3c650: 10.20.0.1> >> 10.21.35.1: icmp: echo reply (encap) >> >> >> Routing is the problem ? what is the cause ? It looks like each FW doesn't >> permit routing packets from LAN hosts. >> >> Thanks for you help >> >> Regards >> >> Morten Bech Christensen
