Hi All, The problem I experienced was indeed in a testbed between an Alix and Soekris (not part of the problem:-) And the reason was that none of the VPN endpoints had a default gw (they share a common wan subnet while I should trial an ipsec solution)
I gave both of the a default GW IP that pointed to the other box WAN address and sure thing - EVERYTHING WORKS Thanks guys for prompt and competent help, I sincerely respect you're expertise!!! Den 23/02/2012 kl. 17.40 skrev Russell Garrison: > 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
