Re: OSPFD over IPSEC

2016-11-15 Thread Comète
14 novembre 2016 22:50 "Remi Locherer"  a écrit:
> On
Mon, Nov 14, 2016 at 04:50:21PM +, Comète wrote:
> 
>> 14 novembre 2016
14:50 "Remi Locherer"  a écrit:
>> On
>> 2016-11-14
12:48, Comète wrote:
>> 
>> Hi,
>> I'm trying to run OSPFD over
>> IPSEC with
OpenBSD 6.0 stable, so I first
>> start looking at >
>>
http://undeadly.org/cgi?action=article&sid=20131105075303
>> Now that etherip
>> has it's own interface in 6.0, I tried to replace gif > with
>> etherip
like
>> this:
> 
> [...]
> 
>> Can
>> you show pf.conf? Are there any blocks
if you check on pflog0 with tcpdump?
>> 
>> But why do you want to have
Ethernet frames tunneled? If you use gif
>> interfaces
>> and make ospfd
beeing active on it you save a few bits. That way
>> you can make
>> the MTU
bigger.
>> https://cway.cisco.com/tools/ipsec-overhead-calc can give you
>>
and idea how
>> big your MTU can be (needs an account but is free).
>> 
>> Be
careful when
>> configuring gif interfaces. ospfd only recognizes that it is a
>> 
>> point-to-point interface when you configure the netmask as
255.255.255.255.
>> I finally got it working. I forgot the 'link2' option in
/etc/hostname.bridge0
>> :
>> 
>> -=>> cat /etc/hostname.bridge0
>> add
etherip0 add vether0
>> up link2
>> 
>> but it
>> wasn't enough...
>> I had to
set 'net.inet.etherip.allow=1' in sysctl.conf
>> despite what it is said in
the 'etherip' man page:
>> 
>> "The sysctl(3) variable
>>
net.inet.etherip.allow must be set to 1, unless ipsec(4) is being used to
>>
protect the traffic."
>> 
>> This is what I don't understand, is there any
>>
particular case in this configuration or maybe something changed in 6.0 ?
>>
thanks
> 
> I can not tell you what is wrong with your configuration. Im not
using
> etherip. But why do you think you need to tunnel Ethernet? You don't
need it
> for ospf. rWWith gif interfaces you're doing ip-over-ip and don't
need
> bridge and vether. Then just add the gif interface to ospfd.conf.
I've made another test with GIF and vether interfaces following this tutorial:
http://undeadly.org/cgi?action=article&sid=20131105075303 (the author talked
about multicast problems when using only gif...). It works too and I can see a
bandwith gain of 13 Mbps, with ipsec (aes-128-gcm) and pf enabled, compared to
the same setup with etherip interfaces. But again I needed to set
net.inet.etherip.allow=1 to make it work.



Re: OSPFD over IPSEC

2016-11-14 Thread Comète
14 novembre 2016 22:50 "Remi Locherer"  a écrit:
> On
Mon, Nov 14, 2016 at 04:50:21PM +, Comète wrote:
> 
>> 14 novembre 2016
14:50 "Remi Locherer"  a écrit:
>> On
>> 2016-11-14
12:48, Comète wrote:
>> 
>> Hi,
>> I'm trying to run OSPFD over
>> IPSEC with
OpenBSD 6.0 stable, so I first
>> start looking at >
>>
http://undeadly.org/cgi?action=article&sid=20131105075303
>> Now that etherip
>> has it's own interface in 6.0, I tried to replace gif > with
>> etherip
like
>> this:
> 
> [...]
> 
>> Can
>> you show pf.conf? Are there any blocks
if you check on pflog0 with tcpdump?
>> 
>> But why do you want to have
Ethernet frames tunneled? If you use gif
>> interfaces
>> and make ospfd
beeing active on it you save a few bits. That way
>> you can make
>> the MTU
bigger.
>> https://cway.cisco.com/tools/ipsec-overhead-calc can give you
>>
and idea how
>> big your MTU can be (needs an account but is free).
>> 
>> Be
careful when
>> configuring gif interfaces. ospfd only recognizes that it is a
>> 
>> point-to-point interface when you configure the netmask as
255.255.255.255.
>> I finally got it working. I forgot the 'link2' option in
/etc/hostname.bridge0
>> :
>> 
>> -=>> cat /etc/hostname.bridge0
>> add
etherip0 add vether0
>> up link2
>> 
>> but it
>> wasn't enough...
>> I had to
set 'net.inet.etherip.allow=1' in sysctl.conf
>> despite what it is said in
the 'etherip' man page:
>> 
>> "The sysctl(3) variable
>>
net.inet.etherip.allow must be set to 1, unless ipsec(4) is being used to
>>
protect the traffic."
>> 
>> This is what I don't understand, is there any
>>
particular case in this configuration or maybe something changed in 6.0 ?
>>
thanks
> 
> I can not tell you what is wrong with your configuration. Im not
using
> etherip. But why do you think you need to tunnel Ethernet? You don't
need it
> for ospf. rWWith gif interfaces you're doing ip-over-ip and don't
need
> bridge and vether. Then just add the gif interface to ospfd.conf.


Ok,
good to know, I will test this too. In fact, I will need etherip for some
sites where I use VLANS. But for others, IP over IP will be ok. So thank you
for the advice.

If someone knows why, with etherip over IPSEC, I had to set
'net.inet.etherip.allow=1' in sysctl.conf ? The question is still opened...
Thanks



Re: OSPFD over IPSEC

2016-11-14 Thread Remi Locherer
On Mon, Nov 14, 2016 at 04:50:21PM +, Comète wrote:
> 14 novembre 2016 14:50 "Remi Locherer"  a écrit:
> > On
> 2016-11-14 12:48, Comète wrote:
> > 
> >> Hi,
> >> I'm trying to run OSPFD over
> IPSEC with OpenBSD 6.0 stable, so I first
> >> start looking at >
> http://undeadly.org/cgi?action=article&sid=20131105075303
> >> Now that etherip
> has it's own interface in 6.0, I tried to replace gif > with
> >> etherip like
> this:
[...]
> > Can
> you show pf.conf? Are there any blocks if you check on pflog0 with tcpdump?
> >
> > But why do you want to have Ethernet frames tunneled? If you use gif
> interfaces
> > and make ospfd beeing active on it you save a few bits. That way
> you can make
> > the MTU bigger.
> https://cway.cisco.com/tools/ipsec-overhead-calc can give you
> > and idea how
> big your MTU can be (needs an account but is free).
> > 
> > Be careful when
> configuring gif interfaces. ospfd only recognizes that it is a
> >
> point-to-point interface when you configure the netmask as 255.255.255.255.
> I finally got it working. I forgot the 'link2' option in /etc/hostname.bridge0
> :
> 
> -=>> cat /etc/hostname.bridge0
> add etherip0 add vether0
> up link2
> 
> but it
> wasn't enough...
> I had to set 'net.inet.etherip.allow=1' in sysctl.conf
> despite what it is said in the 'etherip' man page:
> 
> "The sysctl(3) variable
> net.inet.etherip.allow must be set to 1, unless ipsec(4) is being used to
> protect the traffic."
> 
> This is what I don't understand, is there any
> particular case in this configuration or maybe something changed in 6.0 ?
> thanks

I can not tell you what is wrong with your configuration. Im not using
etherip. But why do you think you need to tunnel Ethernet? You don't need it
for ospf. rWWith gif interfaces you're doing ip-over-ip and don't need
bridge and vether. Then just add the gif interface to ospfd.conf.



Re: OSPFD over IPSEC

2016-11-14 Thread Comète
14 novembre 2016 14:50 "Remi Locherer"  a écrit:
> On
2016-11-14 12:48, Comète wrote:
> 
>> Hi,
>> I'm trying to run OSPFD over
IPSEC with OpenBSD 6.0 stable, so I first
>> start looking at >
http://undeadly.org/cgi?action=article&sid=20131105075303
>> Now that etherip
has it's own interface in 6.0, I tried to replace gif > with
>> etherip like
this:
>> On one host:
>> 
>> -=>> cat /etc/hostname.bridge0
>> add
etherip0 add vether0
>> up
>> -=>> cat /etc/hostname.vether0
>> inet
10.60.10.2
>> 255.255.255.0 NONE up
>> -=>> cat /etc/hostname.etherip0
>>
tunnel 1.2.3.4 4.3.2.1
>> up
>> -=>> doas cat /etc/ipsec.conf
>> ike active
esp proto etherip from 1.2.3.4 to
>> 4.3.2.1 psk "mypassword"
>>> -=>> doas
ipsecctl -sa
>> FLOWS:
>> flow esp in proto
>> etherip from 4.3.2.1 to 1.2.3.4
peer 4.3.2.1 srcid 1.2.3.4/32 dstid > 4.3.2.1/32
>> type use
>> flow esp out
proto etherip from 1.2.3.4 to 4.3.2.1 peer 4.3.2.1 srcid
>> 1.2.3.4/32 dstid
4.3.2.1/32 type require
>> SAD:
>> esp tunnel from 4.3.2.1 to
>> 1.2.3.4 spi
0x3d8e9212 auth hmac-sha2-256 enc aes
>> esp tunnel from 1.2.3.4 to
>> 4.3.2.1
spi 0x900fc2c5 auth hmac-sha2-256 enc aes
>>> On the other host:
>>
--
>> -=>> cat /etc/hostname.bridge0
>> add etherip0 add
vether0
>> up
>> -=>> cat /etc/hostname.vether0
>> inet 10.60.10.1
255.255.255.0 NONE up
>> -=>> cat
>> /etc/hostname.etherip0
>> tunnel 4.3.2.1
1.2.3.4 up
>> -=>> doas cat
>> /etc/ipsec.conf
>> ike passive esp proto
etherip from 4.3.2.1 to 1.2.3.4 psk
>> "mypassword"
>>> -=>> doas ipsecctl -sa
>> FLOWS:
>> flow esp in proto etherip from
>> 1.2.3.4 to 4.3.2.1 peer 1.2.3.4
srcid 4.3.2.1/32 dstid 1.2.3.4/32 type > use
>> flow esp out proto etherip
from 4.3.2.1 to 1.2.3.4 peer 1.2.3.4 srcid
>> 4.3.2.1/32 dstid 1.2.3.4/32 type
require
>> SAD:
>> esp tunnel from 4.3.2.1 to
>> 1.2.3.4 spi 0x3d8e9212 auth
hmac-sha2-256 enc aes
>> esp tunnel from 1.2.3.4 to
>> 4.3.2.1 spi 0x900fc2c5
auth hmac-sha2-256 enc aes
>>> I forgot to mention that i
>> didn't set
net.inet.etherip.allow=1 and let it set to 0, as said in > "etherip"
>> man
page, because I use IPSEC.
>> As you can see the ipsec VPN is well
>>
established, but my problem is that I can't ping 10.60.10.1 from > 10.60.10.2
>> and 10.60.10.2 from 10.60.10.1.
>> On each vether interface, tcpdump
-nettti
>> shows me that nothing is going out of them.
>> Any idea ?
> 
> Can
you show pf.conf? Are there any blocks if you check on pflog0 with tcpdump?
>
> But why do you want to have Ethernet frames tunneled? If you use gif
interfaces
> and make ospfd beeing active on it you save a few bits. That way
you can make
> the MTU bigger.
https://cway.cisco.com/tools/ipsec-overhead-calc can give you
> and idea how
big your MTU can be (needs an account but is free).
> 
> Be careful when
configuring gif interfaces. ospfd only recognizes that it is a
>
point-to-point interface when you configure the netmask as 255.255.255.255.
I finally got it working. I forgot the 'link2' option in /etc/hostname.bridge0
:

-=>> cat /etc/hostname.bridge0
add etherip0 add vether0
up link2

but it
wasn't enough...
I had to set 'net.inet.etherip.allow=1' in sysctl.conf
despite what it is said in the 'etherip' man page:

"The sysctl(3) variable
net.inet.etherip.allow must be set to 1, unless ipsec(4) is being used to
protect the traffic."

This is what I don't understand, is there any
particular case in this configuration or maybe something changed in 6.0 ?
thanks



Re: OSPFD over IPSEC

2016-11-14 Thread Comète
14 novembre 2016 14:50 "Remi Locherer"  a écrit:
> On
2016-11-14 12:48, Comète wrote:
> 
>> Hi,
>> I'm trying to run OSPFD over
IPSEC with OpenBSD 6.0 stable, so I first
>> start looking at >
http://undeadly.org/cgi?action=article&sid=20131105075303
>> Now that etherip
has it's own interface in 6.0, I tried to replace gif > with
>> etherip like
this:
>> On one host:
>> 
>> -=>> cat /etc/hostname.bridge0
>> add
etherip0 add vether0
>> up
>> -=>> cat /etc/hostname.vether0
>> inet
10.60.10.2
>> 255.255.255.0 NONE up
>> -=>> cat /etc/hostname.etherip0
>>
tunnel 1.2.3.4 4.3.2.1
>> up
>> -=>> doas cat /etc/ipsec.conf
>> ike active
esp proto etherip from 1.2.3.4 to
>> 4.3.2.1 psk "mypassword"
>>> -=>> doas
ipsecctl -sa
>> FLOWS:
>> flow esp in proto
>> etherip from 4.3.2.1 to 1.2.3.4
peer 4.3.2.1 srcid 1.2.3.4/32 dstid > 4.3.2.1/32
>> type use
>> flow esp out
proto etherip from 1.2.3.4 to 4.3.2.1 peer 4.3.2.1 srcid
>> 1.2.3.4/32 dstid
4.3.2.1/32 type require
>> SAD:
>> esp tunnel from 4.3.2.1 to
>> 1.2.3.4 spi
0x3d8e9212 auth hmac-sha2-256 enc aes
>> esp tunnel from 1.2.3.4 to
>> 4.3.2.1
spi 0x900fc2c5 auth hmac-sha2-256 enc aes
>>> On the other host:
>>
--
>> -=>> cat /etc/hostname.bridge0
>> add etherip0 add
vether0
>> up
>> -=>> cat /etc/hostname.vether0
>> inet 10.60.10.1
255.255.255.0 NONE up
>> -=>> cat
>> /etc/hostname.etherip0
>> tunnel 4.3.2.1
1.2.3.4 up
>> -=>> doas cat
>> /etc/ipsec.conf
>> ike passive esp proto
etherip from 4.3.2.1 to 1.2.3.4 psk
>> "mypassword"
>>> -=>> doas ipsecctl -sa
>> FLOWS:
>> flow esp in proto etherip from
>> 1.2.3.4 to 4.3.2.1 peer 1.2.3.4
srcid 4.3.2.1/32 dstid 1.2.3.4/32 type > use
>> flow esp out proto etherip
from 4.3.2.1 to 1.2.3.4 peer 1.2.3.4 srcid
>> 4.3.2.1/32 dstid 1.2.3.4/32 type
require
>> SAD:
>> esp tunnel from 4.3.2.1 to
>> 1.2.3.4 spi 0x3d8e9212 auth
hmac-sha2-256 enc aes
>> esp tunnel from 1.2.3.4 to
>> 4.3.2.1 spi 0x900fc2c5
auth hmac-sha2-256 enc aes
>>> I forgot to mention that i
>> didn't set
net.inet.etherip.allow=1 and let it set to 0, as said in > "etherip"
>> man
page, because I use IPSEC.
>> As you can see the ipsec VPN is well
>>
established, but my problem is that I can't ping 10.60.10.1 from > 10.60.10.2
>> and 10.60.10.2 from 10.60.10.1.
>> On each vether interface, tcpdump
-nettti
>> shows me that nothing is going out of them.
>> Any idea ?
> 
> Can
you show pf.conf? Are there any blocks if you check on pflog0 with tcpdump?
pf is disabled on both ends

> 
> But why do you want to have Ethernet frames
tunneled? If you use gif interfaces
> and make ospfd beeing active on it you
save a few bits. That way you can make
> the MTU bigger.
https://cway.cisco.com/tools/ipsec-overhead-calc can give you
> and idea how
big your MTU can be (needs an account but is free).

I simply thought that
etherip interface was the new way to go, anyway I just tried the exact same
config as explained here:
http://undeadly.org/cgi?action=article&sid=20131105075303
with gif interfaces
instead etherip and the problem is the same, I can't ping the vether interface
on the other host...

thanks for your help



Re: OSPFD over IPSEC

2016-11-14 Thread Remi Locherer

On 2016-11-14 12:48, Comète wrote:

Hi,

I'm trying to run OSPFD over IPSEC with OpenBSD 6.0 stable, so I first
start looking at 
http://undeadly.org/cgi?action=article&sid=20131105075303
Now that etherip has it's own interface in 6.0, I tried to replace gif 
with

etherip like this:

On one host:


-=>> cat /etc/hostname.bridge0
add etherip0 add vether0
up

-=>> cat /etc/hostname.vether0
inet 10.60.10.2
255.255.255.0 NONE up

-=>> cat /etc/hostname.etherip0
tunnel 1.2.3.4 4.3.2.1
up

-=>> doas cat /etc/ipsec.conf
ike active esp proto etherip from 1.2.3.4 to
4.3.2.1 psk "mypassword"


-=>> doas ipsecctl -sa
FLOWS:
flow esp in proto
etherip from 4.3.2.1 to 1.2.3.4 peer 4.3.2.1 srcid 1.2.3.4/32 dstid 
4.3.2.1/32

type use
flow esp out proto etherip from 1.2.3.4 to 4.3.2.1 peer 4.3.2.1 srcid
1.2.3.4/32 dstid 4.3.2.1/32 type require

SAD:
esp tunnel from 4.3.2.1 to
1.2.3.4 spi 0x3d8e9212 auth hmac-sha2-256 enc aes
esp tunnel from 1.2.3.4 to
4.3.2.1 spi 0x900fc2c5 auth hmac-sha2-256 enc aes


On the other host:
--

-=>> cat /etc/hostname.bridge0
add etherip0 add vether0
up
-=>> cat /etc/hostname.vether0
inet 10.60.10.1 255.255.255.0 NONE up

-=>> cat
/etc/hostname.etherip0
tunnel 4.3.2.1 1.2.3.4 up

-=>> doas cat
/etc/ipsec.conf
ike passive esp proto etherip from 4.3.2.1 to 1.2.3.4 psk
"mypassword"


-=>> doas ipsecctl -sa

FLOWS:
flow esp in proto etherip from
1.2.3.4 to 4.3.2.1 peer 1.2.3.4 srcid 4.3.2.1/32 dstid 1.2.3.4/32 type 
use

flow esp out proto etherip from 4.3.2.1 to 1.2.3.4 peer 1.2.3.4 srcid
4.3.2.1/32 dstid 1.2.3.4/32 type require

SAD:
esp tunnel from 4.3.2.1 to
1.2.3.4 spi 0x3d8e9212 auth hmac-sha2-256 enc aes
esp tunnel from 1.2.3.4 to
4.3.2.1 spi 0x900fc2c5 auth hmac-sha2-256 enc aes


I forgot to mention that i
didn't set net.inet.etherip.allow=1 and let it set to 0, as said in 
"etherip"

man page, because I use IPSEC.

As you can see the ipsec VPN is well
established, but my problem is that I can't ping 10.60.10.1 from 
10.60.10.2

and 10.60.10.2 from 10.60.10.1.

On each vether interface, tcpdump -nettti
shows me that nothing is going out of them.

Any idea ?


Can you show pf.conf? Are there any blocks if you check on pflog0 with 
tcpdump?


But why do you want to have Ethernet frames tunneled? If you use gif 
interfaces
and make ospfd beeing active on it you save a few bits. That way you can 
make
the MTU bigger. https://cway.cisco.com/tools/ipsec-overhead-calc/ can 
give you

and idea how big your MTU can be (needs an account but is free).

Be careful when configuring gif interfaces. ospfd only recognizes that 
it is a
point-to-point interface when you configure the netmask as 
255.255.255.255.




OSPFD over IPSEC

2016-11-14 Thread Comète
Hi,

I'm trying to run OSPFD over IPSEC with OpenBSD 6.0 stable, so I first
start looking at http://undeadly.org/cgi?action=article&sid=20131105075303
Now that etherip has it's own interface in 6.0, I tried to replace gif with
etherip like this:

On one host:


-=>> cat /etc/hostname.bridge0
add etherip0 add vether0
up

-=>> cat /etc/hostname.vether0
inet 10.60.10.2
255.255.255.0 NONE up

-=>> cat /etc/hostname.etherip0
tunnel 1.2.3.4 4.3.2.1
up

-=>> doas cat /etc/ipsec.conf
ike active esp proto etherip from 1.2.3.4 to
4.3.2.1 psk "mypassword"


-=>> doas ipsecctl -sa
FLOWS:
flow esp in proto
etherip from 4.3.2.1 to 1.2.3.4 peer 4.3.2.1 srcid 1.2.3.4/32 dstid 4.3.2.1/32
type use
flow esp out proto etherip from 1.2.3.4 to 4.3.2.1 peer 4.3.2.1 srcid
1.2.3.4/32 dstid 4.3.2.1/32 type require

SAD:
esp tunnel from 4.3.2.1 to
1.2.3.4 spi 0x3d8e9212 auth hmac-sha2-256 enc aes
esp tunnel from 1.2.3.4 to
4.3.2.1 spi 0x900fc2c5 auth hmac-sha2-256 enc aes


On the other host:
--

-=>> cat /etc/hostname.bridge0
add etherip0 add vether0
up
-=>> cat /etc/hostname.vether0
inet 10.60.10.1 255.255.255.0 NONE up

-=>> cat
/etc/hostname.etherip0
tunnel 4.3.2.1 1.2.3.4 up

-=>> doas cat
/etc/ipsec.conf
ike passive esp proto etherip from 4.3.2.1 to 1.2.3.4 psk
"mypassword"


-=>> doas ipsecctl -sa

FLOWS:
flow esp in proto etherip from
1.2.3.4 to 4.3.2.1 peer 1.2.3.4 srcid 4.3.2.1/32 dstid 1.2.3.4/32 type use
flow esp out proto etherip from 4.3.2.1 to 1.2.3.4 peer 1.2.3.4 srcid
4.3.2.1/32 dstid 1.2.3.4/32 type require

SAD:
esp tunnel from 4.3.2.1 to
1.2.3.4 spi 0x3d8e9212 auth hmac-sha2-256 enc aes
esp tunnel from 1.2.3.4 to
4.3.2.1 spi 0x900fc2c5 auth hmac-sha2-256 enc aes


I forgot to mention that i
didn't set net.inet.etherip.allow=1 and let it set to 0, as said in "etherip"
man page, because I use IPSEC.

As you can see the ipsec VPN is well
established, but my problem is that I can't ping 10.60.10.1 from 10.60.10.2
and 10.60.10.2 from 10.60.10.1. 

On each vether interface, tcpdump -nettti
shows me that nothing is going out of them.

Any idea ?

 
Thanks,

Morgan



Re: OSPFd over IPSEC (enc)?

2005-06-17 Thread Stephen Marley
On Thu, Jun 16, 2005 at 12:51:53PM -0700, Michael Favinsky wrote:
> Can two 3.7 servers running OSPFd talk OSPF to each other over an IPSEC
> tunnel, or worded in another way, an enc interface?
> 
> I have two sites with a WAN link and I want to use the Internet (VPN) as a
> backup route. The concept is that under normal circumstances, the OSPF
> routing table would have valid routes between the two sites over both the
> VPN and WAN links. If the WAN link failed, there'd still be a valid route
> between the two sites over VPN.

I have exactly this situation working with a gre tunnel over ipsec
(using isakmpd). I'm not sure if it will work with enc as ospf needs
multicast ability, which I don't believe is supported by straight ipsec.
(I could well be wrong here).

Openbsd's ospfd (beautiful work from Esben Norby and Claudio Jeker) is
ideal for this, although it is still work in progress. Zebra (quagga
from packages or ports) also works well, but its configuration and
operation is ugly in comparison to the native daemon.

Let me know if you want any help with the configs.

-- 
stephen



Re: OSPFd over IPSEC (enc)? - OT

2005-06-16 Thread jared r r spiegel
On Thu, Jun 16, 2005 at 10:50:10PM +0200, Claudio Jeker wrote:
> 
> AFAIK it was not yet tested. I'm not sure if it will work because the enc
> interface is not a real interface. I know it works over gre tunnels.
> Using the enc device may work but I'm not sure about it (until now I never
> had to use IPsec).

  i was able to use enc0 (after throwing an IP on it) as the local endpoint
  to match an IPsec flow such as:

172.16.2.2/32   0   172.16.1.1/32   0   0   66.55.44.77/50/use/in
172.16.1.1/32   0   172.16.2.2/32   0   0   
66.55.44.77/50/require/out

  where 172.16.1.1/32 was the IP i threw on enc0.

  ( eg, i could ping -I 172.16.1.1 172.16.2.2 ok, and other side could 
ping -I 172.16.2.2 172.16.1.1 OK )

  though, to be fair, i changed the way i was doing things and decided to
  not put the IP on enc0, so i didn't give it a lot of testing.

  jun.10 snapshots

  jared

- 

[ openbsd 3.7 GENERIC ( jun 3 ) // i386 ]



Re: OSPFd over IPSEC (enc)?

2005-06-16 Thread tony sarendal
On 16/06/05, Michael Favinsky <[EMAIL PROTECTED]> wrote:
> Can two 3.7 servers running OSPFd talk OSPF to each other over an IPSEC
> tunnel, or worded in another way, an enc interface?
> 
> I have two sites with a WAN link and I want to use the Internet (VPN) as a
> backup route. The concept is that under normal circumstances, the OSPF
> routing table would have valid routes between the two sites over both the
> VPN and WAN links. If the WAN link failed, there'd still be a valid route
> between the two sites over VPN.
> 

if you want to do things like dynamic routing over IPsec use a
tunneling protocol like IPIP(gif) or GRE. Set up the tunnel and the
just configure IPsec to encrypt the tunnel.

/Tony S



Re: OSPFd over IPSEC (enc)?

2005-06-16 Thread Claudio Jeker
On Thu, Jun 16, 2005 at 12:51:53PM -0700, Michael Favinsky wrote:
> Can two 3.7 servers running OSPFd talk OSPF to each other over an IPSEC
> tunnel, or worded in another way, an enc interface?
> 
> I have two sites with a WAN link and I want to use the Internet (VPN) as a
> backup route. The concept is that under normal circumstances, the OSPF
> routing table would have valid routes between the two sites over both the
> VPN and WAN links. If the WAN link failed, there'd still be a valid route
> between the two sites over VPN.
> 

AFAIK it was not yet tested. I'm not sure if it will work because the enc
interface is not a real interface. I know it works over gre tunnels.
Using the enc device may work but I'm not sure about it (until now I never
had to use IPsec).

Btw. use -current ospfd and ospfctl because many bug fixes and additional
features went into the tree lately.
-- 
:wq Claudio



OSPFd over IPSEC (enc)?

2005-06-16 Thread Michael Favinsky
Can two 3.7 servers running OSPFd talk OSPF to each other over an IPSEC
tunnel, or worded in another way, an enc interface?

I have two sites with a WAN link and I want to use the Internet (VPN) as a
backup route. The concept is that under normal circumstances, the OSPF
routing table would have valid routes between the two sites over both the
VPN and WAN links. If the WAN link failed, there'd still be a valid route
between the two sites over VPN.

Please forgive the following disclaimer - I have no control over it.


This message may contain information that is privileged, confidential and
exempt from disclosure under applicable law. If you are not the intended
recipient of this message you may not store, disclose, copy, forward,
distribute or use this message or its contents for any purpose. If you have
received this communication in error, please notify us immediately by return
e-mail and delete the original message and any attachments from your e-mail
system. Thank you.