Re: Using OpenBSD with Amazon's Virtual Private Cloud, IPsec issue

2010-01-13 Thread Stuart Henderson
On 2010-01-13, Matt Dainty  wrote:
> * Stuart Henderson  [2010-01-12 17:02:39]:
>> Their examples are using route-based VPNs (http://kb.juniper.net/KB4124,
>> RFC3884), I'm not sure whether this is entirely possible here with our
>> ipsec (policy-based), but you could try setting up tunnels between the
>> gif tunnel endpoints i.e. 1.2.3.4 and 72.21.209.225, and a second between
>> 1.2.3.4 and 72.21.209.193. These would take place of the tunnels between
>> 192.168.23/24 and 10/24 (traffic between these networks would be routed
>> in the usual way, taking the gif interfaces as point-to-point links).
>
> RFC3884 uses transport mode to secure the already encapsulated traffic
> whereas I have to use tunnel mode.

Take another look; IKE is done as for tunnel mode (i.e. it tells the
peer to use tunnel mode), but then it's setup as for transport mode,
with the gif header inserted. This is the same packet format as used
by tunnel mode, it's interoperable with tunnel mode on the other side
(see the end of section 4.2.3).

> Any attempts to negotiate a transport mode SA are refused

I think that to support it, isakmpd would need to be able to
negotiate a tunnel mode SA with the peer, but would need to
configure the local side as for transport mode.



Re: Using OpenBSD with Amazon's Virtual Private Cloud, IPsec issue

2010-01-13 Thread Matt Dainty
* Stuart Henderson  [2010-01-12 17:02:39]:
> Their examples are using route-based VPNs (http://kb.juniper.net/KB4124,
> RFC3884), I'm not sure whether this is entirely possible here with our
> ipsec (policy-based), but you could try setting up tunnels between the
> gif tunnel endpoints i.e. 1.2.3.4 and 72.21.209.225, and a second between
> 1.2.3.4 and 72.21.209.193. These would take place of the tunnels between
> 192.168.23/24 and 10/24 (traffic between these networks would be routed
> in the usual way, taking the gif interfaces as point-to-point links).

RFC3884 uses transport mode to secure the already encapsulated traffic
whereas I have to use tunnel mode. This is a shame as this method would
work fine on OpenBSD, I remember doing it previously with another network.

Any attempts to negotiate a transport mode SA are refused and when I tried
your suggestion of creating an SA between just the tunnel endpoints, it
was successfully negotiated but the packets just get dropped by the remote
end.

I'll post on Amazon's forums and see if there's any plan to support the
RFC3884 style way of doing this.

Cheers

Matt



Re: Using OpenBSD with Amazon's Virtual Private Cloud, IPsec issue

2010-01-12 Thread Stuart Henderson
Their examples are using route-based VPNs (http://kb.juniper.net/KB4124,
RFC3884), I'm not sure whether this is entirely possible here with our
ipsec (policy-based), but you could try setting up tunnels between the
gif tunnel endpoints i.e. 1.2.3.4 and 72.21.209.225, and a second between
1.2.3.4 and 72.21.209.193. These would take place of the tunnels between
192.168.23/24 and 10/24 (traffic between these networks would be routed
in the usual way, taking the gif interfaces as point-to-point links).


On 2010-01-12, Matt Dainty  wrote:
> Hi,
>
> I'm trying to evaluate using OpenBSD with Amazon's Virtual Private Cloud as a
> "Customer Gateway" in their EC2-speak. What you need to do is create a tunnel
> to each of Amazon's two routers, use BGP to exchange routes across the tunnels
> and protect all the traffic with IPsec.
>
> I've got it mostly working, but I've hit an issue with the IPsec and I'm
> hoping someone might know what's going on.
>
> I've made the various API calls as per the getting started guide [1] and
> have the configuration in the generic format which you can see an example of
> in the network admin guide [2]. Assume my uplink address is 1.2.3.4 and I
> have a BGP ASN of 65023, my network is 192.168.23.0/24 and the remote
> network where my EC2 instances will appear is 10.0.0.0/24.
>
> Here's what I've done, first create two gif(4) tunnels:
>
> # ifconfig gif1 create
> # ifconfig gif1 tunnel 1.2.3.4 72.21.209.225
> # ifconfig gif1 169.254.255.2 169.254.255.1 prefixlen 32
> # ifconfig gif2 create
> # ifconfig gif2 tunnel 1.2.3.4 72.21.209.193
> # ifconfig gif2 169.254.255.6 169.254.255.5 prefixlen 32
>
> Add the following to /etc/ipsec.conf:
>
> ike dynamic esp from 169.254.255.2 to 169.254.255.1 \
>   local 1.2.3.4 peer 72.21.209.225 \
>   main auth hmac-sha1 enc aes group modp1024 \
>   quick auth hmac-sha1 enc aes group modp1024 \
>   srcid 1.2.3.4 \
>   psk XXX
> ike dynamic esp from 169.254.255.6 to 169.254.255.5 \
>   local 1.2.3.4 peer 72.21.209.193 \
>   main auth hmac-sha1 enc aes group modp1024 \
>   quick auth hmac-sha1 enc aes group modp1024 \
>   srcid 1.2.3.4 \
>   psk YYY
>
> Run isakmpd and load those two tunnels:
>
> # isakmpd -4 -K
> # ipsecctl -f /etc/ipsec.conf
>
> "ipsecctl -s all" confirms those are loaded and I can ping the two tunnel
> endpoints successfully. I've added pf rules to allow ESP and UDP 500 on the
> external interface and for now I'm skipping gif1, gif2 and enc0 to hopefully
> exclude pf as a potential source of any trouble.
>
> Now I've created /etc/bgpd.conf
>
> AS 65023
> router-id 1.2.3.4
> listen on 127.0.0.1
> listen on 169.254.255.2
> listen on 169.254.255.6
>
> group "amazon" {
>   remote-as 7224
>   holdtime 30
>   holdtime min 30
>   announce default-route
>   announce IPv6 none
>   announce IPv4 unicast
>
>   neighbor 169.254.255.1 {
>   local-address 169.254.255.2
>   }
>
>   neighbor 169.254.255.5 {
>   local-address 169.254.255.6
>   }
> }
>
> Fire up bgpd and confirm it's working:
>
> # bgpctl show nexthop   
> Nexthop  State 
> 169.254.255.5valid gif2UP
> 169.254.255.1valid gif1UP
> # route -n get 10.0.0.0
>route to: 10.0.0.0
> destination: 10.0.0.0
>mask: 255.255.255.0
> gateway: 169.254.255.6
>   interface: gif2
>  if address: 169.254.255.6
>priority: 48 (bgp)
>   flags: 
>  use   mtuexpire
>   24 0 0 
>
> Now here's where I've got stuck. If I try and ping an EC2 instance from my
> network, I see the plain gif traffic leaving the external interface and gets
> dropped by the remote router as it's not protected with IPsec. This makes
> sense as there's no flow defined that will match that traffic, so I add two
> further tunnels to /etc/ipsec.conf:
>
> ike dynamic esp from 192.168.23.0/24 to 10.0.0.0/24 \
>   local 1.2.3.4 peer 72.21.209.225 \
>   main auth hmac-sha1 enc aes group modp1024 \
>   quick auth hmac-sha1 enc aes group modp1024 \
>   srcid 1.2.3.4 \
>   psk XXX
> ike dynamic esp from 192.168.23.0/24 to 10.0.0.0/24 \
>   local 1.2.3.4 peer 72.21.209.193 \
>   main auth hmac-sha1 enc aes group modp1024 \
>   quick auth hmac-sha1 enc aes group modp1024 \
>   srcid 1.2.3.4 \
>   psk YYY
>
> Now, only the latter tunnel gets configured, I'm guessing this is because the
> from+to tuple is identical so I'm configuring the same tunnel twice just with
> a different peer and key. As long as the routing decides to use the tunnel
> that is configured between the second peer, everything works, I can ping and
> SSH to my EC2 instance, but if it switches to the tunnel configured between
> the first peer then it breaks.
>
> Is it possible to have both configured somehow?
>
> Thanks
>
> Matt
>
> [1] http://docs.amazonwebservices.com/AmazonVPC/latest/GettingStartedGuide/
> [2] http://docs.amazonwebservice

Using OpenBSD with Amazon's Virtual Private Cloud, IPsec issue

2010-01-12 Thread Matt Dainty
Hi,

I'm trying to evaluate using OpenBSD with Amazon's Virtual Private Cloud as a
"Customer Gateway" in their EC2-speak. What you need to do is create a tunnel
to each of Amazon's two routers, use BGP to exchange routes across the tunnels
and protect all the traffic with IPsec.

I've got it mostly working, but I've hit an issue with the IPsec and I'm
hoping someone might know what's going on.

I've made the various API calls as per the getting started guide [1] and
have the configuration in the generic format which you can see an example of
in the network admin guide [2]. Assume my uplink address is 1.2.3.4 and I
have a BGP ASN of 65023, my network is 192.168.23.0/24 and the remote
network where my EC2 instances will appear is 10.0.0.0/24.

Here's what I've done, first create two gif(4) tunnels:

# ifconfig gif1 create
# ifconfig gif1 tunnel 1.2.3.4 72.21.209.225
# ifconfig gif1 169.254.255.2 169.254.255.1 prefixlen 32
# ifconfig gif2 create
# ifconfig gif2 tunnel 1.2.3.4 72.21.209.193
# ifconfig gif2 169.254.255.6 169.254.255.5 prefixlen 32

Add the following to /etc/ipsec.conf:

ike dynamic esp from 169.254.255.2 to 169.254.255.1 \
local 1.2.3.4 peer 72.21.209.225 \
main auth hmac-sha1 enc aes group modp1024 \
quick auth hmac-sha1 enc aes group modp1024 \
srcid 1.2.3.4 \
psk XXX
ike dynamic esp from 169.254.255.6 to 169.254.255.5 \
local 1.2.3.4 peer 72.21.209.193 \
main auth hmac-sha1 enc aes group modp1024 \
quick auth hmac-sha1 enc aes group modp1024 \
srcid 1.2.3.4 \
psk YYY

Run isakmpd and load those two tunnels:

# isakmpd -4 -K
# ipsecctl -f /etc/ipsec.conf

"ipsecctl -s all" confirms those are loaded and I can ping the two tunnel
endpoints successfully. I've added pf rules to allow ESP and UDP 500 on the
external interface and for now I'm skipping gif1, gif2 and enc0 to hopefully
exclude pf as a potential source of any trouble.

Now I've created /etc/bgpd.conf

AS 65023
router-id 1.2.3.4
listen on 127.0.0.1
listen on 169.254.255.2
listen on 169.254.255.6

group "amazon" {
remote-as 7224
holdtime 30
holdtime min 30
announce default-route
announce IPv6 none
announce IPv4 unicast

neighbor 169.254.255.1 {
local-address 169.254.255.2
}

neighbor 169.254.255.5 {
local-address 169.254.255.6
}
}

Fire up bgpd and confirm it's working:

# bgpctl show nexthop   
Nexthop  State 
169.254.255.5valid gif2UP
169.254.255.1valid gif1UP
# route -n get 10.0.0.0
   route to: 10.0.0.0
destination: 10.0.0.0
   mask: 255.255.255.0
gateway: 169.254.255.6
  interface: gif2
 if address: 169.254.255.6
   priority: 48 (bgp)
  flags: 
 use   mtuexpire
  24 0 0 

Now here's where I've got stuck. If I try and ping an EC2 instance from my
network, I see the plain gif traffic leaving the external interface and gets
dropped by the remote router as it's not protected with IPsec. This makes
sense as there's no flow defined that will match that traffic, so I add two
further tunnels to /etc/ipsec.conf:

ike dynamic esp from 192.168.23.0/24 to 10.0.0.0/24 \
local 1.2.3.4 peer 72.21.209.225 \
main auth hmac-sha1 enc aes group modp1024 \
quick auth hmac-sha1 enc aes group modp1024 \
srcid 1.2.3.4 \
psk XXX
ike dynamic esp from 192.168.23.0/24 to 10.0.0.0/24 \
local 1.2.3.4 peer 72.21.209.193 \
main auth hmac-sha1 enc aes group modp1024 \
quick auth hmac-sha1 enc aes group modp1024 \
srcid 1.2.3.4 \
psk YYY

Now, only the latter tunnel gets configured, I'm guessing this is because the
from+to tuple is identical so I'm configuring the same tunnel twice just with
a different peer and key. As long as the routing decides to use the tunnel
that is configured between the second peer, everything works, I can ping and
SSH to my EC2 instance, but if it switches to the tunnel configured between
the first peer then it breaks.

Is it possible to have both configured somehow?

Thanks

Matt

[1] http://docs.amazonwebservices.com/AmazonVPC/latest/GettingStartedGuide/
[2] http://docs.amazonwebservices.com/AmazonVPC/2009-07-15/NetworkAdminGuide/