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<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?
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 necessary.
Of course, both are a bit of a kludge. Would it be permissible to just
use the same DHCP server for the internal clients and OpenVPN? That
would make it easy to keep both on the same net, they would be pretty
much intermixed but you can always filter by the interface where they
came from.
Joachim
