Re: IPSEC Site-to-Site not routing packages
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 DestinationPort Proto SA(Address/Proto/Type/Direction) 10.20/16 0 10.21.35/240 0 212.37.141.59/esp/use/in 10.21.35/240 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 DestinationPort Proto SA(Address/Proto/Type/Direction) 10.21.35/240 10.20/16 0 0 212.37.141.60/esp/use/in 10.20/16 0 10.21.35/240 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 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
Re: IPSEC Site-to-Site not routing packages
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 DestinationPort Proto SA(Address/Proto/Type/Direction) 10.20/16 0 10.21.35/240 0 212.37.141.59/esp/use/in 10.21.35/240 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 DestinationPort Proto SA(Address/Proto/Type/Direction) 10.21.35/240 10.20/16 0 0 212.37.141.60/esp/use/in 10.20/16 0 10.21.35/240 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 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
Re: IPSEC Site-to-Site not routing packages - SOLVED
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 DestinationPort Proto SA(Address/Proto/Type/Direction) 10.20/16 0 10.21.35/240 0 212.37.141.59/esp/use/in 10.21.35/240 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 DestinationPort Proto SA(Address/Proto/Type/Direction) 10.21.35/240 10.20/16 0 0 212.37.141.60/esp/use/in 10.20/16 0 10.21.35/240 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 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
IPSEC Site-to-Site not routing packages
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 DestinationPort Proto SA(Address/Proto/Type/Direction) 10.20/16 0 10.21.35/240 0 212.37.141.59/esp/use/in 10.21.35/240 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 DestinationPort Proto SA(Address/Proto/Type/Direction) 10.21.35/240 10.20/16 0 0 212.37.141.60/esp/use/in 10.20/16 0 10.21.35/240 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 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
