[Openswan Users] Site-to-site + OpenVPN

Sat May 11 12:06:34 UTC 2013

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.  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.

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