Onderwerp: Subnet conflict, hoe op te lossen?

Ik heb onlangs een VPS server gehuurd en daar OpenVPN op geinstalleerd.
Ik kan connectie maken met de VPN server maar het laden van websites in m'n browser werkt niet.
In de OpenVPN client log staat het volgende:

Fri Feb 26 17:51:36 2010 OpenVPN 2.1.1 i686-pc-mingw32 [SSL] [LZO2] [PKCS11] built on Dec 11 2009
Fri Feb 26 17:51:36 2010 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
Fri Feb 26 17:51:36 2010 LZO compression initialized
Fri Feb 26 17:51:36 2010 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Fri Feb 26 17:51:36 2010 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Fri Feb 26 17:51:36 2010 Local Options hash (VER=V4): '41690919'
Fri Feb 26 17:51:36 2010 Expected Remote Options hash (VER=V4): '530fdded'
Fri Feb 26 17:51:36 2010 Socket Buffers: R=[8192->8192] S=[8192->8192]
Fri Feb 26 17:51:36 2010 UDPv4 link local: [undef]
Fri Feb 26 17:51:36 2010 UDPv4 link remote: 79.xx.xx.xx:1194
Fri Feb 26 17:51:36 2010 TLS: Initial packet from 79.xx.xx.xx:1194, sid=822cd3da 6768278c
Fri Feb 26 17:51:38 2010 VERIFY OK: depth=1, /C=US/ST=CA/L=SanFrancisco/O=Fort-Funston/CN=Fort-Funston_CA/emailAddress=me@myhost.mydomain
Fri Feb 26 17:51:38 2010 VERIFY OK: nsCertType=SERVER
Fri Feb 26 17:51:38 2010 VERIFY OK: depth=0, /C=US/ST=CA/L=SanFrancisco/O=Fort-Funston/CN=server/emailAddress=me@myhost.mydomain
Fri Feb 26 17:51:42 2010 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Feb 26 17:51:42 2010 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Feb 26 17:51:42 2010 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Fri Feb 26 17:51:42 2010 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Feb 26 17:51:42 2010 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Fri Feb 26 17:51:42 2010 [server] Peer Connection Initiated with 79.99.24.116:1194
Fri Feb 26 17:51:44 2010 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Fri Feb 26 17:51:45 2010 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 208.67.222.222,dhcp-option DNS 208.67.220.220,redirect-gateway,route 10.11.12.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.11.12.6 10.11.12.5'
Fri Feb 26 17:51:45 2010 OPTIONS IMPORT: timers and/or timeouts modified
Fri Feb 26 17:51:45 2010 OPTIONS IMPORT: --ifconfig/up options modified
Fri Feb 26 17:51:45 2010 OPTIONS IMPORT: route options modified
Fri Feb 26 17:51:45 2010 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Fri Feb 26 17:51:45 2010 ROUTE default_gateway=10.0.0.1
Fri Feb 26 17:51:45 2010 TAP-WIN32 device [LAN-verbinding 2] opened: \\.\Global\{625D2025-97BF-4361-8C0E-259250C036BB}.tap
Fri Feb 26 17:51:45 2010 TAP-Win32 Driver Version 9.6
Fri Feb 26 17:51:45 2010 TAP-Win32 MTU=1500
Fri Feb 26 17:51:45 2010 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.11.12.6/255.255.255.252 on interface {625D2025-97BF-4361-8C0E-259250C036BB} [DHCP-serv: 10.11.12.5, lease-time: 31536000]
Fri Feb 26 17:51:45 2010 Successful ARP Flush on interface [26] {625D2025-97BF-4361-8C0E-259250C036BB}
Fri Feb 26 17:51:50 2010 TEST ROUTES: 2/2 succeeded len=1 ret=1 a=0 u/d=up
Fri Feb 26 17:51:50 2010 C:\WINDOWS\system32\route.exe ADD 79.99.24.116 MASK 255.255.255.255 10.0.0.1
Fri Feb 26 17:51:50 2010 C:\WINDOWS\system32\route.exe DELETE 0.0.0.0 MASK 0.0.0.0 10.0.0.1
Fri Feb 26 17:51:50 2010 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 0.0.0.0 10.11.12.5
Fri Feb 26 17:51:50 2010 WARNING: potential route subnet conflict between local LAN [10.11.12.4/255.255.255.252] and remote VPN [10.11.12.0/255.255.255.0]
Fri Feb 26 17:51:50 2010 C:\WINDOWS\system32\route.exe ADD 10.11.12.0 MASK 255.255.255.0 10.11.12.5
Fri Feb 26 17:51:51 2010 Initialization Sequence Completed
Fri Feb 26 17:52:17 2010 TCP/UDP: Closing socket
Fri Feb 26 17:52:17 2010 C:\WINDOWS\system32\route.exe DELETE 10.11.12.0 MASK 255.255.255.0 10.11.12.5
Fri Feb 26 17:52:18 2010 C:\WINDOWS\system32\route.exe DELETE 79.99.24.116 MASK 255.255.255.255 10.0.0.1
Fri Feb 26 17:52:18 2010 C:\WINDOWS\system32\route.exe DELETE 0.0.0.0 MASK 0.0.0.0 10.11.12.5
Fri Feb 26 17:52:18 2010 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 0.0.0.0 10.0.0.1
Fri Feb 26 17:52:18 2010 Closing TUN/TAP interface
Fri Feb 26 17:52:18 2010 SIGTERM[hard,] received, process exiting

Uit de log kan ik opmaken dat er een conflict is met de subnets, maar ik heb geen idee hoe ik dat op moet lossen. Is er iemand die het probleem voor mij op kan lossen tegen een kleine vergoeding? Ik heb net nl. zo spoedig mogelijk nodig.

Dat wordt veroorzaakt omdat je locale machine in een ander subnet zit dan je VPN machine.

Stel je VPN machine even op een subnet in welke je ook thuis/kantoor gebruikt of andersom. Dan zou het moeten werken.

OF je zou je redirect gateway kunnen uitschakelen. MAar dan surf je volgens mij niet via de VPN meer over het net.

je vpn server zit in 79.x.x.x, je eigen computer zit in 10.x.x.x. Zoals IC-hosting aangeeft een ander subnet.

je kan je eigen pc ook 79.x.x.x adres toe laten kennen door de vpnserver, je kan ook de vpn server in het script zichzelf een 10.x.x.x adres laten geven, dan werkt het wel. Of wil je ook kunnen internetten via je vpn?

Je point-to-point IP (tussen client en server) moet in je huidige setup een ander subnet zijn dan het subnet dat je erdoor wilt routeren, de 10.11.12.0/24. Als je de pool van adressen die voor de tunnels gebruikt wordt aanpast moet het netjes werken.

Ik heb het probleem opgelost door een tip van: http://serverfault.com/questions/669...s-any-websites

1 ensure you have pkt forwarding enabled on vpn server:

cat /proc/sys/net/ipv4/ip_forward

it should be 1, if it's not run:

echo 1 > /proc/sys/net/ipv4/ip_forward

2 for a good measure add [ not really needed since you allow traffic from/to tun0.. ]

iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

3 and finally - nat the traffic coming from vpn - that is: replace the source ip address of your connection with address of the server

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

i think the last point is the missing one...

Is het eigenlijk nodig om een firewall zoals APF te installeren op mijn VPS?
Ik heb enkel OpenVPN geinstalleerd met Centos als OS.

OpenVPN is zeer goed te beveiligen met pre shared certificaten en key-files. Zonder die bestanden accepteerd de vpn gewoon de verbinding niet. Als je verder op de server geen poorten open hebt, is het niet nodig.

Heb je wel poorten open, kan je deze misschien wijzigen? ssh op een andere poort dan 22 bijvoorbeeld. http kan je niet zomaar wijzigen, maar dan is een firewall misschien wel weer nuttig.

Ik gebruik idd pre shared certificaten en keys. SSH is op de standaard poort 22 geconfigged en verder staat er niets op, geen http, geen ftp, geen mail.

Heeft het eigenlijk wel nut om ssh op een andere poort te zetten? portscanbots vinden de ssh poort toch uiteindelijk wel.

Scanbots vinden alles. Het is ook niet onverstandig om je eigen server te scannen zodat je zeker weet dat wat er open staat ook open hoort.

Poort 22 is in 99,999% van de gevallen de SSH poort. Poort 19582 kan vanalles zijn. Vandaar dat mensen dit toch vaak veranderen.

Oorspronkelijk geplaatst door oehTie

Poort 22 is in 99,999% van de gevallen de SSH poort. Poort 19582 kan vanalles zijn. Vandaar dat mensen dit toch vaak veranderen.

Klopt, maar goede scanscript doen dan direct ook even een socket version check van wat er op draaid, dus of het nut heeft is een andere vraag.

Raar maar waar: security through obscurity werkt, maar het werkt enkel bij simpele geautomatiseerde aanvallen. Niet als je ruzie hebt met iemand specifiek. Het is geen wondermiddel, maar helpt wel tegen velen.

Wat zonder twijfel wel zinnig is:
- Enkel ssh protocol 2 toelaten
- ssh voor root uitschakelen
- limiteer de users die su/sudo kunnen gebruiken
- beperk welke ips kunnen inloggen (moet je wel zelf een vast ip hebben)
- standaard of oude user accounts die niet gebruikt worden desactiveren
- check of je wachtwoorden niet gemakkelijk te kraken zijn (met bvb. jack the ripper)

En nu terug on topic: vergeet niet dat je iptables weer leeg zijn na een reboot tenzij je dit ook even configureert: iptables-save >/etc/sysconfig/iptables of /sbin/service iptables save