openvpn access server,vpn tunnel iptables

[nike]

Beste,

Op ons bedrijf hebben we een openvpn access server draaien.
Hierop connecten conel routers die een vpn tunnel opzetten naar deze access server.
Tunnel ip ligt in de 10.200.10.0/24 .
We hebben dus nu rond de 6 conel routers elk een vast ip adres.conel 1 = 10.200.10.3 en een ander 10.200.10.5.

Wat gaat er niet goed:
Het NAT gedeelte. Achter deze routers zit een server met een java aplicatie. poort forward en terug word niet goed genat. hierdoor knalt java er uit. Het login scherm word dus wel getoont wat betekent dat het wel aan komt.
Een simpel remote desktop forwarden gaat bijvoorbeeld wel.

in de conel router heb ik een startup script namelijk:

code:

#!/bin/sh

mkdir /var/openvpn/scripts
cat > /var/openvpn/scripts/openvpn.up <<EOF
#!/bin/sh

iptables -t nat -A PREROUTING -p tcp -d 10.200.0.3 --dport 3389 -j DNAT --to-destination 10.0.0.1
iptables -t nat -A PREROUTING -p tcp -d 10.200.0.3 --dport 25 -j DNAT --to-destination 10.0.0.1
iptables -t nat -A PREROUTING -p tcp -d 10.200.0.3 --dport 81 -j DNAT --to-destination 10.0.0.1:80
iptables -t nat -A PREROUTING -p tcp -d 10.200.0.3 --dport 5938 -j DNAT --to-destination 10.0.0.1
iptables -t nat -A POSTROUTING -s 10.0.0.1 -p tcp --dport 81 -j SNAT --to-source 10.200.0.3:80
iptables -t nat -A POSTROUTING -s 10.0.0.1 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

In bovenstaand voorbeeld is dus het 10.200.0.3 de vpn tunnel, dit ip is van de conel router dus. het netwerk hierachter ligt in de 10.0.0.1 range dus waar de webserver op poort 80 draaid met de java applicatie (poort 81 is in gebruik door de gui van de conel router)

De conel router draaid busybox. op het script krijg ik verder geen errors ook niet als ik ze direct in putty invul.
Je zit ook dat remote desktop aan staat naar die server en dat werkt wel gewoon.

Na dagen zoeken kom ik er gewoon niet uit. wellicht is de destination niet goed.

Ik log in op een 192.168.223.0 range en via de vpn tunnel 10.200.0.x naar de client.
In bovenstaand voorbeeld vul ik in internet explorer op de 192.168.223.x machine http://10.200.0.3:81 en dan moet kom ik op die webserver.
Zodra ik inlog op je java aplicatie en hij gaat componenten inladen gaat het fout.Iemand nog een idee wat er fout gaat?

[Verwijderd]

gaat de Java applicatie naast de eth0 ook over de tun0 van OpenVPN

(of is dit een domme vraag. want ik heb zelf ook nog niet alle kennis van OpenVPN en iptables.
maar bij programma's als samba is dit ook nodig namelijk)

[ Voor 54% gewijzigd door Verwijderd op 28-08-2016 09:01 ]

[nike]

klopt de java applet gaat via de eth0 naar de tun0 (vpn tunnel)

[_root]

Zou je eens een tekeningetje kunnen maken hoe het in elkaar zit, dan kan ik je ongetwijfeld verder helpen.
Ik zie nu even niet hoe het in elkaar zit.

[ik222]

Is je probleem niet gewoon dat die webapplicatie na inloggen nog meer dingen clientside wil inladen en dat dan dus niet over poort 81 probeert?

Maar waarom gebruik je überhaupt NAT? Ik zou zeggen namelijk dat je hier veel makkelijker gewoon kan routeren.Dan ben je namelijk gelijk ook af van het issue dat je de webapplicatie via poort 81 moet benaderen.

[nike]

plaatje toegevoegd

[_root]

ik222 schreef op zondag 28 augustus 2016 @ 11:48:
Is je probleem niet gewoon dat die webapplicatie na inloggen nog meer dingen clientside wil inladen en dat dan dus niet over poort 81 probeert?

Maar waarom gebruik je überhaupt NAT? Ik zou zeggen namelijk dat je hier veel makkelijker gewoon kan routeren.Dan ben je namelijk gelijk ook af van het issue dat je de webapplicatie via poort 81 moet benaderen.

Mee eens, het is lastig beheerbaar, herleidbaarheid is niet aanwezig.
Soms kan het een snelle oplossing zijn, maar vaak niet de mooiste en beste.

Maar zijn de openvpn verbindingen momenteel productief in gebruik? Of heb je nu de mogelijkheid om te het te verbouwen naar een gerouteerd netwerk?

[nike]

ik kan het ombouwen.
dus eigelijk is het beter om NAT niet te gebruiken en een route netwerk van te maken.
Dan valt iptables uit, maar hoe zou ik dat moeten doen dan?

[_root]

nike schreef op zondag 28 augustus 2016 @ 12:34:
ik kan het ombouwen.
dus eigelijk is het beter om NAT niet te gebruiken en een route netwerk van te maken.
Dan valt iptables uit, maar hoe zou ik dat moeten doen dan?

Je kan altijd nog iptables gebruiken voor filter toepassingen, altijd handig
Maar er mogen dan geen dezelfde netwerken zijn

begin eerst om in je config van de openvpnserver de volgende dingen erbij te zetten:
route 192.168.0.0 255.255.255.0 (adressen van de lan netwerken op de remote locaties, dus meerdere routes)
push "route 192.168.223.0 255.255.255.0" (weet de client welke netwerken achter de vpn leven)

Ik neem aan dat je ook gebruik maakt van ccd files voor de client
In deze clientfiles zetten
iroute 192.168.0.0 255.255.255.0 (netwerk dat aan de clientkant leeft, weet de server welke netwerken een specifieke client heeft, per client dus een file met de clientnetwerken)

[ Voor 8% gewijzigd door _root op 28-08-2016 13:03 ]

[ik222]

nike schreef op zondag 28 augustus 2016 @ 12:34:
ik kan het ombouwen.
dus eigelijk is het beter om NAT niet te gebruiken en een route netwerk van te maken.
Dan valt iptables uit, maar hoe zou ik dat moeten doen dan?

In de basis moet je de volgende dingen doen:

- IP forwarding aanzetten in de kernel van je OpenVPN server, zie http://www.ducea.com/2006...e-ip-forwarding-in-linux/
- OpenVPN config op de OpenVPN server uitbreiden zodat de routes naar de netwerken achter de VPN gepusht worden naar de client VPN routers.
- Zorgen dat op de centrale lokatie alle apparaten de weg naar de remote VPN subnets weten, ofwel via een route in hun default gateway of anders met lokale static routes.

[_root]

ik222 schreef op zondag 28 augustus 2016 @ 12:48:
[...]

In de basis moet je de volgende dingen doen:

- IP forwarding aanzetten in de kernel van je OpenVPN server, zie http://www.ducea.com/2006...e-ip-forwarding-in-linux/

Ook op de clients, maar neem aan dat dit al gedaan is omdat hij wel verbinding kan maken.

[ik222]

_root schreef op zondag 28 augustus 2016 @ 13:00:
[...]


Ook op de clients, maar neem aan dat dit al gedaan is omdat hij wel verbinding kan maken.

Klopt ja dat het daar ook aan moet staan, maar ook in de huidige setup met NAT op de server is dat al nodig dus ging er inderdaad vanuit dat dit al zo staat. Bovendien zijn die Conel routers echt routers, ik denk dus dat dit daar standaard aan staat.

[ Voor 11% gewijzigd door ik222 op 28-08-2016 13:04 ]

[nike]

ik denk dat ik er bijna ben....verkeer terug gaat denk ik niet goed:

code:

#!/bin/sh

mkdir /var/openvpn/scripts
cat > /var/openvpn/scripts/openvpn.up <<EOF
#!/bin/sh

iptables -A FORWARD -i eth0 -j ACCEPT
iptables -A FORWARD -o eth0 -j ACCEPT

iptables -A FORWARD -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -j ACCEPT

## verkeer naar binnen port 81 naar port 80 java server
iptables -t nat -A PREROUTING -p tcp -d 10.200.15.3 --dport 81 -j DNAT --to-destination 10.0.0.1:80

# remote desktop
iptables -t nat -A PREROUTING -p tcp -d 10.200.15.3 --dport 3389 -j DNAT --to-destination 10.0.0.1

## verkeer terug
iptables -t nat -A POSTROUTING -s 10.0.0.1 -p tcp -m tcp --dport 81 -j SNAT --to-source 10.200.15.3
iptables -t nat -A POSTROUTING -s 10.0.0.1 -p tcp --dport 3389 -j SNAT --to-source 10.200.15.3


EOF
chmod 755 /var/openvpn/scripts/openvpn.up

ik werk dus vanaf de 192.168.223.12 door de tunnel, kom uit op 10.200.15.3 en ga door naar 10.200.15.1:81

Ik twijfel welke source en destination ik moet gebruiken, heb nu zoveel combo's geprobeert maar lukt niet.
In bovenstaand voorbeeld werkt remote desktop goed.

[ik222]

Als je nu routing gebruikt heb je geen NAT meer nodig.

[nike]

Hoi ik222,

Het probleem alleen is dat klant A heeft een netwerk van 10.0.0.0/24 klant B heeft een netwerk van 172.0.0.0/24 en ga zo maar door.
Maar ik ga het nogmaals proberen of er iets van routing te maken..

[ik222]

Dat het verschillende subnets zijn per lokatie is juist goed Als subnets overlappen heb je wel een probleem en dat kan dan juist een van de redenen zijn om iets van NAT te gaan doen.