Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #5327 > unrolled thread

PPTP and NAT, IPSec and vpnc to Draytek Vigor

Back to article view | Back to comp.os.linux.misc

Contents

  PPTP and NAT, IPSec and vpnc to Draytek Vigor Chris Davies <chris-usenet@roaima.co.uk> - 2012-05-18 01:09 +0100
    Re: PPTP and NAT, IPSec and vpnc to Draytek Vigor Stan Bischof <stan@worldbadminton.com> - 2012-05-18 13:30 +0000
      Re: PPTP and NAT, IPSec and vpnc to Draytek Vigor Chris Davies <chris-usenet@roaima.co.uk> - 2012-05-19 01:07 +0100
        Re: PPTP and NAT, IPSec and vpnc to Draytek Vigor The Natural Philosopher <tnp@invalid.invalid> - 2012-05-19 01:16 +0100
    Re: PPTP and NAT, IPSec and vpnc to Draytek Vigor J G Miller <miller@yoyo.ORG> - 2012-05-19 10:58 +0000
      Re: PPTP and NAT, IPSec and vpnc to Draytek Vigor Chris Davies <chris-usenet@roaima.co.uk> - 2012-05-23 19:57 +0100
        Re: PPTP and NAT, IPSec and vpnc to Draytek Vigor J G Miller <miller@yoyo.ORG> - 2012-05-24 13:15 +0000
          Re: PPTP and NAT, IPSec and vpnc to Draytek Vigor Chris Davies <chris-usenet@roaima.co.uk> - 2012-05-24 15:40 +0100
            Re: PPTP and NAT, IPSec and vpnc to Draytek Vigor J G Miller <miller@yoyo.ORG> - 2012-05-24 15:49 +0000
              Re: PPTP and NAT, IPSec and vpnc to Draytek Vigor Chris Davies <chris-usenet@roaima.co.uk> - 2012-05-24 23:54 +0100
                Re: PPTP and NAT, IPSec and vpnc to Draytek Vigor J G Miller <miller@yoyo.ORG> - 2012-05-25 00:10 +0000
                  Re: PPTP and NAT, IPSec and vpnc to Draytek Vigor Chris Davies <chris-usenet@roaima.co.uk> - 2012-05-25 08:51 +0100

#5327 — PPTP and NAT, IPSec and vpnc to Draytek Vigor

I seem to be getting squashed between a rock and a hard place, and Google
doesn't appear to be my saviour - this time.

I need to connect from my home office to a client's site using VPN. They
have a Draytek Vigor and can offer IPSec or PPTP.

1. PPTP won't work across NAT without help. My router - a Thomson TG585
with version 7 firmware -  doesn't have a PPTP ALG to support GRE,
and it's sufficiently locked down by the ISP that I'm not sure I could
safely upgrade the firmware. (I know the my firmware's revision doesn't
have PPTP support as neither my laptop nor my smartphone can establish
a PPTP session through the router, whereas the smartphone can at least
connect via GPRS/3G. And Googling does appear to support this discovery).

2. My IPSec client of choice, vpnc, appears to make the Draytek router
complain about IKE being Aggressive and they won't play ball together.

3. OpenVPN isn't supported by the Draytek.


I have considered a number of options, but none of them really appeals
to me "as is". Maybe I've missed something, or one of you can offer me
some advice.

a. Upgrade the router firmware. This is an unknown as it's a locked-down
router provided by my ISP and (apparently) unless the newer firmware is
also appropriately locked down it won't load.

b. Replace the router firmware with DD-WRT. I don't believe DD-WRT
supports ADSL; it's just routing and wireless, isn't it?

c. Buy another router. This seems overkill for this one project.

d. Persuade the client to (allow me to) install OpenVPN on one of their
Windows servers, and bypass the Draytek's VPN capabilities entirely. I
can't see them being that impressed by this idea, really.

e. Persude the client to allow me to run an ssh tunnel from one of their
fileservers (running Linux-ish) back to my own server, over which I can
then tunnel TCP based connections. Ugly but plausible.

f. Try and climb the learning curve for OpenSWAN/FreeSWAN - and the
Draytek's IPSec configuration - before Christmas.

Thoughts, pointers, and advice gratefully received.

Cheers,
Chris

[toc] | [next] | [standalone]

#5330

Chris Davies <chris-usenet@roaima.co.uk> wrote:
> 
> f. Try and climb the learning curve for OpenSWAN/FreeSWAN - and the
> Draytek's IPSec configuration - before Christmas.
> 

How about just using Draytek's VPN client instead of trying to force-fit
a different solution?

VPN can be very picky, so using what Draytek supports is
likely to save you a lot of hassle.

Stan

[toc] | [prev] | [next] | [standalone]

#5335

Stan Bischof <stan@worldbadminton.com> wrote:
> How about just using Draytek's VPN client instead of trying to force-fit
> a different solution?

Thank you for the suggestion. Where should I find it? (I can see clients
for Windows platforms, but nothing for Linux.)

Chris

[toc] | [prev] | [next] | [standalone]

#5336

Chris Davies wrote:
> Stan Bischof <stan@worldbadminton.com> wrote:
>> How about just using Draytek's VPN client instead of trying to force-fit
>> a different solution?
> 
> Thank you for the suggestion. Where should I find it? (I can see clients
> for Windows platforms, but nothing for Linux.)
> 
> Chris
isn't the simpler solution to buy a draytek router?

I presume you can tunnel from one to another over the internet in 
relative security?


-- 
To people who know nothing, anything is possible.
To people who know too much, it is a sad fact
that they know how little is really possible -
and how hard it is to achieve it.

[toc] | [prev] | [next] | [standalone]

#5338

On Friday, May 18th, 2012, at 01:09:28h +0100, Chris Davies wrote:

> 2. My IPSec client of choice, vpnc, appears to make the Draytek router
> complain about IKE being Aggressive and they won't play ball together.

Then it is time for you to consider dropping vpnc as your client of
choice because it is a client of limited ability and *only* supports
IKE aggressive mode.

My suggestion would be to look at Strongswan for setting up
an IPsec tunnel.  If you become proficient with Strongswan
configuration,  you will be able to setup connections of all
the different flavors that may be necessary with your various
customers.

             <http://www.strongswan.ORG>

[toc] | [prev] | [next] | [standalone]

#5409

J G Miller <miller@yoyo.org> wrote:
> My suggestion would be to look at Strongswan for setting up
> an IPsec tunnel.

After banging my head against a hard place, on and off, for the last
three days I've finally got this to work while on the train home from
the customer's site.

Thank you for the push, even if I still don't really have a clue why what
I've done has worked. Big kudos to the folk who wrote the roadwarrior
examples on the Strongswan site.

Let's hope it works when I get back home and my own router plays a
part in the equation again. It may be that in the end I will need to
upgrade/replace it anyway.

Chris

[toc] | [prev] | [next] | [standalone]

#5410

On Wed, 23 May 2012 19:57:16 +0100, Chris Davies wrote:

> Thank you for the push, even if I still don't really have a clue why what
> I've done has worked.

Strongswan is a major piece of software so you will not understand it
all in one day. (I only understand a few small parts of it after
struggling with it for quite a while to understand the configuration
file parameters).

Best to look at the diagrams and to re-read the configuration files
and see if you can work out what the lines are doing, if you want to
understand why it works  ;)

> Let's hope it works when I get back home and my own router plays a
> part in the equation again.

Remember though that if you have

       pcA  ----->  router1 ======== router2  <------  pcB

then the IPSEC is a tunnel going from pcA to pcB through router1 and router2.

What you have to worry about is that router1 and router2 allow IPSEC pass
through, and that if NAT is involved you have to provide a keep alive port
pass from the router1 to pcA and router2 to pcB in the rules
on each router respectively (if I remember the setup correctly).

It is possible to get VPN/IPSec enabled routers which will create an
IPSEC tunnel from themselves to another VPN/IPSec enabled router
and this can be used to allow two subnets to communicate with each other
more easily than that pcA to pcB.

[toc] | [prev] | [next] | [standalone]

#5411

J G Miller <miller@yoyo.org> wrote:
> Strongswan is a major piece of software so you will not understand it
> all in one day. (I only understand a few small parts of it after
> struggling with it for quite a while to understand the configuration
> file parameters).

Yes, I appreciate that  :-)


> Remember though that if you have
>       pcA  ----->  router1 ======== router2  <------  pcB

> then the IPSEC is a tunnel going from pcA to pcB through router1
> and router2.

Yes, true. But fortunately my scenario is slightly simpler:
	pcA  ----->  router1  =====/=====  router2[endpoint]


What I'm finding most strange is that the private IP address for pcA on
my own LAN is being propagated into the network behind router2. So when
I connect to a device that's on router2's LAN it sees the connection
coming from my own LAN's private address space. This doesn't feel right:
I would have expected pcA to be leased an address from the address
space owned/managed by router2. (I think there are options to provide
a static IP address but not a dynamic one from a pool. I'll have to do
more reading. Later.)

Cheers,
Chris

[toc] | [prev] | [next] | [standalone]

#5413

On Thursday, May 24th, 2012, at 15:40:33h +0100, Chris Davies wrote:

> pcA  ----->  router1  =====/=====  router2[endpoint]
>
> What I'm finding most strange is that the private IP address for pcA on
> my own LAN is being propagated into the network behind router2.

You may think it strange but that is exactly what would should expect.
Remember IPSEC is like a tunnel and it starts from your PC, so the
IP address associated with that will be your local private LAN address.

> I would have expected pcA to be leased an address from the address
> space owned/managed by router2.

No, because in order to setup the IPSEC tunnel you have to start
with two IP end point addresses (as far as I am aware, corrections
invited).

This is true whether you use certificates

     <http://www.strongswan.ORG/uml/testresults/ikev2/rw-cert/>

or pre-shared keys

     <http://www.strongswan.ORG/uml/testresults/ikev2/rw-psk-ipv4/>

because your traffic is still passing through your your network device
eth0.

With openvpn it is rather different becauase traffic then goes via a
virtual device tun which does have a network address on each end different
to the local network.

If you want to start doing complicated things with using different
addresses to the local network, you can set up a GRE tunnel on top
of the IPsec tunnel  ;)  If you want to do multicasting, you actually
do need one of those plus a multicast router daemon on each end.

> I think there are options to provide a static IP address but not a
> dynamic one from a pool.

That is my [limited] understanding also, but please prove me wrong
if another configuration can make it possible ...

[toc] | [prev] | [next] | [standalone]

#5415

J G Miller <miller@yoyo.org> wrote:
> On Thursday, May 24th, 2012, at 15:40:33h +0100, Chris Davies wrote:
>> What I'm finding most strange is that the private IP address for pcA on
>> my own LAN is being propagated into the network behind router2.

> You may think it strange but that is exactly what would should expect.

So what happens when my LAN address space happens to overlap the remote
address space and my PC has an IP address that clashes with something
on the remote side? That's a recipe for disaster, and surely there is
mitigation for the resulting mess?


> Remember IPSEC is like a tunnel and it starts from your PC, so the
> IP address associated with that will be your local private LAN address.

When I used to use a VPN client in a corporate (CISCO based) setting,
my local device was assigned an address from the VPN concentrator. To
me, this makes far more sense than exposing my private LAN address to
the remote network.


> [...] your traffic is still passing through your network device eth0.

Ah. Yes. I saw that, along with the policy based iptables rule (ouch).

I must admit, though, I really don't see why eth0 (or whatever) couldn't
have been assigned a temporary IP address from the VPN endpoint. I assume
there was good reason when IPSec was designed/implemented the way it is.


> With openvpn it is rather different becauase traffic then goes via a
> virtual device tun which does have a network address on each end different
> to the local network.

OpenVPN's default is to route rather than to bridge. I've never tried
it in bridging mode so I can't comment on what happens there.


> If you want to start doing complicated things with using different
> addresses to the local network, you can set up a GRE tunnel on top
> of the IPsec tunnel  ;)

Isn't the presence of GRE the reason why PPTP doesn't work (properly)
through a NAT router? I just don't want to go there!

Cheers,
Chris

[toc] | [prev] | [next] | [standalone]

#5416

On Thursday, May 24th, 2012, at 23:54:30h +0100, Chris Davies wrote:

> So what happens when my LAN address space happens to overlap the remote
> address space and my PC has an IP address that clashes with something
> on the remote side?

The purpose of IPSEC is to allow connection between two different networks.
When you connect networks together you must have different IP addresses for
everything just as you do within a single LAN.

> That's a recipe for disaster,

Only for those who do not know what they are doing.

> and surely there is mitigation for the resulting mess?

The network administrator who assigns IP addresses and manages the connection.

> When I used to use a VPN client in a corporate (CISCO based) setting,
> my local device was assigned an address from the VPN concentrator.

If I understand correctly (from my experience with openVPN), the VPN server
assigns a subnet address for particular connections and the local and
remote and end points are then assigned IP addresses, and the IP addresses
increments by four for each new connection.

> To me, this makes far more sense than exposing my private LAN address to
> the remote network.

If you do not want to expose your private LAN to the remote network, then
you should not be making a network connection.

> I must admit, though, I really don't see why eth0 (or whatever) couldn't
> have been assigned a temporary IP address from the VPN endpoint.

If the eth0 address is changed then you will lose connection to your
local network.  If your connection to your local network goes down,
and this includes your connection to your router, you will lose your
IPSEC connection because that goes through the router.

> OpenVPN's default is to route rather than to bridge.

And my comment was with regard to routing mode rather than bridging.

openVPN is very easy to set up but the advantage of IPSEC is that
with it being kernel level rather than user level, it is much more
efficient and so significantly faster.

> Isn't the presence of GRE the reason why PPTP doesn't work (properly)
> through a NAT router?

My comment was with respect to running GRE on top of the IPSEC
connection nothing else.  Of course you can have GRE tunnels
which are not on the IPSEC connection but I do not see why that
should affect PPTP, but then I know nothing about PPTP.

A quick web search tends to indicate that in fact one runs
PPTP over GRE.

> I just don't want to go there!

I was not suggesting you should, just pointing out the further
things you can do with an IPSEC connection, or that you have to
do eg if you need to pass multicast traffic over the IPSEC connection.

[toc] | [prev] | [next] | [standalone]

#5417

J G Miller <miller@yoyo.org> wrote:
> The purpose of IPSEC is to allow connection between two different networks.

OK. I've tended to see it also a means by which a remote client device
can be added to a local network. Two different requirements with (IMO)
different needs.


>> When I used to use a VPN client in a corporate (CISCO based) setting,
>> my local device was assigned an address from the VPN concentrator.

> If I understand correctly (from my experience with openVPN), the VPN server
> assigns a subnet address for particular connections and the local and
> remote and end points are then assigned IP addresses, and the IP addresses
> increments by four for each new connection.

OpenVPN and CISCO's VPN implementation are very different beasties.


>> To me, this makes far more sense than exposing my private LAN address to
>> the remote network.

> If you do not want to expose your private LAN to the remote network, then
> you should not be making a network connection.

I didn't say anything about exposing the LAN itself. Just my device's
IP address.


>> I must admit, though, I really don't see why eth0 (or whatever) couldn't
>> have been assigned a temporary IP address from the VPN endpoint.

> If the eth0 address is changed then you will lose connection to your
> local network.

Yes, obviously. I was referring to a secondary address. Maybe I should
have made that an explicit statement.

I appreciate your insights.
Chris

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.misc

csiph-web