Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 12 replies
  • Subscribers 1 subscriber
  • Views 2237 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Is there a definitive SIMPLE guide to setting up a VPN

gadgetdoctor
I've set up an Astaro on a refurbished PC and it works but I can't seem to get any VPN set up such that I can connect to it passing ALL TRAFFIC through the tunnel and then get back out to the Internet.

I've managed to get PPTP to connect from my Mac and see internal machines however onward routing to the Internet has eluded me. I also tried L2TP with iPsec but that didn't seem to work though I may have given up to early.

I've followed every guide I could find here on setting NAT rules, Packet filter rules and what have you but just haven't succeeded yet.


Background:

I downloaded a copy of Firesheep the other day and, while I knew that kind of thing was possible, seeing it for myself was quite shocking. I will NEVER be using another coffee shop open wifi again.


This thread was automatically locked due to age.
  • 0
    Go to the Astaro KnowledgeBase and search on L2TP which is more secure than PPTP.  I also responded in the other thread where you posted a similar question.

    If you want to search for something in the User BB, rather than use the built-in search routine, use google and include site:astaro.org in the search string.

    Cheers - Bob
  • 0
    I'm trying to follow the steps in the document "Remote Access via L2TP over IPSec Configuring ASG and Client" but it seems to have quite a few holes.

    The following section :

    Activate the proxies (optional):
    If the remote employees shall access URL services via the remote access you may con- figure the required proxies on the Astaro Security Gateway – this would be the DNS and HTTP proxy for example.
    More detailed information on the configuration of Proxies and detailed explanations of the individual settings can be found in the Astaro Security Gateway V7 admin- istration guide.

    Is not all that revealing and neither is the admin guide. It would be nice if it explained WHY it was optional. Passages like "Define the masquerading rule (optional):" are also opaque.

    I'm not usually this slow but the ASG might just be a step too far. I was hoping it wouldn't be because I really can see the potential for this to be an amazing device.
  • 0
    Hi, if you're using the proxies, then you probably want to use them for the VPN users too.

    If you're doing Masquerading for your LAN(s), you'll need it for the VPN Pools also.

    Barry
  • 0 in reply to BarryG
    OK, I have nothing set in HTTP/S Profiles and have never touched that section.

    There is one rule in Masquerading that I believe was set during installation? Internal Network -> External (WAN)

    DNAT/SNAT has one rule that I put in which is to open up a port forward (there is a corresponding rule in Packet Filter that I also set by hand.

    Other than setting the Global page of L2TP, what else is the minimum I am supposed to set so that I can L2TP in to my network and then surf out from it again?

    All help is appreciated and if I get this working I'll try to write a single sequence of steps.
  • 0
    Something very strange happens when I try to activate L2TP.

    If I press enable on the processor ramps toward 100%, the external DSL connection dies and the machine becomes hard to use.

    I've attached the screenshot of the settings for L2TP.
  • 0 in reply to gadgetdoctor
    Could you please provide the lines from the mdw-debug log at the time that happens. What version are you using?
  • 0
    Firmware version: 8.002
    Pattern version: 20564

    I'm making the educated guess that mdw-debug is the "MiddleWare" log from the View Log Files screen:


    2010:11:02-10:06:21 ben middleware[4157]: T main::top-level:171() => starting cycle 7, caught 1 signals
    2010:11:02-10:06:22 ben middleware[4157]: T core::Config::Changed:131() => configversion=9
    2010:11:02-10:06:22 ben middleware[4157]: T core::Config::Changed:141() => nodes=0 objects=1 triggers=0
    2010:11:02-10:06:22 ben middleware[4157]: T core::Config::load:265() => modules=2,5
    2010:11:02-10:06:22 ben middleware[4157]: >=========================================================================
    2010:11:02-10:06:22 ben middleware[4157]: E Can't call method "FirstAddress" on an undefined value at /ASG/IPSec/Connection/L2tp.pm line 206.
    2010:11:02-10:06:22 ben middleware[4157]: 
    2010:11:02-10:06:22 ben middleware[4157]:  1. main::_warn:134() mdw.pl
    2010:11:02-10:06:22 ben middleware[4157]:  2. main::_die:131() mdw.pl
    2010:11:02-10:06:22 ben middleware[4157]:  3. ASG::IPSec::Connection::L2tp::GetL2tpConfig:206() /ASG/IPSec/Connection/L2tp.pm
    2010:11:02-10:06:22 ben middleware[4157]:  4. ASG::ipsec::load:113() /ASG/ipsec.pm
    2010:11:02-10:06:22 ben middleware[4157]:  5. core::Config::load:275() /core/Config.pm
    2010:11:02-10:06:22 ben middleware[4157]:  6. main::top-level:179() mdw.pl
    2010:11:02-10:06:40 ben middleware[8723]: T main::top-level:63() => MiddleWare starting
    2010:11:02-10:06:42 ben middleware[8723]: T main::top-level:171() => starting cycle 0, caught 0 signals
    2010:11:02-10:06:42 ben middleware[8723]: T core::Config::Changed:131() => configversion=0
    2010:11:02-10:06:42 ben middleware[8723]: T core::Config::Changed:231() => configversion=9
    2010:11:02-10:06:42 ben middleware[8723]: T core::Config::load:265() => modules=134,121
    2010:11:02-10:06:43 ben middleware[8723]: >=========================================================================
    2010:11:02-10:06:43 ben middleware[8723]: E /sbin/rmmod ebtables
    2010:11:02-10:06:43 ben middleware[8723]: 
    2010:11:02-10:06:43 ben middleware[8723]:  1. utils::Exec::rmmod:173() /utils/Exec.pm
    2010:11:02-10:06:43 ben middleware[8723]:  2. modules::bridging::setAll:192() /modules/bridging.pm
    2010:11:02-10:06:43 ben middleware[8723]:  3. core::Config::load:276() /core/Config.pm
    2010:11:02-10:06:43 ben middleware[8723]:  4. main::top-level:179() mdw.pl
    2010:11:02-10:06:44 ben middleware[8723]: >=========================================================================
    2010:11:02-10:06:44 ben middleware[8723]: E /sbin/rmmod bridge
    2010:11:02-10:06:44 ben middleware[8723]: 
    2010:11:02-10:06:44 ben middleware[8723]:  1. utils::Exec::rmmod:173() /utils/Exec.pm
    2010:11:02-10:06:44 ben middleware[8723]:  2. modules::bridging::setAll:197() /modules/bridging.pm
    2010:11:02-10:06:44 ben middleware[8723]:  3. core::Config::load:276() /core/Config.pm
    2010:11:02-10:06:44 ben middleware[8723]:  4. main::top-level:179() mdw.pl
    2010:11:02-10:07:03 ben middleware[8723]: >=========================================================================
    2010:11:02-10:07:03 ben middleware[8723]: E Failed: /sbin/ip -f inet route add table 252 to local default/0 dev lo
    2010:11:02-10:07:03 ben middleware[8723]: 
    2010:11:02-10:07:03 ben middleware[8723]:  1. utils::IPRoute::ip_route_cmd:765() /utils/IPRoute.pm
    2010:11:02-10:07:03 ben middleware[8723]:  2. utils::IPRoute::ip_route_add:729() /utils/IPRoute.pm
    2010:11:02-10:07:03 ben middleware[8723]:  3. ASG::Adapters::tproxy::setAll:120() /ASG/Adapters/tproxy.pm
    2010:11:02-10:07:03 ben middleware[8723]:  4. core::Config::load:276() /core/Config.pm
    2010:11:02-10:07:03 ben middleware[8723]:  5. main::top-level:179() mdw.pl
    2010:11:02-10:07:05 ben middleware[8723]: T main::top-level:202() => ending cycle 0, caught 2 signals
    2010:11:02-10:07:05 ben middleware[8723]: T main::top-level:171() => starting cycle 1, caught 2 signals
    2010:11:02-10:07:06 ben middleware[8723]: T core::Config::Changed:131() => configversion=11
    2010:11:02-10:07:06 ben middleware[8723]: T core::Config::Changed:141() => nodes=0 objects=5 triggers=0
    2010:11:02-10:07:06 ben middleware[8723]: T core::Config::load:265() => modules=28,49
    2010:11:02-10:07:08 ben middleware[8723]: T main::top-level:202() => ending cycle 1, caught 0 signals
    2010:11:02-10:07:12 ben middleware[8723]: T main::top-level:171() => starting cycle 2, caught 1 signals
    2010:11:02-10:07:13 ben middleware[8723]: T core::Config::Changed:131() => configversion=12
    2010:11:02-10:07:13 ben middleware[8723]: T core::Config::Changed:141() => nodes=0 objects=2 triggers=0
    2010:11:02-10:07:13 ben middleware[8723]: T core::Config::load:265() => modules=3,5
    2010:11:02-10:07:14 ben middleware[8723]: T main::top-level:202() => ending cycle 2, caught 1 signals
    2010:11:02-10:07:14 ben middleware[8723]: T main::top-level:171() => starting cycle 3, caught 1 signals
    2010:11:02-10:07:15 ben middleware[8723]: T core::Config::Changed:131() => configversion=13
    2010:11:02-10:07:15 ben middleware[8723]: T core::Config::Changed:141() => nodes=0 objects=1 triggers=0
    2010:11:02-10:07:15 ben middleware[8723]: T core::Config::load:265() => modules=2,5
    2010:11:02-10:07:15 ben middleware[8723]: T main::top-level:202() => ending cycle 3, caught 0 signals
  • 0 in reply to gadgetdoctor
     
    Can't call method "FirstAddress" on an undefined value at /ASG/IPSec/Connection/L2tp.pm line 206.


    Hm, there was a similar bug in mdw that is fixed in the latest 8.100 beta, but it was related to using DHCP for IP address assignment. Nothing that I see being configured on your screenshot. Have you modified the L2TP IP pool network object to only have IPv6 addresses, maybe?
  • 0 in reply to d12fk
    Hm, there was a similar bug in mdw that is fixed in the latest 8.100 beta, but it was related to using DHCP for IP address assignment. Nothing that I see being configured on your screenshot. Have you modified the L2TP IP pool network object to only have IPv6 addresses, maybe?


    I hope not! I'm clinging on to this thread by the limits of my knowledge.

    I think on my very first try to set up L2TP I selected a DHCP server on my network that hands out addresses thinking that this would then give an internal address to the computer coming in through the tunnel. Then I read a bit more and that didn't seem to be the correct way to do it. That change has therefore been backed out.

    VPN Pool (L2TP) 10.242.3.0/24 
    Last change information is not available

  • 0 in reply to gadgetdoctor

    I think on my very first try to set up L2TP I selected a DHCP server on my network that hands out addresses thinking that this would then give an internal address to the computer coming in through the tunnel.


    That broke your setup, sorry about that! =)

    You can reset your L2TP settings by running this in a root shell:

    obj=$(cc get remote_access l2tp|grep -o REF.[^\"]*); cc -ack all del_object $obj 2>/dev/null && cc set remote_access l2tp ''

    Just copy and paste the complete line and you should be able to start from the beginning then. But please don't use L2TP with DHCP befor 8.100 beta 2 is installed on your system.