[Openswan Users] Site-to-site + OpenVPN

Simon Deziel simon at xelerance.com
Thu May 9 18:46:05 UTC 2013

Say the left side has and the right has and they are
connected by a transport mode IPsec connection.

Once this IPsec connection is up, OpenVPN will connect from -> and this will be covered by IPsec.

The fact that OpenVPN will later assign a client IP (ex to its
tun interface has really nothing to do with IPsec. As far as IPsec is
concerned it is only carrying UDP traffic between and

So really close to GRE encapsulation except that with OpenVPN you get
another layer of encryption.

On 13-05-09 02:29 PM, Leto wrote:
> if your openvpn client gets and that source ip needs to make it to the 2nd ipsec server you cannot
use transport mode, as the ipsec as transport mode would only cover the
ipsec gw ips and not hence needing NAT then
> sent from a tiny device 
> On 2013-05-09, at 13:38, Simon Deziel <simon at xelerance.com> wrote:
>> On 13-05-09 12:57 PM, Leto wrote:
>>> openvpn gives an ip to the user.
>> OpenVPN creates a tun (or tap) device that gets an IP but that's not the
>> point. The actual OpenVPN traffic is only between the 2 endpoints so it
>> is secure-able by IPsec in transport mode.
>>> you cannot use transport mode to forward that using ipsec to another host, unless natted to the host ip. whether public or private ips are used for openvpn is irrelevant
>> No NAT'ing is needed. One other way to compare this OpenVPN over IPsec
>> is like GRE over IPsec.
>>> sent from a tiny device 
>>> On 2013-05-09, at 10:05, Simon Deziel <simon at xelerance.com> wrote:
>>>> Right, I wasn't clear in my reply. My recommendation to use IPsec in
>>>> transport mode isn't compatible with Neal's recommendation to use
>>>> private IPs for the OpenVPN connection.
>>>> To use IPsec in transport mode and an OpenVPN tunnel on top, both
>>>> endpoint have to use their public IPs for the 2 VPNs.
>>>> In that scenario, since OpenVPN will be bound to the public IP too I'd
>>>> recommend to firewall it with something like this to require IPsec:
>>>> iptables -A INPUT -p udp --dport 1399 -m policy --dir in \
>>>>          --proto esp -j ACCEPT
>>>> iptables -A INPUT -p udp --dport 1399 -j DROP
>>>> Adapt for a TCP based OpenVPN configuration.
>>>> Regards
>>>> Simon
>>>> On 13-05-08 07:13 PM, Leto wrote:
>>>>> you cannot use transport in this scenario unless you double NAT it
>>>>> sent from a tiny device 
>>>>> On 2013-05-08, at 18:39, Simon Deziel <simon at xelerance.com> wrote:
>>>>>> Hi,
>>>>>> On 13-05-08 05:13 PM, Neal Murphy wrote:
>>>>>>> On Wednesday, May 08, 2013 04:02:34 PM Damir Reic wrote:
>>>>>>>> Hello,
>>>>>>>> this is theoretical question:
>>>>>>>> Let's say i have 2 servers, intermediary server and destination openvpn
>>>>>>>> server. If i establish site-to-site VPN with openswan between those 2
>>>>>>>> servers, can i let's say use this tunnel to tunnel openvpn requests and
>>>>>>>> whole openvpn traffic to destination server (both server have public IP).
>>>>>>> It's not so theoretical. It's basically what certain governments and 
>>>>>>> militaries do (an encrypted tunnel in an encrypted tunnel using different 
>>>>>>> technologies); the same fault is not likely to be found in both.
>>>>>>> I believe OpenVPN uses UDP packets (port 1194 by default); it's ordinary IP 
>>>>>>> traffic. If you set up IPSEC with the proper LAN addresses at each end and use 
>>>>>>> the private (or internal) server address, then it should work. Don't configure 
>>>>>>> OpenVPN to use the servers' public addresses, and be sure to use different 
>>>>>>> encryption algorithms.
>>>>>> I'd also recommend using transport mode instead of tunnel mode because
>>>>>> of the lower overhead in terms of payload.
>>>>>> Simon
>>>>>> _______________________________________________
>>>>>> Users at lists.openswan.org
>>>>>> https://lists.openswan.org/mailman/listinfo/users
>>>>>> Micropayments: https://flattr.com/thing/38387/IPsec-for-Linux-made-easy
>>>>>> Building and Integrating Virtual Private Networks with Openswan:
>>>>>> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155

More information about the Users mailing list