Route fout icm VPN

[Zeezicht]

Ik heb op mijn server een VPN verbinding naar een ander netwerk. Deze verbinding werkt netjes.
Het netwerk hier achter de VPN server kan dan ook mooi connecten naar het andere netwerk.
Maar ik heb op mijn -niet- VPN ip met hostnaam een webserver draaien. Als iemand van het andere netwerk dan via die hostnaam op mijn webserver wil komen lukt dat niet.
Ik denk dat het ligt aan dat zijn/haar request via het -niet- VPN ip/iface binnenkomt en dan terug wordt gestuurt via de VPN verbinding (want dat is de weg volgens de routetabel). Hoe kan ik er nu voor zorgen dat de requests gewoon via de normale iface (eth0) terug gaan?

Ik hoop dat ik een beetje duidelijk ben geweest, anders kan ik nog wel het 1 en ander toelichten,

code:

intern netwerk - server (oa webserver) - vpn verbinding - server - netwerk
                              |
                               - inet verbinding

[Zeezicht]

Heeft niemand een idee wat ik hieraan kan doen? Of is het zo onduidelijk dat niemand er wat uit op kan maken?

[Verwijderd]

het is een routerings en dns probleem, wat en waar het precies fout gaat kan je uitvinden met een traceroute

edit:

zie voor alle info die je nodig hebt :http://www.tldp.org/HOWTO/Net-HOWTO/

p.s. dit hoort meer thuis in network troubleshooting volgens mij

[ Voor 24% gewijzigd door Verwijderd op 15-08-2003 21:06 ]

[Zeezicht]

De route heen anders dan de terug route, want de mensen die naar mijn hostnaam surfen gaan naar ip-adres van mijn provider. De server stuurt dan het antwoord terug naar het adres op het andere VPN netwerk, maar door de route tabel gaat dat een andere weg.
Op zich zou dat niks uit moeten maken, maar helaas doet dat het wel.

[Verwijderd]

Over wat voor soort VPN verbinding hebben we het hier? (frees/wan (ipsec), poptop (pptp) Verder is denk ik je route tabel (route -n) wel interessant van de betreffende server en je VPN configfiles.

[Zeezicht]

Het gaat over een pptp verbinding tussen een @Home aansluiting en het campusnet (Utwente).
route tabel:

code:

130.89.1.223    @Home-gw     255.255.255.255 UGH   0      0        0 eth0
213.*.*.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.5.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
130.89.0.0      130.89.*.*     255.255.0.0     UG    0      0        0 ppp0
0.0.0.0         @Home-gw     0.0.0.0         UG    0      0        0 eth0

VPN werkt ook gewoon, dus log-files geven geen errors weer. Alleen als iemand een service (http) probeert te benaderen (gaat dan via ip van @Home) vanaf het campusnet, dan timed de verbinding uit.

[ Voor 18% gewijzigd door Zeezicht op 16-08-2003 13:19 ]

[Verwijderd]

Als iemand van het andere netwerk dan via die hostnaam op mijn webserver wil komen lukt dat niet.

Welk andere netwerk bedoel je hier precies? Het netwerk aan de andere kant van de PPTP tunnel?

Zit het -niet- VPN ip ook in de 130.89.*.* range?

[ Voor 12% gewijzigd door Verwijderd op 16-08-2003 15:47 ]

[Zeezicht]

Mensen vanaf het campusnet komen niet op mijn webserver, dus dat is idd het netwerk aan de andere kant van de PPTP tunnel. Maar de aanvraag gaat via het @Home ip (omdat de hostnaam naar dat ip verwijst) en gaat dus terug via de PPTP tunnel (door de routetabel).
Als mensen het IP van de VPN verbinding gebruiken (dus http://130.89.*.*/) dan komen ze wel op de webserver uit en werkt het allemaal goed.

Het -niet- VPN ip zit in een @Home range. En de hostnaam verwijst dus naar dit ip en niet naar een 130.89.*.* adres. Dat kan ook niet, want dat ip is dynamisch. Daarnaast mag het ook niet van Surfnet/UT.

[Verwijderd]

Ik snap nu je probleem, maar ik zie niet echt hoe je dit simpel zou kunnen oplossen. Misschien een DNS verwijzing in de DNS servers van campusnet naar het 130.98.*.* adres van je server ipv je @home adres.

Of alleen je tunnel met campusnet opzetten als je hem nodig hebt. Dan werkt het meestal wel en soms niet, dus dat wil je ook niet echt.

Of je moet met iptables aan de slag en http requests via de goede interface (eth0) terug sturen, maar ik weet niet wat hogere prioriteit heeft. Je routetabel of je regels die je in iptables maakt.

[Zeezicht]

DNS verwijzing kan ik niet maken. Een andere naam dan iets van *.utwente.nl naar een 130.89.*.* adres mag namelijk niet.

Tunnel wordt ook alleen opgezet indien nodig, maar zoals je al aangeeft werkt het dan soms wel en soms niet. Dus niet echt ideaal.

Misschien is iptables wel de oplossing, maar geen idee hoe ik dat dan kan doen (dus als iemand een idee heeft, let me know!!). Misschien kan je dan wel "langs" je routetabel komen.

[Verwijderd]

Je moet zoeken naar een methode (poortnummer packet type, ip adres) waarmee je normaal tunnelverkeer kan onderscheiden van de webserver replies. Het beste wat je dus kunt doen is een sniffer (tcpdump/ethereal) draaien op je server en beide typen verkeer genereren. Volgens mij kun je dan vervolgens in je prerouting chain je webserver replies eruit pikken en via eth0 sturen. Het moeilijke is nu alleen om te bepalen waarop je verkeer kan uitsplitsen. Als de log ook hier plaatst zal ik ook kijken of ik wat kan bedenken, want zo uit mijn hoofd heb ik niet echt een kant en klare oplossing, wel wat vage ideeen.

[Zeezicht]

Klinkt goed... nu de uitvoering nog
Poortnummer is bekend (80), ip adres waarop de aanvraag komt ook (@home), en het is TCP.
Alles wat op de @Home iface binnenkomt op poort 80, moet het ook weer via die iface (eth0) verlaten (andere services maken nu niet zo uit).

En jij hebt het over een log, maar wel log wil je zien? Dat van ethereal? Nog nooit mee gewerkt dus dan zou ik eerst moeten uitzoeken hoe dat werkt.

[Verwijderd]

Zeezicht schreef op 16 augustus 2003 @ 19:35:
Klinkt goed... nu de uitvoering nog ;-)
Poortnummer is bekend (80), ip adres waarop de aanvraag komt ook (@home), en het is TCP.
Alles wat op de @Home iface binnenkomt op poort 80, moet het ook weer via die iface (eth0) verlaten (andere services maken nu niet zo uit).

En jij hebt het over een log, maar wel log wil je zien? Dat van ethereal? Nog nooit mee gewerkt dus dan zou ik eerst moeten uitzoeken hoe dat werkt.

Ja ethereal of tcpdump. Met beide kun je al het netwerk verkeer loggen en het gebruik is niet erg moeilijk.

PPTP is trouwens meer dan alleen TCP verkeer. Het maakt ook nog gebruik van het GRE protocol.

[Zeezicht]

Ik heb net ff ethereal gedraait, maar dat is een enorme berg info. Enig idee wat ik hieruit kan gaan filteren?
Op dat moment ging er SMB verkeer overheen. Ethereal zei dat het grootste gedeelte GRE was en de rest viel in de categorie overige.

[Verwijderd]

Waar je vooral naar moet kijken is of je replies op http verkeer vanaf 130.89.*.* unencrypted voorbij ziet komen. Dus niet als onderdeel van de PPTP verbinding (GRE pakketten of TCP poort 1723). Ik neem aan dat al het verkeer wat via de tunnel naar het 130.89.*.* netwerk gaat alleen encrypted is te zien in ethereal?

Dat SMB verkeer is dat lokaal verkeer?

[Zeezicht]

Om http verkeer te simuleren gebruik ik op een 130.89.*.* server (X) het commando telnet mijn-hostnaam 80

Met ethereal zie ik het volgende dan:
Ik capture eth0 (@Home):
- er gaat verjeer van mij naar de vpn server met het GRE protocol (Encapsulated PPP).
- verkeer van de 130.89.*.* server (X) naar mijn VPN adres: SSH en WWW
blijkbaar gaat het www verkeer ook al naar mijn vpn adres en niet naar mijn @Home (begrijp alleen niet waarom).
- verkeer van mijn VPN-adres naar server (X): alleen SSH
WWW verkeer gaat dus blijkbaar niet terug

Capture ppp0
- daar gaat alleen ssh verkeer heen en weer tussen mijn VPN ip en server (X)

Het samba verkeer was tussen mijn netwerk en het 130.89.*.* netwerk.

Edit:
als ik SSH van server (X) naar mijn hostname doe, dan werkt dit ook niet.
Dus alleen verkeer vanaf mij en teru gaat goed. Andersom blijkbaar (?) niet.

[ Voor 11% gewijzigd door Zeezicht op 18-08-2003 11:26 ]

[Zeezicht]

Niemand meer een idee wat ik kan doen met eventueel prerouting?

[Verwijderd]

Je probleem is als volgt: als je vpn verbonden is en vanaf het 130.89/16 netwerk wordt er naar jouw server geconnect (via dns-naam), gebeurd dat over het internet(aanvraag komt dus binnen via @home) maar omdat de 130.89/16 range dan in je route tabel staat wordt het antwoord over je VPN terug-gestuurd. de aanvrager krijgt dus antwoord van een ip-adres waar hij geen aanvraag naar heeft verstuurd, en dus wordt dat genegeerd.

probeer eens deze:
iptables -t nat -A POSTROUTING -p tcp --sport 80 -o ppp0 -j SNAT --to [@home-ip]:80

tis een soort ip-spoofing, je stuur pakketjes via je vpn met als source adres je @home-ip
dus een firewall van campusnet zou het tegen kunnen houden...
dit werkt trouwens ook alleen als het hele 130.89/16 net zonder nat het internet opgaat

je probleem kan je ook oplossen door een dyndns(o.i.d.) naam te laten verwijzen naar je campusnet ip als je vpn-t en naar je @home ip als je dat niet doet ( zie www.dyndns.org ) en die dns-naam aan de mensen door te geven
(dit is de makkelijkste manier, geen netwerk voodoo nodig)

edit:
spellingchecker :x

[ Voor 5% gewijzigd door Verwijderd op 19-08-2003 16:12 ]

[Zeezicht]

Verwijderd schreef op 19 August 2003 @ 15:42:
Je probleem is als volgt: als je vpn verbonden is en vanaf het 130.89/16 netwerk wordt er naar jou server geconnect (via dns-naam) gebeurd dat over het internet(aanvraag komt dus binnen via @home) maar omdat de 130.89/16 range dan in je route tabel staat wordt het antwoord over je VPN terug-gestuurd. de aanvrager krijgt dus antwoord van een ip-adres waar hij geen aanvraag naar heeft verstuurd, en dus wordt dat genegeerd.

Klopt

probeer eens deze:
iptables -t nat -A POSTROUTING -p tcp --sport 80 -o ppp0 -j SNAT --to [@home-ip]:80

tis een soort ip-spoofing, je stuur pakketjes via je vpn met als source adres je @home-ip
dus een firewall van campusnet zou het tegen kunnen houden...
dit werkt trouwens ook alleen als het hele 130.89/16 net zonder nat het internet opgaat

Dit heb ik geprobeerd en werkt helaas niet. Het 130.89/16 netwerk zit direct aan internet verbonden (dwz met een router en niet achter een NAT box oid).

je probleem kan je ook oplossen door een dyndns(o.i.d.) naam te laten verwijzen naar je campusnet ip als je vpn-t en naar je @home ip als je dat niet doet ( zie www.dyndns.org ) en die dns-naam aan de mensen door te geven

Dit mag niet van de UT / Surfnet. Er mogen geen andere namen dan .utwente.nl naar 130.89/16 adressen wijzen. Anders wordt je afgesloten.

[Verwijderd]

Dit mag niet van de UT / Surfnet. Er mogen geen andere namen dan .utwente.nl naar 130.89/16 adressen wijzen. Anders wordt je afgesloten.

hmmm had het verkeerd begrepen
dacht dat je een utwente.nl naam naar je @home-ip wilde laten verwijzen

[Zeezicht]

Nee ik heb een dyns.net naam verwijzen naar mijn @Home ip. En soms de VPN verbinding met de campus aanstaan. Op dat moment is de webserver (en andere services net zo goed) niet bereikbaar voor de campus (130.89/16).

[Verwijderd]

ideetje,
als je een soort van virtuele DMZ maakt (laten we aannemen 10.0/16)
en al het verkeer dat binnenkomt op eth0 vanaf 130.89/16 daar vandaan laat lijken te komen (een source nat op inkomend verkeer dus)
met een route voor 10.0.0.0/16 die naar je eth0 wijst ben je er dan (al bijna)

iptables -t nat -A PREROUTING -p tcp -s 130.89.0.0/16 --dport 80 -i eth0 -j SNAT --to 10.0.0.0-10.0.255.255
geen idee of dat werkt,(ff geen linux-doos bij de hand), maar als je een corresponderende dnat op uitgaand verkeer moet doen ben je zuur, (zie http://www.netfilter.org/...on/HOWTO/NAT-HOWTO-6.html , onderaan de pagina)

[Zeezicht]

Verwijderd schreef op 19 August 2003 @ 16:27:
ideetje,
als je een soort van virtuele DMZ maakt (laten we aannemen 10.0/16)
en al het verkeer dat binnenkomt op eth0 vanaf 130.89/16 daar vandaan laat lijken te komen (een source nat op inkomend verkeer dus)
met een route voor 10.0.0.0/16 die naar je eth0 wijst ben je er dan (al bijna)

iptables -t nat -A PREROUTING -p tcp -s 130.89.0.0/16 --dport 80 -i eth0 -j SNAT --to 10.0.0.0-10.0.255.255
geen idee of dat werkt,(ff geen linux-doos bij de hand), maar als je een corresponderende dnat op uitgaand verkeer moet doen ben je zuur, (zie http://www.netfilter.org/...on/HOWTO/NAT-HOWTO-6.html , onderaan de pagina)

Om dat te laten werken zou ik dus een 2e ip moeten koppelen aan eth0? Kan dat zonder problemen?

Ik kom trouwens niet op de netfilter pagina, probeerde ik ook al eerder om een oplossing te vinden....

[Verwijderd]

nope. alleen een route in je route tabel met een verwijzing dat 10.0.0.0/16 te bereiken valt via je @home verbinding,
route add -net 10.0.0.0/16 gw @home-ip (o.i.d)

eigenlijk zou het 10.0.0.0/16 netwerk al over je @home verbinding moeten gaan vanwege je default route, dus misschien is dat niet eens nodig

[ Voor 31% gewijzigd door Verwijderd op 19-08-2003 16:52 . Reden: toevoeging ]

[Zeezicht]

Ik heb eth0:1 aangemaakt met als ip 10.0.0.1 (255.255.0.0)
Route wordt dan automagisch aangemaakt door Debian

code:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.0.0.0        0.0.0.0         255.255.0.0     U     0      0        0 eth0

Dan heb ik die iptables regel gebruikt die jij hierboven noemde, maar helaas krijg ik dan een foutmelding:
iptables: Invalid argument
Niet erg verhelderend ook. Nu zie ik niet helemaal wat er fout is aan die iptables regel, maar heb nog wel geprobeerd achter --to wat verschillende dingen neer te planten. Helaas allen zonder resultaat.

[Verwijderd]

was ik al bang voor, je kan geen source-nat op inkomend verkeer doen. (m'n penguin loopt weer als een kieviet dus ik heb het even gechecked )
helaas is dit een probleem waar je een by-pass voor moet verzinnen.
de dns oplossing mag niet, en de nat oplossing kan niet
(bijvoorbeeld zet op je @home webspace een link naar je campus ip-adress en je @home ipadres ,mbv een scriptje o.i.d. kan je dat dan automatisch laten updaten als het veranderd)

een html redirect zo mooier zijn...

[ Voor 6% gewijzigd door Verwijderd op 19-08-2003 17:31 . Reden: toevoeging ]

[Zeezicht]

Bedankt in elk geval voor de hulp. Jammer dat het niet 'mooi' opgelost kan worden.

[Zeezicht]

Ik heb toevallig uiteindelijk het antwoord gevonden, dus daarom nog even een post in dit oude topic.

Mijn probleem werd opgelost door:
echo "0" > /proc/sys/net/ipv4/conf/all/rp_filter

Waarschijnlijk kan je ipv all ook een specifieke interface kiezen, maar dat heb ik nog niet getest.

[Verwijderd]

Cool dat hier een oplossing voor is! Ik zit namelijk ook al een tijd met hetzelfde probleem, ook met @home en UT. Heb het nog niet getest maar zal het is proberen, de oplossing klinkt in ieder geval een stuk simpeler dan een die laatst werd aangedragen in de UT nieuwsgroepen...

Kun je uitleggen wat je oplossing precies doet in het routing proces?

[igmar]

Iets als in

code:

iptables -t mangle -A PREROUTING -i eth0 -s 130.89.0.0/16 -j MARK --set-mark 1
ip rule add fwmark 1 table utwente.out 
ip route add default via @Home-gw dev eth0 table utwente.out

mijn iptables is wat roestig, maar het zou in de goede richting moeten zijn

[Verwijderd]

Verwijderd schreef op dinsdag 06 december 2005 @ 01:05:
Cool dat hier een oplossing voor is! Ik zit namelijk ook al een tijd met hetzelfde probleem, ook met @home en UT.

By the way, dit was op een Debian server, sinds kort heb ik een andere server met Gentoo erop, VPN handleiding van UT gevolgd en nu kan ik zonder verdere aanpassingen vanaf de UT op m'n @home IP komen met VPN aan...

[Zeezicht]

Dan heb je misschien standaard je rp_filter goed staan? Moet je maar even kijken in dat bestand in /proc

Die iptables rules van igmar heb ik niet getest btw, want bij mij werkt het nu zo ook al.