[Openswan Users] Site-to-site + OpenVPN

Fri May 10 16:30:28 UTC 2013

On 13-05-10 12:11 PM, Nick Howitt wrote:
> I know nothing about transport/tunnel mode.

Transport is for host-to-host while tunnel is for net-to-net or
host-to-net. Transport mode is commonly used when doing L2TP/IPsec.

> I've only ever used tunnel
> and I understand from these exchanges that it will carry a larger
> overhead,

Yes but the overhead difference isn't that big either ;)
But overhead keeps adding up (ex: PPPoE + IPsec + OpenVPN) and that's
why I mentioned transport mode in the first place.

> but someone further back said OpenVPN would have the WAN IP in
> the header which would cause problems.

No problem there and in fact it's a requirement to get transport mode
security.

> In my scenario, OpenVPN would
> never know anything about either WAN IP so it could bypass the issue
> (and allow you to use transport mode?).

OK I'll try to clarify a bit:

1) there is no issue to bypass ;)
2) if you want transport mode, OpenVPN has to use the WAN IP
3) if you don't want OpenVPN to use the WAN IP then you cannot use
transport mode and have to use tunnel mode instead

HTH,
Simon

> Anyway it is over to you experts. I can't really contribute further.
> 
> Nick
> 
> On 10/05/2013 17:02, Simon Deziel wrote:
>> On 13-05-10 11:47 AM, Nick Howitt wrote:
>>> Somewhere back in this thread I think a possibly incorrect statement was
>>> made about OpenVPN. AFAIK, OpenVPN normally binds to all the interfaces
>>> it can including the LAN interfaces and can be used for encrypting all
>>> LAN traffic. This can be especially useful if you want to secure WiFi.
>>> Anyway, following on from this thought, can you create an ipsec tunnel
>>> in tunnel mode with leftsubnet=LAN_IP/32 and
>>> rightsubnet=remote_LAN_IP/32? Also set left/rightsourceip. Then in
>>> OpenVPN, at the end initiating the connection you use "remote =
>>> far_end_LAN_IP port". You then use the OpenVPN configuration to do the
>>> subnet to subnet routing.
>> This would work indeed but has a slightly larger overhead when compared
>> to OpenVPN on top of IPsec in transport mode.
>>
>> Since the OpenVPN communication is between the 2 hosts doing IPsec,
>> there is no point to use tunnel mode as transport was designed exactly
>> for that use case.
>>
>>> I think this will allow all subnet-subnet traffic through the OpenVPN
>>> tunnel which is inside an IPsec tunnel.
>> Yes but whatever is the IPsec connection type (tunnel/transport) doesn't
>> matter as OpenVPN is just an UDP stream to protect.
>>
>> IMO, using transport mode is a sensible choice especially when doing
>> OpenVPN on top of IPsec as the MTU keeps shrinking when you add layers.
>>
>> Simon
>>
>>> Nick
>>>
>>> On 09/05/2013 19:46, Simon Deziel wrote:
>>>> Say the left side has 1.2.3.4 and the right has 5.6.7.8 and they are
>>>> connected by a transport mode IPsec connection.
>>>>
>>>> Once this IPsec connection is up, OpenVPN will connect from
>>>> 1.2.3.4:1399 -> 5.6.7.8:1399 and this will be covered by IPsec.
>>>>
>>>> The fact that OpenVPN will later assign a client IP (ex 10.1.2.3) to
>>>> its
>>>> tun interface has really nothing to do with IPsec. As far as IPsec is
>>>> concerned it is only carrying UDP traffic between 1.2.3.4 and 5.6.7.8.
>>>>
>>>> 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 10.1.2.3 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 10.1.2.3. 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
>>>>>>>> AFAIK, OpenVPN normally binds to all the interfaces it can
>>>>>>>> including the LAN in
>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>> _______________________________________________
>>>> 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
>>>>
> 