[Openswan Users] Site-to-site + OpenVPN

Mon May 13 14:12:58 UTC 2013

Hi Damir,

On 13-05-11 08:06 AM, Damir Reic wrote:
> Hi,
> 
> i have 2 OpenVPN services on end server binded on WAN IP. Ports used are TCP
> 443 and UDP 1194. I have Iptables rules to forward requests on some other
> ports (TCP 80, UDP 443, UDP 80, UDP 4500, UDP 5632) to the one of those 2
> configured ports. That is working fine. Now i established site-to-site VPN
> over openswan in tunnel mode between 1st server and end server. 

If your OpenVPN session is already running over an IPsec tunnel I think
the rest of the discussion should be moved to the OpenVPN mailing list [1].

> What i
> don't know now is how can i configure 1st server (iptables or IPsec tunnel)
> to forward (TCP 80, UDP 443, UDP 80, UDP 4500, UDP 5632, TCP 443 and UDP
> 1194 - OpenVPN requests) openvpn traffic to end server trough the the
> tunnel? Openvpn is also configured as tunnel.

Looks like a pure OpenVPN question so their mailing list should provide
good help.

Regards,
Simon

1: https://lists.sourceforge.net/lists/listinfo/openvpn-users

> Thanks,
> Damir
> 
> 
> 
>> -----Original Message-----
>> From: users-bounces at lists.openswan.org [mailto:users-
>> bounces at lists.openswan.org] On Behalf Of Simon Deziel
>> Sent: Friday, May 10, 2013 6:30 PM
>> To: Nick Howitt
>> Cc: users at lists.openswan.org
>> Subject: Re: [Openswan Users] Site-to-site + OpenVPN
>>
>> 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-29463
>>>>>>>>>>>> 27?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=2
>>>>>> 83155
>>>>>>
>>>
>>
>> _______________________________________________
>> 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
> 