Re: openvpn to ipsec routing question

2005-11-25 Thread David Bryan

Christoph Leser wrote:


Hello,

the question is about how to route traffic from an openvpn tunnel
to an ipsec tunnel.

This is my setup:

The OpenBSD gateway has an internal (10.0.1.1/24 ) 
and external (x.x.x.x/30) interface.


The internal net is NAT'ed to the external interface to provide 
internet access to hosts on the internal net.


Through the external interface an ipsec SA ( security association ) 
is established ( tunnel mode ) between my internal net ( 10.0.1/24 ) 
and another local net of a remote site ( 10.0.2/24 ).


So hosts on the internal net can reach hosts on the internet 
(being NAT'ed ) as well as hosts on the remote 
private net 10.0.2/24 ( not being NAT'ed ).


Now I have setup an openvpn server on this box. 
This openvpn server gives out addresses from yet 
another net ( 10.0.3/24 ) to the connected clients.


Connections from openvpn clients are NAT'Ed to the internal
interface to make them appear as being directly attached
to the local private net ( 10.0.1/24 ).

So far, it works.

Now I want the clients on the openvpn subnet ( 10.0.3/24 ) to get 
access to the remote side of the ipsec sa ( 10.0.2/24 ).


Here is an excerpt of my ipconfig and routing table

# ifconfig
lo0: flags=8049 mtu 33224
   inet 127.0.0.1 netmask 0xff00
   inet6 ::1 prefixlen 128
   inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6
fxp0: flags=8943 mtu 1500
   address: 00:a0:c9:43:07:20
   media: Ethernet autoselect (100baseTX full-duplex)
   status: active
   inet 10.0.1.1 netmask 0xff00 broadcast 10.0.1.255
   inet6 fe80::2a0:c9ff:fe43:720%fxp0 prefixlen 64 scopeid 0x1
fxp1: flags=8943 mtu 1500
   address: 00:a0:c9:30:b3:34
   media: Ethernet autoselect (10baseT)
   status: active
   inet x.x.x.254 netmask 0xfffc broadcast x.x.x.255
   inet6 fe80::2a0:c9ff:fe30:b334%fxp1 prefixlen 64 scopeid 0x2
pflog0: flags=141 mtu 33224
pfsync0: flags=0<> mtu 2020
enc0: flags=0<> mtu 1536
tun0: flags=8051 mtu 1500
   inet 10.0.3.1 --> 10.0.3.2 netmask 0x


# netstat -rn
Routing tables

Internet:
DestinationGatewayFlags Refs UseMtu  Interface
defaultx.x.x.254  UGS11  1211734  -   fxp1
10.0.3/24  10.0.3.2   UGS 031900  -   tun0
10.0.3.2   10.0.3.1   UH  10  -   tun0
x.x.x.x/30 link#2 UC  10  -   fxp1
127/8  127.0.0.1  UGRS00  33224   lo0
127.0.0.1  127.0.0.1  UH  1  392  33224   lo0
10.0.1/24  link#1 UC 110  -   fxp0

224/4  127.0.0.1  URS 00  33224   lo0

Encap:
Source Port  DestinationPort  Proto 
SA(Address/Proto/Type/Direction)
10.0.2/24  0 10.0.1/24  0 0 y.y.y.y/50/use/in
10.0.1/24  0 10.0.2/24  0 0 y.y.y.y/50/require/out

where x.x.x.x is the external address of my box, y.y.y.y is the
external address of the remote side of the ipsec tunnel.


I expected this to be sufficient for the routing
from 10.0.3/24 to 10.0.2/24.
But it is not.

Using tcpdump I see that packets entering the gateway via the
openvpn tun0 interface destined to some host on 10.0.2/24
do not get routed to the ipsec tunnel but are routed directly
to the external interface, i.e. a packet with 
source ip = 10.0.3.10 and destination ip 10.0.2.1

is routed as is to the external interface.

I assume that the route through the IPSEC SA is not taken into account,
as the packet to be routed is not from the internal interface.

If there were a way to source-nat the packet when it comes in 
via the tun interface, i.e. before the routing is done, maybe

all would be fine. But I don't know a way to achieve this.

The straight forward solution to setup another ipsec tunnel 
between 10.0.2/24 and 10.0.3/24 is out of reach

due to weird administrative constraints.

Any suggestions?

Thanks

Christoph

 

Try something like... (This was goofy the first time I did it, at least 
it didn't quite make since to me..)


route add -net 10.0.2.0/24 10.0.1.1

This will tell the local OS where to send traffic for the 10.0.2.0/24 
network, where as isakmpd only will processes traffic inbound to match 
an SA. (as far as I can tell).


Give it a shot, it should work...

-Dave



Re: openvpn to ipsec routing question

2005-11-23 Thread Joachim Schipper
On Tue, Nov 22, 2005 at 08:31:13PM +0100, Christoph Leser wrote:
> Hello,
> 
> the question is about how to route traffic from an openvpn tunnel
> to an ipsec tunnel.
> 
> This is my setup:
> 
> The OpenBSD gateway has an internal (10.0.1.1/24 ) 
> and external (x.x.x.x/30) interface.
> 
> The internal net is NAT'ed to the external interface to provide 
> internet access to hosts on the internal net.
> 
> Through the external interface an ipsec SA ( security association ) 
> is established ( tunnel mode ) between my internal net ( 10.0.1/24 ) 
> and another local net of a remote site ( 10.0.2/24 ).
> 
> So hosts on the internal net can reach hosts on the internet 
> (being NAT'ed ) as well as hosts on the remote 
> private net 10.0.2/24 ( not being NAT'ed ).
> 
> Now I have setup an openvpn server on this box. 
> This openvpn server gives out addresses from yet 
> another net ( 10.0.3/24 ) to the connected clients.
> 
> Connections from openvpn clients are NAT'Ed to the internal
> interface to make them appear as being directly attached
> to the local private net ( 10.0.1/24 ).
> 
> So far, it works.
> 
> Now I want the clients on the openvpn subnet ( 10.0.3/24 ) to get 
> access to the remote side of the ipsec sa ( 10.0.2/24 ).
> 
> Here is an excerpt of my ipconfig and routing table
> 
> # ifconfig
> lo0: flags=8049 mtu 33224
> inet 127.0.0.1 netmask 0xff00
> inet6 ::1 prefixlen 128
> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6
> fxp0: flags=8943 mtu 1500
> address: 00:a0:c9:43:07:20
> media: Ethernet autoselect (100baseTX full-duplex)
> status: active
> inet 10.0.1.1 netmask 0xff00 broadcast 10.0.1.255
> inet6 fe80::2a0:c9ff:fe43:720%fxp0 prefixlen 64 scopeid 0x1
> fxp1: flags=8943 mtu 1500
> address: 00:a0:c9:30:b3:34
> media: Ethernet autoselect (10baseT)
> status: active
> inet x.x.x.254 netmask 0xfffc broadcast x.x.x.255
> inet6 fe80::2a0:c9ff:fe30:b334%fxp1 prefixlen 64 scopeid 0x2
> pflog0: flags=141 mtu 33224
> pfsync0: flags=0<> mtu 2020
> enc0: flags=0<> mtu 1536
> tun0: flags=8051 mtu 1500
> inet 10.0.3.1 --> 10.0.3.2 netmask 0x
> 
>  
> # netstat -rn
> Routing tables
> 
> Internet:
> DestinationGatewayFlags Refs UseMtu  Interface
> defaultx.x.x.254  UGS11  1211734  -   fxp1
> 10.0.3/24  10.0.3.2   UGS 031900  -   tun0
> 10.0.3.2   10.0.3.1   UH  10  -   tun0
> x.x.x.x/30 link#2 UC  10  -   fxp1
> 127/8  127.0.0.1  UGRS00  33224   lo0
> 127.0.0.1  127.0.0.1  UH  1  392  33224   lo0
> 10.0.1/24  link#1 UC 110  -   fxp0
> 
> 224/4  127.0.0.1  URS 00  33224   lo0
> 
> Encap:
> Source Port  DestinationPort  Proto 
> SA(Address/Proto/Type/Direction)
> 10.0.2/24  0 10.0.1/24  0 0 y.y.y.y/50/use/in
> 10.0.1/24  0 10.0.2/24  0 0 y.y.y.y/50/require/out
> 
> where x.x.x.x is the external address of my box, y.y.y.y is the
> external address of the remote side of the ipsec tunnel.
> 
> 
> I expected this to be sufficient for the routing
> from 10.0.3/24 to 10.0.2/24.
> But it is not.
> 
> Using tcpdump I see that packets entering the gateway via the
> openvpn tun0 interface destined to some host on 10.0.2/24
> do not get routed to the ipsec tunnel but are routed directly
> to the external interface, i.e. a packet with 
> source ip = 10.0.3.10 and destination ip 10.0.2.1
> is routed as is to the external interface.
> 
> I assume that the route through the IPSEC SA is not taken into account,
> as the packet to be routed is not from the internal interface.
> 
> If there were a way to source-nat the packet when it comes in 
> via the tun interface, i.e. before the routing is done, maybe
> all would be fine. But I don't know a way to achieve this.
> 
> The straight forward solution to setup another ipsec tunnel 
> between 10.0.2/24 and 10.0.3/24 is out of reach
> due to weird administrative constraints.
> 
> Any suggestions?

I'm not certain about what to do about the routing, but I'm fairly
certain that all your problems would be easily solved if you would just
use 10.0.0.0/25 for your internal hosts, and 10.0.0.128/25 for your
OpenVPN'ed hosts. Of course, this would require some reconfiguring on
the clients/DHCP server/whatever, but it should work. Especially since
anything but the router already expects to find OpenVPN clients on
10.0.0.0/24.

Otherwise, I see a route-to option in pf.conf(5), which might be used
for explicitly sending packets over encap0... of course, you'd still
need to do NAT or weird stuff would happen, but this might at least get
the routing right. And NAT can come later, if ne

openvpn to ipsec routing question

2005-11-22 Thread Christoph Leser
Hello,

the question is about how to route traffic from an openvpn tunnel
to an ipsec tunnel.

This is my setup:

The OpenBSD gateway has an internal (10.0.1.1/24 ) 
and external (x.x.x.x/30) interface.

The internal net is NAT'ed to the external interface to provide 
internet access to hosts on the internal net.

Through the external interface an ipsec SA ( security association ) 
is established ( tunnel mode ) between my internal net ( 10.0.1/24 ) 
and another local net of a remote site ( 10.0.2/24 ).

So hosts on the internal net can reach hosts on the internet 
(being NAT'ed ) as well as hosts on the remote 
private net 10.0.2/24 ( not being NAT'ed ).

Now I have setup an openvpn server on this box. 
This openvpn server gives out addresses from yet 
another net ( 10.0.3/24 ) to the connected clients.

Connections from openvpn clients are NAT'Ed to the internal
interface to make them appear as being directly attached
to the local private net ( 10.0.1/24 ).

So far, it works.

Now I want the clients on the openvpn subnet ( 10.0.3/24 ) to get 
access to the remote side of the ipsec sa ( 10.0.2/24 ).

Here is an excerpt of my ipconfig and routing table

# ifconfig
lo0: flags=8049 mtu 33224
inet 127.0.0.1 netmask 0xff00
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6
fxp0: flags=8943 mtu 1500
address: 00:a0:c9:43:07:20
media: Ethernet autoselect (100baseTX full-duplex)
status: active
inet 10.0.1.1 netmask 0xff00 broadcast 10.0.1.255
inet6 fe80::2a0:c9ff:fe43:720%fxp0 prefixlen 64 scopeid 0x1
fxp1: flags=8943 mtu 1500
address: 00:a0:c9:30:b3:34
media: Ethernet autoselect (10baseT)
status: active
inet x.x.x.254 netmask 0xfffc broadcast x.x.x.255
inet6 fe80::2a0:c9ff:fe30:b334%fxp1 prefixlen 64 scopeid 0x2
pflog0: flags=141 mtu 33224
pfsync0: flags=0<> mtu 2020
enc0: flags=0<> mtu 1536
tun0: flags=8051 mtu 1500
inet 10.0.3.1 --> 10.0.3.2 netmask 0x

 
# netstat -rn
Routing tables

Internet:
DestinationGatewayFlags Refs UseMtu  Interface
defaultx.x.x.254  UGS11  1211734  -   fxp1
10.0.3/24  10.0.3.2   UGS 031900  -   tun0
10.0.3.2   10.0.3.1   UH  10  -   tun0
x.x.x.x/30 link#2 UC  10  -   fxp1
127/8  127.0.0.1  UGRS00  33224   lo0
127.0.0.1  127.0.0.1  UH  1  392  33224   lo0
10.0.1/24  link#1 UC 110  -   fxp0

224/4  127.0.0.1  URS 00  33224   lo0

Encap:
Source Port  DestinationPort  Proto 
SA(Address/Proto/Type/Direction)
10.0.2/24  0 10.0.1/24  0 0 y.y.y.y/50/use/in
10.0.1/24  0 10.0.2/24  0 0 y.y.y.y/50/require/out

where x.x.x.x is the external address of my box, y.y.y.y is the
external address of the remote side of the ipsec tunnel.


I expected this to be sufficient for the routing
from 10.0.3/24 to 10.0.2/24.
But it is not.

Using tcpdump I see that packets entering the gateway via the
openvpn tun0 interface destined to some host on 10.0.2/24
do not get routed to the ipsec tunnel but are routed directly
to the external interface, i.e. a packet with 
source ip = 10.0.3.10 and destination ip 10.0.2.1
is routed as is to the external interface.

I assume that the route through the IPSEC SA is not taken into account,
as the packet to be routed is not from the internal interface.

If there were a way to source-nat the packet when it comes in 
via the tun interface, i.e. before the routing is done, maybe
all would be fine. But I don't know a way to achieve this.

The straight forward solution to setup another ipsec tunnel 
between 10.0.2/24 and 10.0.3/24 is out of reach
due to weird administrative constraints.

Any suggestions?

Thanks

Christoph