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<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33224
        inet 127.0.0.1 netmask 0xff000000
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6
fxp0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        address: 00:a0:c9:43:07:20
        media: Ethernet autoselect (100baseTX full-duplex)
        status: active
        inet 10.0.1.1 netmask 0xffffff00 broadcast 10.0.1.255
        inet6 fe80::2a0:c9ff:fe43:720%fxp0 prefixlen 64 scopeid 0x1
fxp1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        address: 00:a0:c9:30:b3:34
        media: Ethernet autoselect (10baseT)
        status: active
        inet x.x.x.254 netmask 0xfffffffc broadcast x.x.x.255
        inet6 fe80::2a0:c9ff:fe30:b334%fxp1 prefixlen 64 scopeid 0x2
pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33224
pfsync0: flags=0<> mtu 2020
enc0: flags=0<> mtu 1536
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
        inet 10.0.3.1 --> 10.0.3.2 netmask 0xffffffff

 
# netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags     Refs     Use    Mtu  Interface
default            x.x.x.254          UGS        11  1211734      -   fxp1
10.0.3/24          10.0.3.2           UGS         0    31900      -   tun0
10.0.3.2           10.0.3.1           UH          1        0      -   tun0
x.x.x.x/30         link#2             UC          1        0      -   fxp1
127/8              127.0.0.1          UGRS        0        0  33224   lo0
127.0.0.1          127.0.0.1          UH          1      392  33224   lo0
10.0.1/24          link#1             UC         11        0      -   fxp0

224/4              127.0.0.1          URS         0        0  33224   lo0

Encap:
Source             Port  Destination        Port  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

Reply via email to