[OpenVPN] Internet & sites

[ZeroXT]

Beste mensen,

Ik heb OpenVPN geinstalleerd op een CentOS systeem. Een client kan verbinding maken en wanneer deze zijn wan IP-adres bekijkt, ziet diegene het IP-adres van de server. Internet is ook aanwezig, sites zoals tweakers.net laden prima.

Echter heeft het systeem ook een webserver geinstalleerd die luistert op zowel poort 80 als 443. Deze websites zijn echter niet bereikbaar voor de client.

Het systeem maakt gebruik van iptables als firewall. Wanneer ik deze uitzet werkt het systeem naar behoren alleen willen we dit natuurlijk niet.

Onderstaande code staat in iptables:

code:

-A PREROUTING -p tcp -d xxx.xxx.xxx.xxx --dport 80 -j DNAT --to xxx.xxx.xxx.xxx:80
-A PREROUTING -p tcp -d xxx.xxx.xxx.xxx --dport 443 -j DNAT --to xxx.xxx.xxx.xxx:443
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j SNAT --to-source xxx.xxx.xxx.xxx

Heeft iemand enig idee waar dit aan kan liggen?

[Thralas]

Je vertelt niet naar welk IP je prbeert te verbinden, de RFC1918 range of het externe IP.

Daarnaast neem ik aan dat 'xxx.xxx.xxx.xxx' niet in alle gevallen hetzelfde IP betreft? Is dat een extern routable IP?? Onhandig gemaskeerd..

Heb je al met tcpdump gekeken waar het misgaat?

[ZeroXT]

xxx.xxx.xxx.xxx is het wan IP-adres van de server.

Het IP-adres van de client wordt gebruikt om de data op te halen. Wanneer de client een website opvraagd die door onze server wordt geserveerd, zal de server de aanvraag doen naar zichzelf met het IP-adres van de client waardoor deze niet bereikbaar is omdat alles dicht zit middels iptables (vandaar de OpenVPN configuratie).

[Thralas]

ZeroXT schreef op maandag 04 mei 2015 @ 11:52:
xxx.xxx.xxx.xxx is het wan IP-adres van de server.

Oke.

Het IP-adres van de client wordt gebruikt om de data op te halen.

Ik snap niet wat je hier bedoelt, noch met 'het IP-adres', noch met 'de data' (welke data? waarvandaan?)

Wanneer de client een website opvraagd die door onze server wordt geserveerd, zal de server de aanvraag doen naar zichzelf met het IP-adres van de client waardoor deze niet bereikbaar is omdat alles dicht zit middels iptables (vandaar de OpenVPN configuratie).

Wat concreter; je probleem is dus dat je VPN client de services op de server op het externe IP niet kan bereiken?

Is dat IP niet hetzelfde adres waarop OpenVPN luistert? Dan is het nogal logisch dat het niet werkt; verkeer naar dat IP gaat niet door de tunnel (zonder ranzige hacks clientside).

De netste oplossing lijkt me om de services op 10.8.0.X beschikbaar te maken voor de client, en ze ook dusdanig te benaderen.

Als dat niet is wat je zoekt is het handig om TS nog even aan te scherpen met een overzicht van wat waar luistert en hoe het verkeer volgens jou zou moeten lopen, het is me allemaal niet heel erg duidelijk

En ik zie het nut van je DNAT rules niet. Je rewrite xxx.xxx.xxx.xxx:yyyy naar xxx.xxx.xxx.xxx:yyy?

[ZeroXT]

- Client (100.100.100.100 (fictief IP-adres)) verbindt met de server via OpenVPN (200.200.200.200).
- Client opent website tweakers.net
- Data wordt verstuurd naar de server.
- Server opent website tweakers.net onder IP-adres 100.100.100.100
- Server stuurt response terug naar Client.


In dit plaatje moet het Client IP-adres niet 100.100.100.100 zijn maar 200.200.200.200 en dat is momenteel niet het geval.

De server heeft nagenoeg alles dicht in de ip-tables. Wanneer door de client een website geopend wordt die gehost wordt door de Server, zal de Server de aanvraag naar zichzelf indienen onder de Client IP-adres die geen toegang heeft waardoor de webpagina niet geladen kan worden.

De verbinding gaat namelijk eerst naar buiten, vervolgens weer naar binnen. Deze wordt door de firewall tegengehouden omdat het IP-adres niet is toegevoegd in de iptables als zijnde veilige IP-adres.

[Orion84]

Thralas schreef op maandag 04 mei 2015 @ 12:18:
Wat concreter; je probleem is dus dat je VPN client de services op de server op het externe IP niet kan bereiken?

Is dat IP niet hetzelfde adres waarop OpenVPN luistert? Dan is het nogal logisch dat het niet werkt; verkeer naar dat IP gaat niet door de tunnel (zonder ranzige hacks clientside).

De netste oplossing lijkt me om de services op 10.8.0.X beschikbaar te maken voor de client, en ze ook dusdanig te benaderen.

Check inderdaad eens met een packetsniffer op de externe interface of het verkeer naar de webserver niet gewoon compleet buiten VPN om loopt.

En de webserver benaderen op zijn LAN adres lijkt mij inderdaad dan ook de meest logische aanpak.