[draytek] VPN probleem 2200/2600

Pagina: 1
Acties:
  • 354 views sinds 30-01-2008
  • Reageer

  • D2k
  • Registratie: Januari 2001
  • Laatst online: 09-01 11:25
Ik heb een probleem met een draytek <-> draytek VPN. Zowel op de 2200 als op de 2600 (zelfde config zo ongeveer).

Ik heb hier nu 2 2200's staan waar het volgende op van toepassing is.
head:
net. id; 192.168.0.0/24
routerip: 192.168.0.251/24
accessaccount: header/header
VPN server ip adres 172.10.10.2
type: L2TP over IPsec
key's: ABC123
ipsec sec. method: ESP 3des

branch:
net. id; 192.168.50.0/24
routerip: 192.168.50.254/24
accessaccount: branch/branch
VPN server ip adres 172.10.10.1
type: L2TP over IPsec
key's: ABC123
ipsec sec. method: ESP 3des

head staat ingesteld op dail-in, branch op dail-out.
http://www.d2k.nl/got/tnet1-dailin.pdf
http://www.d2k.nl/got/tnet2-dailout.pdf

tunnel wordt ook netjes opgebouwd
Afbeeldingslocatie: http://www.d2k.nl/got/tunnel.jpg

Routes:
Branch
code:
1
2
3
4
5
6
7
    Key: C - connected, S - static, R - RIP, * - default, ~ - private

    S~            0.0.0.0/         0.0.0.0 via 192.168.0.251, IF4
    C~       192.168.50.0/   255.255.255.0 is directly connected, IF0
    C~      192.168.0.251/ 255.255.255.255 is directly connected, IF4
    *         172.10.10.2/ 255.255.255.255 via 172.10.10.2, IF3
    C          172.10.0.0/     255.255.0.0 is directly connected, IF3

Head
code:
1
2
3
4
5
6
    Key: C - connected, S - static, R - RIP, * - default, ~ - private

    *             0.0.0.0/         0.0.0.0 via 172.10.10.1, IF3
    C~       192.168.50.0/   255.255.255.0 is directly connected, IF4
    C~        192.168.0.0/   255.255.255.0 is directly connected, IF0
    C          172.10.0.0/     255.255.0.0 is directly connected, IF3



Maar dan het belangrijkste. Data er overheen. Ik kan vanuit de branch kant (die inbelt) niet voorbij de router aan de andere kant pingen. Vice-versa geldt ook dat ik niet vanuit de head kant naar de branch kant kan pingen. waar zie ik iets over het hoofd?

Doet iets met Cloud (MS/IBM)


  • D2k
  • Registratie: Januari 2001
  • Laatst online: 09-01 11:25
*kick*
niemand een idee?

Modbreak
Loopt je uurwerk voor :? 8)7
Jij zou toch zeker moeten weten dat je je topic niet moet omhoog schoppen voor 24u voorbij zijn.

[ Voor 87% gewijzigd door Predator op 25-08-2003 21:55 ]

Doet iets met Cloud (MS/IBM)


  • D2k
  • Registratie: Januari 2001
  • Laatst online: 09-01 11:25
nog wat additionele info: firmware 2.3.6
En de enige VPN oplossing die lijkt te werken is de PPTP tunnel, maar dat is voor ons onvoldoende.

Doet iets met Cloud (MS/IBM)


  • PtrO
  • Registratie: November 2001
  • Laatst online: 20:02
D2k schreef op 25 August 2003 @ 12:17:
.....snip...
Maar dan het belangrijkste. Data er overheen. Ik kan vanuit de branch kant (die inbelt) niet voorbij de router aan de andere kant pingen. Vice-versa geldt ook dat ik niet vanuit de head kant naar de branch kant kan pingen. waar zie ik iets over het hoofd?
Vaag.

Hoe bedoel je voorbij oftewel vanaf welk IP adress probeer van/naar je te pingen. Dus wat kan je niet bereiken ?
IP in (al) jouw private-nets of die daar buiten (aangesloten via de WAN-ports) ?

Controle, je hebt dus een IPSEC connectie tussen de volgende netwerken:
192.168.50.0/24 [ 172.10.10.1/32 <-VPN-> 172.10.10.2/32] 192.168.0.0/24

Edit: Ms remote IP gateway invullen ??

[ Voor 9% gewijzigd door PtrO op 26-08-2003 16:39 . Reden: Remote Gateway ? ]

Go with the flow blocking your way and use AD for achieving results


  • D2k
  • Registratie: Januari 2001
  • Laatst online: 09-01 11:25
ik kan van de ene kant de wan ip + intern uitgedeelde ip pingen (die .202 oid). niet het netwerk erachter want vanaf de andere kant kan ik niets.

Remote gateway maakte geen verschil

Doet iets met Cloud (MS/IBM)


  • PtrO
  • Registratie: November 2001
  • Laatst online: 20:02
D2k schreef op 26 August 2003 @ 17:02:
ik kan van de ene kant de wan ip + intern uitgedeelde ip pingen (die .202 oid). niet het netwerk erachter want vanaf de andere kant kan ik niets.

Remote gateway maakte geen verschil
OK. Is me nog steeds niet duidelijk wat je wel en niet kan pingen. Die .202 in welk network zit dat. Geef 's concreet het volledige IP-nr waar je van en naar toe pingt.

Word FF een zoekplaatje.

Doe evt. ook 's een trace-route op de client om te zien waar e.e.a. instort (wel DoS/FW uitzetten op de Drayteks) en wees er wel zeker van dat het te pingen adres daadwerkelijk actief is.

Probeer is het vinkje van 'change to default' route in het VPN config scherm uit te zitten. Hierna moet je routering-query (scherm) een ander beeld geven.

Nadat de IPSEC connectie actief is, ga 's in de draytek telnet mode en probeer de IP adressen vanuit de router te pingen met: IP PING <ip.addr>
Probeer ook vanuit de 'branch' router adres 192.168.0.251 te pingen, dat moet/hoort iig beslist te lukken.

Suc6

Go with the flow blocking your way and use AD for achieving results


  • D2k
  • Registratie: Januari 2001
  • Laatst online: 09-01 11:25
ga het morgen allemaal proberen
tnx voor de tips

Doet iets met Cloud (MS/IBM)


  • PtrO
  • Registratie: November 2001
  • Laatst online: 20:02
Ik heb e.e.a. 's nagespeeld omdat het me wel prikkelde.

Snap nu waar die .202 vandaan komt. Dit is het door (remote) DHCP uitgegeven VPN-adres. Op zich voor je probleem niet interessant.

Opties ter overweging:
1) Haal aan beide kanten de 'change to default route weg'. Je hangt jezelf dan vice-versa in op de private subnets. Pingen op de Intranets en voorbij de router (dus externe IP's) naar bijv. xs4all.nl gaat dan (bij mij, althans) ook goed etc.

2.a) Nadat router 1 (automatisch/manueel) heef ingedialed naar router 2, kan je dus vanaf router1-subnet spullen pingen naar IP's van router2-subnet. Dit, zoals je zei, lukt niet de andere kant op. Dus neem stap nu stap 2.b
2.b) Logo aan op router2, ga naar VPN connecties en doe een manuele dial naar router1 dit kan (helaas) niet automatisch. In je routering za; je nu ook IF5 zien verschijnen. IF4 was daar al vanwege 2.a. Nu kan je vanaf router2.subnet ook & wel de zaken van router1.subnet pingen.
Let op, omdat je de 'change_default_route' hebt aangevinkt in beide dial-profiles, zal je never niet voorbij de router kunnen komen omdat.......je dan aan beide kanten jezelf hebt ingesloten (default routes van beide routers wijzen dan nl. naar elkaar --> cirkel).

Oorzaak van je probleem lijkt me nu enigzins helder en komt door een foute routering.

Laat de afloop nog 's FF weten.

Go with the flow blocking your way and use AD for achieving results


  • D2k
  • Registratie: Januari 2001
  • Laatst online: 09-01 11:25
1) helaas geen oplossing. Pingen naar hosts op het intranet aan de overzijde geeft geen response.
extern niet getest. we hebben het hier los gehaald van ons gewone netwerk (alle externe factoren uitsluiten ;) )
2) hmmz good one. Moet ik nog eens aandachtig bekijken. Maar als het dailen alleen manual kan is het eik ook gewoon k#t. Daar heb je toch nix aan? Dan moet je dus ervoor zorgen dat de tunnel altijd openblijft. Ik ga niet steeds aan jan en alleman uitleggen hoe er gedaild moet worden. Tnx voor je hulp tot zover.

Doet iets met Cloud (MS/IBM)


  • PtrO
  • Registratie: November 2001
  • Laatst online: 20:02
D2k schreef op 28 August 2003 @ 08:47:
1) helaas geen oplossing. Pingen naar hosts op het intranet aan de overzijde geeft geen response.
extern niet getest. we hebben het hier los gehaald van ons gewone netwerk (alle externe factoren uitsluiten ;) )
2) hmmz good one. Moet ik nog eens aandachtig bekijken. Maar als het dailen alleen manual kan is het eik ook gewoon k#t. Daar heb je toch nix aan? Dan moet je dus ervoor zorgen dat de tunnel altijd openblijft. Ik ga niet steeds aan jan en alleman uitleggen hoe er gedaild moet worden. Tnx voor je hulp tot zover.
Zal nog ergens een quirk inzitten want bij mij werkt het met jouw opzet, prima.

Ad 1: Laat 's de route-table zien van beide kanten van zowel voor en na LAN2LAN dialen. Wel FF de change-to-default-route uitzetten en om zeker te zijn dat je route-table schoon is, beide routers evt. vooraf resetten.
Niet dat 't veel uit moet maken, maar evt. kan je in de settings, RIP op TX/RX-Both aanzetten. P.s. RIP (routering informatie protocol) wordt pas echt uitgewisseld tussen routers wanneer het 'RIP Protocol' op het 'Internet Access' panel wordt aangezet.

Ad 2: Eens. De eerste dial gaat iig automatisch zodra er een client een referentie maakt naar het remote subnet. De dial-terug moet je 'helaas' forceren. Dit lijkt me overigens een ms ergens een 'foutje' in de firmware of design. Let op: de profiles moeten hiervoor wel en kan je het beste op 'Call direction Both' zetten.

Go with the flow blocking your way and use AD for achieving results


  • Thijs B
  • Registratie: Augustus 1999
  • Niet online
Moet echt redelijk simpel zijn hoor. op de diverse draytek sites staat zeer duidelijke uitleg.

Maar je vraag is onduidelijk en je laat volgens mij heeeeeeel veel info achterwegen. :(
In de topic titel heb je het over 2200/2600 even later over 2x een 2200 o-)

En is dat dan via kabel modem of adsl ??????? aan de vreemde 172.xxx.xxx.xx ip's te zien niet ?

je maakt een link tussen twee 172.10.10.x ip adressen wat is dat?? Een of ander extranet want dat is geen internet ip adres.

Hoe kom je aan die adressen ? De server/router waar die 172. adressen vandaan komen staan die wel toe dat je een vpn opzet ? Zit er ergens iets van NAT tussen ?

Snappen die 2 drayteks dat wel, 2 routers aan elkaar geknoopt die beide weer in hetzelfde net zitten ?

Heb je wel bij Remote Access controll alles aangevinkt ?

Heb je alle firewall opties even uitgezet ? (alhoewel geen invloed mag hebben)

Change tunnel to default route aanzetten dan weet je zeker dat de router ALLES naar die tunnel gaat sturen. (Maar normaal gesproken zet je alleen aan 1 kan die default route aan)

De 2 profile's in pdf formaat staan beide op dail-out ?

Je hebt in de profile's de timout op nul gezet, volgens mij moet je die op 999 ofzo zetten.. Met nul zou de link altijd openblijven maar dat werkt niet altijd.

in je profile heb je ENABLE CLID AUTHENTICATION aanstaan ? Die heb je alleen nodig als je de authenticatie laat verlopen via een ANDERE server/router !?

Je hebt RIP aanstaan, misschien dat je nog meer routers met RIP in het netwerk hebt die de boel door de warrie gooien :) ?

Probeer je de 2 vigors binnen een groot lan aan elkaar te knopen ? zo ja dan moet je zowiezo de laatste firmware gebruiken..

  • PtrO
  • Registratie: November 2001
  • Laatst online: 20:02
Thijs B schreef op 28 August 2003 @ 13:41:
........snipperdesnip...snapperdesnap.....
FF lezen en niet alles wat je stelt en noemt is zo.

Hij kan gewoon een L2TP/Ipsec VPN opzetten, dus dat werkt allemaal wel.

Wat hem niet lukt (mij e.a. wel) met die VPN actief is:
1) Vice-versa alles in zowel lokaal als ge-VPN'de remote LAN benaderen
2) Naar IP's buiten de router zelf gaan.

Kortom een routerings probleem.

[ Voor 68% gewijzigd door PtrO op 28-08-2003 14:45 ]

Go with the flow blocking your way and use AD for achieving results


  • D2k
  • Registratie: Januari 2001
  • Laatst online: 09-01 11:25
juist een routeringsprobleem
maar waarom!
daar zit hem de clou.

alles ligt los van het netwerk. Dus 1 pc aan de ene kant en 1 pc aan de andere kant
verder los van een lan.

maar ook RIP aan/uit maakt geen verschil. :{

ze hangen nu netjes via de wan poorten aan elkaar. (overigens heb ik ook 5 2600's zoals gemeld die via het internet aan elkaar hangen en waar het ook niet werkt).

2x dailout klopt niet. PDF'je net op een verkeerd moment geschoten. Dus staat wel 1 dailout en 1 dailin.

en alles wat je verder vraagt moet je ff truglezen. De relevante info staat er volgens mij.

Doet iets met Cloud (MS/IBM)


  • PtrO
  • Registratie: November 2001
  • Laatst online: 20:02
Nog 's een vraag, we gaan helemaal focussen op de routering.

Hoe staat op de routers (in menu VPN and remote Access --> PPP General setup) de startwaarde van IP-Adress assignments. Deze wordt gebruikt om een VPN verbinding te voorzien van een IP-home-adres.

Wat me nu nl. invalt is dat bij jou (kijkend naar je route-info van je 1e post), je een VPN IP-adres krijgt van de VPN-server welke gelijk is aan je routergateway-ip address (192.168.0.251/ 255.255.255.255).
Om het verhaal kort te houden: dit (.251) is d8 ik niet zoals het hoort.

Geef nog 's route-plaatje van beiden, met change_default_route uitgeschakeld en met VPN actief. FF voor de helderheid.

Go with the flow blocking your way and use AD for achieving results


  • D2k
  • Registratie: Januari 2001
  • Laatst online: 09-01 11:25
sterker nog ik heb het opgelost

in de dailout kant het "For NAT operation, treat remote sub-net as" op Public gezet. Nu kan ik iig vanaf de dailout kant overal bij

de logica ontgaat me nog, maar werken doet het

Doet iets met Cloud (MS/IBM)


  • PtrO
  • Registratie: November 2001
  • Laatst online: 20:02
Felicitados & well done.

Zou je ms nog 's je routering bij een ingebelde VPN verbinding kunnen laten zien, kan ik dan ook wat van leren ??

Breek bij mij wel een klompje :?.
Juist wanneer ik "For NAT operation, treat remote sub-net as" op Private zet heb ik het probleem wat jij eerder had wanneer je gebruikt maakt van Public. Kortom contra.

OK het enige wat ik me dan kan voorstellen is dat ik heb getest met de router WAN-adressen in het 10.x.x.x bereik (qua Internet private !!!) en daarom "For NAT operation, treat remote sub-net as" op Private moest zetten.

Jij daarentegen, met router WAN adressen op RFC/public (je gebruikt 172.10.x.x) moet daarom "For NAT operation, treat remote sub-net as" op Public zetten.


Ik had/heb zelf bijv (autodial: 10.0.0.1 naar 10.0.0.2 met Private zonder Change-Default-Gateway network):
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
Key: C - connected, S - static, R - RIP, * - default, ~ - private
*             0.0.0.0/0.0.0.0 via 10.0.0.1, IF3
C            10.0.0.0/255.255.255.0 is directly connected, IF3
C~     192.168.11.202/255.255.255.255 is directly connected, IF4
C~       192.168.11.0/255.255.255.0 is directly connected, IF0
S~        192.168.1.0/255.255.255.0 via 192.168.11.202, IF4

Key: C - connected, S - static, R - RIP, * - default, ~ - private
*             0.0.0.0/0.0.0.0 via 10.0.0.2, IF3
C            10.0.0.0/255.255.255.0 is directly connected, IF3
C~       192.168.11.1/255.255.255.255 is directly connected, IF4
S~       192.168.11.0/255.255.255.0 via 192.168.11.1, IF4
C~        192.168.1.0/255.255.255.0 is directly connected, IF0

Let vooral op de 192.168.11.202 in router 10.0.01 die ik als VPN gateway (IF4) adres voor het LAN (=IF0) vanuit de VPN-server op 10.0.0.2 heb gekregen.

Edit/aanvulling 29aug03:
Denk dat jouw/mijn verschil in gebruik zit of je al of niet gebruik maakt van de 'change to default route for this VPN tunnel' die alleen van toepassing is bij Dial_out verbindingen (achteraf: natuurlijk).

[ Voor 21% gewijzigd door PtrO op 29-08-2003 11:40 . Reden: Doorhaling & toevoeging ]

Go with the flow blocking your way and use AD for achieving results


  • Thijs B
  • Registratie: Augustus 1999
  • Niet online
172.x.x.x is toch ook private waarschijnlijk gaat daar iets mis er zitten genoeg bugs in die router..
Maar als je vpn tunnel op NAT operation public zet ?? Wat dan ? Gaat die router dan geen NAT op die vpn tunnel ofzo doen ??

Bytheway hier staat wat info over de nieuwe (beta) firmware voor de 2600 helaas nog niet in nl te krijgen...
http://www.draytek.nl/phpBB2/viewtopic.php?t=432

Wel slechte zaak dat ze in die nieuwe firmware iets van content filtering hebben gebakken... :( Laat ze eerst maar eens alle bekende bugs fixen..
Maarja dit is verder offtopic :)

[ Voor 20% gewijzigd door Thijs B op 29-08-2003 11:10 ]


  • PtrO
  • Registratie: November 2001
  • Laatst online: 20:02
Thijs B schreef op 29 August 2003 @ 11:08:
172.x.x.x is toch ook private waarschijnlijk gaat daar iets mis er zitten genoeg bugs in die router..
Maar als je vpn tunnel op NAT operation public zet ?? Wat dan ? Gaat die router dan geen NAT op die vpn tunnel ofzo doen ??

Bytheway hier staat wat info over de nieuwe (beta) firmware voor de 2600 helaas nog niet in nl te krijgen...
http://www.draytek.nl/phpBB2/viewtopic.php?t=432

Wel slechte zaak dat ze in die nieuwe firmware iets van content filtering hebben gebakken... :( Laat ze eerst maar eens alle bekende bugs fixen..
Maarja dit is verder offtopic :)
Nee, in de B-class is alleen de 172.16.x.x tot 172.31.x.x range door de IANA als private aangemerkt.

Router zelf heeft practisch geen bugs maar is bij specialistisch gebruik wat ondoorzichtig maar nog altijd 10x simpeler dan een (vage telnet commands) gedreven Cisco. Gelukkig wisselen we daarom dan ook de gebruiks-ervaringen uit.

V.w.b. de upcoming release 2.5.1 (Release Candidate, dus Beta !!) snap ik je klacht niet. Het is juist perfect dat je ook content-filtering kan doen op de router. Wordt veel om gevraagd. Zelfs nog mooier is die IPsec-agressive mode die ze gaan inbakken. Laat mij maar's weten welke ander router-merk VPN in die prijsklasse aanbiedt.

Verder ben ik benieuwd waar een lijstje is van bekende 'bugs' die niet (zouden) worden opgelost.

Ontopic:
Denk dat mijn opmerking dat de Draytek mogelijk reageerd op public/private adressen, geheel geschrapt kan worden.
In de Draytek heeft het begrip Public/Private betrekking op routering policy: Extern-WAN resp. Intern-LAN.

Go with the flow blocking your way and use AD for achieving results


  • Thijs B
  • Registratie: Augustus 1999
  • Niet online
Wat bedoelen ze met IPSEC-agressive mode ?

Er zitten wel degelijk bugs in.

Problemen die ik heb met deze routers:
De allergrootste bug op dit moment in firmware 2.3.6 (naar mijn mening) het niet werken van de handmatig ingevoerde dns servers. De router geeft altijd de dns servers van de provider door. Dat is dus zwaar k@#@$ als je zelf een eigen dns server gebruikt.
Want telewerkers die 'inbellen' krijgen ALTIJD de dns van de provider.

Bij gebruik van meerdere vpn tunnels 5 tot 6 op de 2600 slaat de router bij heel veel incoming ipsec traffic af en toe muur vast. (komt bij mij zo'n 1x per maand voor) Toen ik een oude firmware terug had gezet was dit probleem volledig opgelost. Alleen werkte daarbij de vpn links niet stabiel (moest soms handmatig droppen/connecten).

Bij gebruik van een trage adsl lijn slaat de router soms vast bij veel upload ipsec verkeer.

Bij lan-to-lan profile kan je onder het knopje MORE routes opgeven, deze handmatig ingevoerde routes vallen heel soms vanzelf weg. (komt bij mij 1x in de 2 a 3 maanden voor)

De isdn fallback werkt niet altijd goed. (vpn link komt soms niet meer up)

Wel is het mij opgevallen dat de 2200 in combinatie met een alcatel speed modem super stabiel is, deze blijft echt NOOIT hangen en heb er nooit omkijken naar. Enig nadeel is de tragere snelheid bij ipsec links..

Verder vind ik het jammer dat er geen 2300 is met een isdn portje voor fallback :( en dat je maar max 10 static routes kan opgeven..

Verder ben ik een grote fan van deze routers zeer eenvoudig in te stellen en de problemen die ik heb zullen de 'gewone' thuis gebruikers waarschijnlijk nooit tegenkomen.

Zit met smart te wachten op de vigor 3300 :9~

  • PtrO
  • Registratie: November 2001
  • Laatst online: 20:02
Thijs B schreef op 29 augustus 2003 @ 13:34:
Wat bedoelen ze met IPSEC-agressive mode ?

Er zitten wel degelijk bugs in.

Problemen die ik heb met deze routers:
De allergrootste bug op dit moment in firmware 2.3.6 (naar mijn mening) het niet werken van de handmatig ingevoerde dns servers. De router geeft altijd de dns servers van de provider door. Dat is dus zwaar k@#@$ als je zelf een eigen dns server gebruikt.
Want telewerkers die 'inbellen' krijgen ALTIJD de dns van de provider.

Bij gebruik van meerdere vpn tunnels 5 tot 6 op de 2600 slaat de router bij heel veel incoming ipsec traffic af en toe muur vast. (komt bij mij zo'n 1x per maand voor) Toen ik een oude firmware terug had gezet was dit probleem volledig opgelost. Alleen werkte daarbij de vpn links niet stabiel (moest soms handmatig droppen/connecten).

Bij gebruik van een trage adsl lijn slaat de router soms vast bij veel upload ipsec verkeer.

Bij lan-to-lan profile kan je onder het knopje MORE routes opgeven, deze handmatig ingevoerde routes vallen heel soms vanzelf weg. (komt bij mij 1x in de 2 a 3 maanden voor)

De isdn fallback werkt niet altijd goed. (vpn link komt soms niet meer up)

Wel is het mij opgevallen dat de 2200 in combinatie met een alcatel speed modem super stabiel is, deze blijft echt NOOIT hangen en heb er nooit omkijken naar. Enig nadeel is de tragere snelheid bij ipsec links..

Verder vind ik het jammer dat er geen 2300 is met een isdn portje voor fallback :( en dat je maar max 10 static routes kan opgeven..

Verder ben ik een grote fan van deze routers zeer eenvoudig in te stellen en de problemen die ik heb zullen de 'gewone' thuis gebruikers waarschijnlijk nooit tegenkomen.

Zit met smart te wachten op de vigor 3300 :9~
OK duidelijk, je problemen zijn voornamelijk VPN gerelateerd en ze zijn hierin niet de enige !!!!

Je DNS probleem vindt ik een beetje zoeken naar onmogelijkheden. Wat let je om een eigen DHCP server (Draytek heeft DHCP-Relay) te gebruiken. Kan je alles doen wat je wil. Tis nl. wat meer werk, maar kan wel.

Nu je VPN. Hou in je achterhoofd(en dat weet je best) dat je dit merk alle functies voor een habbekrats levert, geen software licentiekosten vraagt noch bijzondere (echt specialistische) kennis vraagt bij het configureren.

De VPN van de Draytek is een pure meerwaarde toevoeging en het verbaast mij dan ook niet dat bij meerdere tunnels , de processor & memory in elkaar storten. Verder moest de firmware nogal schipperen met de ruimte en worden soms dingen geschrapt (denk aan SNMP op 2200's). Wat kan helpen om je performance met VPN te verbeteren, is het geheel uitschakelen van de IP firewall en Syslogging. Scheelt nl. weer een tunneltje.

Heb of ben je werkelijk afhankelijk van alleen of voornamelijk VPN, dan neem je natuurlijk (nog ?) geen Draytek noch andere low-end apparatuur. Immers, de certificering ontbreekt en er is geen daadwerklijke software-support wat al voldoende is voor grote bedrijven om 'm niet in te zetten.

OK nu IPSec--agressive. Khou het simpel. Hiermee is er minder overhead voor de IPsec-Authenticatie en kan je de (pre-shared IKE) keys betrekken vanaf een server locatie. Voordeel, vooral met meerdere routers, is dat het IPSec-key beheer centraal geregeld kan worden etc. Nadeel is dat IPsec-A (vanwege server key retrieval) theoretisch onveiliger kan zijn.
Is verder voldoende informatie (wel wat zware kost voor de gemiddelde n00b) over te vinden.

Met de 3300 serie zal de Draytek wel het professionelere veld in gaan trekken om hun hegemonie voort te zetten.
Wat mij e.a aanspreekt, is de QoS, DMZ-zone poort, 100Mbit WAN etc en veel meer VPN (128 tunnels) capaciteit versus een 2200E (8 tunnels).
Ik neem aan dat ze het bedienings concept wel wat gelijk zullen houden. Zal dan hier niet lang aarzelen, FF w88 op stabiliteit, om een 3300X aan het parkje toe te voegen.

Go with the flow blocking your way and use AD for achieving results


  • Thijs B
  • Registratie: Augustus 1999
  • Niet online
Die nieuwe firmware 2.5 staat inmiddels op de uk site, waarom deze UK only is weet ik niet.
http://www.draytek.co.uk/support/index.html

En zo tezien kan je weer een handmatige dns server opgeven :) Ik ga 2.5 vanavond gelijk ff testen.

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
  [Changes / New functions since firmware 2.3.6UK]

    [Improvements]

    1. New Features:
     1.1 Aggressive mode for IPSec. 
     1.2 Remote dial-in (Teleworker to LAN) by using IPSec tunnel mode
     1.3 AES (Advanced Encryption Standard) encryption in IPSec
     1.4 802.1x in all of Wireless model - See FAQ on web site
     1.5 Content filtering on URLs and blocking of http file download;
           see new menu on IP Filter/Firewall menu
     1.6 VPN over Wireless - You can use IPSec encryption for WLAN
           clients, which is considered more secure than WEP
       1.7 Phase 1 Selection adavanced options for IPSec VPNs
       1.8 Second subnet IP can act as VPN server IP. 
              > vpn 2ndsubnet on    : Enable it.
              > vpn 2ndsubnet off   : Disable it. 
       1.9 support multi-pvc setting on WUI (not used in UK)
       1.10 support to use manual setting primary and secondary DNS for Vigor and dhcp 
             client IP from Vigor.
             > srv dhcp frcdnsmanl on   : Enable it.
             > srv dhcp frcdnsmanl off  : Disable it.       

    2. Improvements/Changes :
     2.1 Passthrough or Blocking a PPPoE connection which requires from internal 
         LAN host by using a check button in WUI
     2.2 Some improvements to the web user interface
     2.3 New NAT mechanism
     2.4 ARP attack defence in DoS protection
     2.5 New handling for IP conflict resolution
     2.6 MSN 6.0 passthrough
       2.7 "2st http://192.168.2.1:80" of WUI of reboot will appear only when 2nd 
             subnet was enabled.
         2.8 "For Wireless LAN" of PPPoE Pass-through will appear only when it is a
             wireless router.
         2.9 change WUI text "Remote Access User Setup (Host-to-LAN)" to 
             "Remote User Profile Setup (Teleworker)".
         2.10 Improvement wireless WEP128 unstable problem 
         2.11 Support MPPE for MS-CHAP v1 authentication
         2.12 Allow to specify MPPE encryption type on server side
         2.13 Allow to configure detailed parameters for IKE/IPSec from Web Configurator
         2.14 Allow syslog information through VPN
         2.15 DHCP relay agent for remote LAN(VPN)
         2.16 VoIP(SIP base)passthrough improvement


        [3. Fixed Issues ]

         3.1 WAN online time for DHCP client, 
             DHCP client renew time do not replace existing default gateway,
             DHCP relay agent strategy.
         3.2 PPPoE bug for change mss.
         3.3 DNS proxy.
         3.4 IKE event protect timeout situation.
         3.5 syslog through VPN.
         3.6 prevent IKE memory leakage.
         3.7 VoIP passthrough.
         3.8 ISDN backup for ppp shutdown.
         3.9 Check arp correctness.
         3.10 arp table flush.
         3.11 PPTP fragment packets.
         3.12 UPNP with MSN6.0. 
         3.13 Improved code for 128bit WEP which could cause dropouts

  • PtrO
  • Registratie: November 2001
  • Laatst online: 20:02
Thijs B schreef op 03 september 2003 @ 16:10:
Die nieuwe firmware 2.5 staat inmiddels op de uk site, waarom deze UK only is weet ik niet.
http://www.draytek.co.uk/support/index.html

En zo tezien kan je weer een handmatige dns server opgeven :) Ik ga 2.5 vanavond gelijk ff testen.
[knip code]
Let op, die 2.5 firmware op de site is alleen voor de 2600 serie.
De 2200 zal ook wel gaan komen.

Go with the flow blocking your way and use AD for achieving results


  • Thijs B
  • Registratie: Augustus 1999
  • Niet online
ff snel getest op een 2600We en zo tezien werkt alles, de handmatige dhcp dns server is weer gefixt :) daar zijn mijn dail-up users heeeeeeeeeel blij :)
De content filter is leuk maar het nut ontgaat mij een beetje je kan max op 8 key words filteren.. Het lijkt mij dat je voor dergelijke zaken toch echt een proxy server zal gebruiken.. maarja wie ben ik :)

In iedergeval brengt deze firmware aardig wat verbeteringen.
Pagina: 1