pptp vpn routeren door linux router

[riotrick]

Ik probeer een pptp vpn door een linux router (2.4 kernel) te routeren. De VPN server staat in ons interne netwerk. We hebben deze een geregistreerd ip adres gegeven (laten we zeggen 1.1.1.1), dus masquerading is niet nodig. Tussen de VPN server en de internetverbinding (DSL modem) staat een linux router met een geregistreerd ip adres (laten we zeggen 2.2.2.2).
Op het DSL modem is een route gemaakt die verkeer voor ip 1.1.1.1 door gateway 2.2.2.2 routeert. Op de linux machine (2.2.2.2) is een route aangemaakt voor ip 1.1.1.1 naar de interne nic (eth0) als volgt:

route add 1.1.1.1 dev eth0

Op de linux machine heb ik bovenaan mijn firewall script voor het testen het volgende gezet:

iptables -A FORWARD --destination 1.1.1.1 -j ACCEPT
iptables -A FORWARD --source 1.1.1.1 -j ACCEPT

Ok so far so good. Ik kan nu vanaf het internet pingen naar machine 1.1.1.1.

Probeer ik nu echter een pptp verbinding op te zetten dan blijft de verbinding hangen op het verifying username & password. Na een seconde of 30 komt er een timeout met server did not respond.

De pptp verbinding gebruikt tcp poort 1723 en protcol 47 (gre). Werkt het routeren van gre niet goed met het route command of moet er nog wat gebeuren?

[Verwijderd]

Als dit je hele firewall script is gaat het niet werken. Je mist je forward van het GRE protocol (47) en daar zal je ook nog een regel voor moeten aanmaken.

Wat is trouwens je default policy?

[riotrick]

Het firewall scriptje is nog wat langer. Maar ik heb geen speciale forward regel voor het GRE protocol. Moet je dat nog apart aanmaken dan als je alles met 1.1.1.1 als destination of source al ACCEPT?

De default policy van de INPUT en FORWARD chain is DROP. De default policy van de de OUTPUT chain is ACCEPT. Aan het einde van elke chain staat een log en drop regel, dus alles wat gedropped wordt komt in m'n logfiles terecht. Wanneer ik een pptp verbinding probeer te maken zie ik niks wat gedropped wordt.

[Verwijderd]

Verwijderd schreef op 22 april 2004 @ 13:56:
Als dit je hele firewall script is gaat het niet werken. Je mist je forward van het GRE protocol (47) en daar zal je ook nog een regel voor moeten aanmaken.

Wat is trouwens je default policy?

Iets beter lezen.. er is geen kwestie van NAT/PAT, het is gewoon routeren. En met de iptables regels welke hij hier post, laat die machine al het verkeer door.


Wordt er ergens in het hele verhaal stiekum toch NAT/PAT toegepast? Heeft de VPN server ook een geregistreerd adres?

//edit
Vergeet even 'forwarden', dat is een onzinantwoord hier. Forwarden doe je als je iets achter NAT wilt verstoppen, wat hier niet gebeurd (aan de hand van bovenstaande info)

[ Voor 15% gewijzigd door Verwijderd op 22-04-2004 14:00 ]

[riotrick]

Zowel de VPN server als de linux server hebben beide een geregistreerd adres. Er is voor de verbinding dus geen sprake van NAT/PAT.

Ik denk dat dit een probleem is met routeren. Wanneer je een route aanmaakt met het route commando worden dan alle protocollen, GRE in dit geval, gerouteerd? Of moet ik hiervoor iets als iproute2 gaan gebruiken?

[ Voor 47% gewijzigd door riotrick op 22-04-2004 14:04 ]

[Verwijderd]

Volgens mij zou een route hier moeten volstaan..

Eigenlijk twijfel ik of dit probleem uberhaupt wel in je routering zit, je geeft zelf immers al aan dat je firewall niets dropped volgens de logs. Wat hij niet dropped, kan hij ook niet routeren..

[riotrick]

Even ter aanvulling de VPN server heeft 2 ip adressen op de nic aan het lan. het 1e ip adres is een intern adres. Het tweede adres is een registered adres. Zou het kunnen zijn dat de VPN server (win2k server) in zijn response het interne adres als source adres gebruikt? Als dit het geval is gaat de linux machine het verkeer inderdaad masqueraden nl.

[Verwijderd]

Wat is de default route op die VPN server?

Ik denk dat je de default route op de 'interne' nic hebt staan. Verander dat is, maak een route voor je interne verkeer aan 'over' je interne nic, en zet je default route naar de linux server..

[riotrick]

De default route op de vpn staat al naar de linux server, alleen dan op het interne ip-adres van de linux server.

[Verwijderd]

Dus zowel de linux server als de VPN server hebben een intern IP?

De situatie is nu al heel anders dan je in je TS schetst, misschien in het vervolg alle info er gelijk bijzetten?

Verander die default route toch maar even naar het geregistreerde adres van de VPN server, en maak een route aan voor je 'interne' verkeer. Je zult zien dat het dan wel werkt

[riotrick]

Net getest. Heeft geen effect.

Even voor de volledigheid. De VPN server hangt in het lan. Deze heeft ip 192.168.1.3. Op dezelfde nic heb ik een 2e geregisteerde ip adres aangemaakt (wat ik 1.1.1.1 noemde).

De linux machine heeft 2 nics. Met eth0 hang hij aan het lan. eth0 heeft 3 ip adressen (ivm oude servers die niet meer bestaan): 192.168.1.6, 192.168.1.9 en 192.168.1.240.
eth1 hangt aan aparte switch waar ook het dsl modem in hangt. eth1 heeft een geregistreerd ip adres (wat ik 2.2.2.2 noemde).

Alle werkstations en servers in het lan hebben als default gateway 192.168.1.240. Deze doet NAT en verzorgt zo de internetverbinding voor alle hosts.

Nu hebben we dus op het DSL modem een route aangemaakt voor ip adres 1.1.1.1. Dit loopt nu via 2.2.2.2 (de linux machine).
Op de linux machine heb ik een route aangemaakt voor 1.1.1.1 via dev eth0 (de interface aan het lan). Tevens wordt in de firewall in de forward chain alles geaccepteerd met 1.1.1.1 als source of destination.

Hiermee is de vpn server bereikbaar vanaf het internet op ip adres 1.1.1.1 (d'r draait o.a. vnc op, dit werkt prima nu). Echter een pptp verbinding opzetten wil nog niet werken.

Ik heb op de vpn server de default gateway even aangepast naar 1.1.1.1 (geregistreerd ip van de linux bak). Dit heeft geen effect.

[Verwijderd]

kun je eens een ROUTE PRINT posten van de server en de linux machine?

Als je het interne IP even vergeet bij de VPN-server (uitschakeld), werkt het dan wel?

[riotrick]

Ik denk dat de meeste mensen hier niet echt vrolijk worden als ik het interne ip adres van vpn server af haal Dat ding doet nog wat meer dingen dan alleen voor vpn server spelen.

// edit
ik ga even de route tabellen posten. even knippen en plakken.

//edit
De linux bak

code:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
1.1.1.1         *               255.255.255.255 UH    0      0        0 eth0
1.1.1.0 (net adres)   *         255.255.255.248 U     0      0        0 eth1
192.168.5.0     192.168.1.3     255.255.255.0   UG    1      0        0 eth0
192.168.3.0     192.168.1.1     255.255.255.0   UG    1      0        0 eth0
192.168.2.0     192.168.1.1     255.255.255.0   UG    1      0        0 eth0
localnet        *               255.255.255.0   U     0      0        0 eth0
default         9.9.9.9(DSL)    0.0.0.0         UG    0      0        0 eth1

ik heb even de registered ip adressen vervangen.


en de vpn server

code:

Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0    192.168.1.240     192.168.1.3       1
          1.1.1.0  255.255.255.248          1.1.1.1     192.168.1.3       1
          1.1.1.1  255.255.255.255        127.0.0.1       127.0.0.1       1
   62.255.255.255  255.255.255.255      192.168.1.3     192.168.1.3       1
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
      192.168.1.0    255.255.255.0      192.168.1.3     192.168.1.3       1
      192.168.1.3  255.255.255.255        127.0.0.1       127.0.0.1       1
    192.168.1.255  255.255.255.255      192.168.1.3     192.168.1.3       1
      192.168.5.0    255.255.255.0      192.168.5.1     192.168.5.1       1
      192.168.5.1  255.255.255.255        127.0.0.1       127.0.0.1       1
     192.168.5.60  255.255.255.255        127.0.0.1       127.0.0.1       1
    192.168.5.255  255.255.255.255      192.168.5.1     192.168.5.1       1
        224.0.0.0        224.0.0.0      192.168.1.3     192.168.1.3       1
        224.0.0.0        224.0.0.0      192.168.5.1     192.168.5.1       1
  255.255.255.255  255.255.255.255      192.168.5.1     192.168.5.1       1
Default Gateway:     192.168.1.240
===========================================================================
Persistent Routes:
  None

//edit
De registered ip adressen zitten trouwens in een range van 8 adressen met mask 255.255.255.248

[ Voor 102% gewijzigd door riotrick op 22-04-2004 14:56 ]

[Verwijderd]

Ik denk dat je probleem zit in de 2 IP's aan dezelfde adapter in je VPN server.

Het kan handig zijn een sniffer te downloaden, en te gaan sniffen. Ik durf te wedden dat je dan ook verkeer ziet vanaf het interne adres van de VPN server naar de VPN client..

Heb je nog een NIC over?

Andere mogelijkheid: het VPN adres aan je linux-server geven, en de boel gewoon forwarden (dan dus wel)

[ Voor 31% gewijzigd door Verwijderd op 22-04-2004 15:03 ]

[riotrick]

Dat is wat ik nu net wilde voorkomen.

Ik heb al even met iptraf zitten kijken. Ik zie inderdaad vanaf de vpn client een tcp verbinding naar de vpn server op poort 1723 langskomen. En tevens zie ik GRE verbindingen van de vpn client naar de vpn server langskomen. En ICMP redirect's van 192.168.1.6 (intern ip linux bak) naar de vpn client. Geen idee of dit laatste er wat mee te maken heeft, maar het is nogal druk op het netwerk, dus het kijkt wat lastig

Responses van de vpn server zie ik niet echt langskomen. Terwijl die toch zelfs als default gw de linux bak heeft. Ik zou daar toch iets van moeten zien.

[ Voor 12% gewijzigd door riotrick op 22-04-2004 15:36 ]

[Verwijderd]

Staat die VPN server wel goed ingesteld? Als je het zonder linux-router doet, werkt hij dan wel?

Wat voor ICMP verkeer krijg je precies?

[riotrick]

Als ik vanaf een werkstation in het lan een pptp verbinding maak met het interne ip van de vpn server, dan krijg ik probleemloos verbinding. Gebruik ik het registered ip adres, dan zie ik hetzelfde effect als van buitenaf. Het icmp verkeer dat ik zie zijn ICMP redirect's van 192.168.1.6 (intern ip linux bak) naar de vpn client.

[Verwijderd]

Ik doelde meer op: mag er op het externe IP wel verbinding gemaakt worden?

Die ICMP-redirects geven wel het probleem weer..

http://support.microsoft....spx?scid=kb;en-us;q195686

Als ik dit goed lees, houdt dit in dat je linux server tegen de client zegt dat er een betere route is (rechtstreeks ipv. door de router)..

//edit

aangezien beide IP's in hetzelfde subnet zitten, is dit ook wel logisch..

[ Voor 12% gewijzigd door Verwijderd op 22-04-2004 16:11 ]

[riotrick]

Hmmm.. ik zie het ja. is daar nog iets aan te doen?

[Verwijderd]

Tsja.. beetje blind vliegen dit, maar ik blijf bij mijn gok dat het aan het feit van 2 IP's aan 1 netwerkkaart in windows ligt. Windows doet dat niet helemaal lekker.

Een 2e nic plaatsen in die VPN server lijkt mij een betere oplossing.

Wat is er overigens tegen op de methode om die linux server dat 2e geregistreerde IP te geven?

//edit
vergeet die 2e nic opmerking maar.. ik bedenk me net dat die redirect eigenlijk heel logisch is, aangezien de PC's (server + linux bak) in hetzelfde subnet zitten.

Wat gebeurd er als je op die linux bak een specifieke route alleen voor dat IP aanmaakt? (dus naast de default route)

[ Voor 32% gewijzigd door Verwijderd op 22-04-2004 16:12 ]

[gekkie]

Kijk eens op www.netfilter.org er bestaat een patch voor pptp NAT en Connection tracking. Werkt voor mij prima (niet vergeten je iptables ook opnieuw te compileren na de patch :-) )

[Verwijderd]

gekkie: hij gebruikt geen NAT..

[riotrick]

Ik zit nu even ingebeld met een modem om het nog eens van buiten af te testen. In dit geval zie ik ook GRE responses van de vpn server naar mijn vpn client met iptraf. Alleen nog steeds geen verbinding.

[Verwijderd]

Zie je dan nog steeds die redirects? En ander verkeer?

[riotrick]

Heb even goed bekeken. De vpn server gebruikt als source adres 192.168.1.3 voor al het GRE verkeer, z'n interne ip adres dus. Daar zit het probleem in. Ik ga nog even kijken of ik dat aan kan passen op de vpn server.