Openvpn / nat routing issue

[Verwijderd]

Hi Tweakers,

Op het moment ben ik wat aan het expirimenteren met openvpn in mijn virtuele NAT omgeving op een dedicated server.

Wat ik wil is intern verkeer via openvpn naar het publieke net routeren. En dan alleen op basis van specifiek ingestelde routes. By default laat ik alles over NAT net lopen.
NAT werkt verder prima zoals het hoort (KVM/virsh/libvirt + iptables).

VPN server

config

code:

port 1295
proto udp
dev tun0
ca ca.crt
cert sphinx.crt
script-security 2
dh DiffieHellman.pem
server 10.50.1.0 255.255.255.0
client-config-dir ccd
ccd-exclusive
keepalive 3 10
comp-lzo
user vpn
group vpn
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log         /var/log/openvpn/openvpn.log
log-append  /var/log/openvpn/openvpn.log
verb 4
mute 20

Routing table,

code:

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         172.16.1.1      0.0.0.0         UG        0 0          0 eth0
10.50.1.0       10.50.1.2       255.255.255.0   UG        0 0          0 tun0
10.50.1.2       0.0.0.0         255.255.255.255 UH        0 0          0 tun0
172.16.1.0      0.0.0.0         255.255.255.0   U         0 0          0 eth0

Firewall

code:

Chain INPUT (policy ACCEPT 26938 packets, 3888K bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:44 /* SSH */
40277 2139K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22 /* SSH */
82876   12M LOG        udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:1295 LOG flags 0 level 4 prefix "INPUT VPN "

Chain FORWARD (policy ACCEPT 19719 packets, 1656K bytes)
 pkts bytes target     prot opt in     out     source               destination         
19719 1656K LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 4 prefix "FORWARD ALLOW "

VPN client

config

code:

client
dev tun
nobind
proto udp
remote 172.16.1.2 1295
resolv-retry infinite
user nobody
group nogroup
script-security 2
persist-key
persist-tun
ca   /etc/openvpn/ca.crt
cert /etc/openvpn/client.crt
key  /etc/openvpn/client.key
ns-cert-type server
tls-auth hmac.key 1 # This file is secret
cipher AES-128-CBC    # AES
comp-lzo
mute 20

firewall

code:

Chain INPUT (policy ACCEPT 48028 packets, 4561K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 124K packets, 15M bytes)
 pkts bytes target     prot opt in     out     source               destination

routing table

code:

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         172.16.1.1      0.0.0.0         UG        0 0          0 eth0
10.50.1.0       10.50.1.1       255.255.255.0   UG        0 0          0 tun0
10.50.1.1       0.0.0.0         255.255.255.255 UH        0 0          0 tun0
172.16.1.0      0.0.0.0         255.255.255.0   U         0 0          0 eth0
172.16.1.2      172.16.1.1      255.255.255.255 UGH       0 0          0 eth0
188.64.64.61    10.50.1.1       255.255.255.255 UGH       0 0          0 tun0

Outgoing connection test

Client ping test

code:

root@malak:~# ping 188.64.64.61
PING 188.64.64.61 (188.64.64.61) 56(84) bytes of data.

--- 188.64.64.61 ping statistics ---
20 packets transmitted, 0 received, 100% packet loss, time 19152ms

Server tcpdump

code:

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:43:14.695196 IP 10.50.1.4 > 188.64.64.61: ICMP echo request, id 12246, seq 15, length 64
17:43:15.703261 IP 10.50.1.4 > 188.64.64.61: ICMP echo request, id 12246, seq 16, length 64

conclusie
Verkeer komt aan bij de vpn server
Routing op de vpn server staat goed, maar word om onbekende reden niet doorgelaten
ipv4 kernel forwarding staat aan uiteraard
Waarschijnlijk zie ik een klein eenvoudig detail over het hoofd maar ben al enige dagen aan het etteren maar krijg het niet voor elkaar.

Een suggestie of hint in de goede richting zou ik ten zeerste waarderen.
Bij voorbaat dank!

[Thralas]

Verwijderd schreef op woensdag 29 januari 2014 @ 17:52:

code:

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:43:14.695196 IP 10.50.1.4 > 188.64.64.61: ICMP echo request, id 12246, seq 15, length 64
17:43:15.703261 IP 10.50.1.4 > 188.64.64.61: ICMP echo request, id 12246, seq 16, length 64

Dit gaat met het private address je eth0 uit, logisch dus dat je geen response krijgt.

Je zult moeten MASQUERADE'n of SNAT'en.

[Verwijderd]

Het werkt nu, heb nog niet veel ervaring met NAT maar weet nu weer wat meer
heb de MASQUERADE regels toegevoegd,
en een route om alles terug righting het 10.50.0/24 net naar de natbr0 interface te sturen.

[Fish]

Mja ik ben niet zo iptables gewend

maar moet protocol 51 voor ipsec niet worden doorgestuurd ?

nee dus openvpn is ssl geen ipsec

[ Voor 19% gewijzigd door Fish op 30-01-2014 23:32 ]

[Verwijderd]

@flsh Haha, ik kon de link tussen je antwoord en het onderwerp al niet vinden
Over ipsec gesproken, daar wil ik me ook is in gaan verdiepen. Qua performance is dat waarschijnlijk beter dan openvpn aangezien het crypten niet in userland hoeft te gebeuren.

Terwijl in mij ervaring (tot nu toe) vaker voor openvn dan ipsec gekozen word in enterprise omgevingen.

[ Voor 16% gewijzigd door Verwijderd op 30-01-2014 23:52 ]

[Hero of Time]

Vorige werk had ik tussen de twee locaties (kantoor en datacenter) een OpenVPN site-to-site opgezet. Nu bij m'n huidige werkgever wordt er ook OpenVPN gebruikt om naar het datacenter te kunnen (vanaf je werkplek, dus handig mobiel thuis ook toegang).

Als je met IPSec gaat werken, zal je zien dat heel vaak L2TP erbij wordt gebruikt. Hoe de performance is tussen IPSec en OVPN, zal je moeten onderzoeken. Er zullen vast wel benchmarks bestaan.

[Verwijderd]

Nog een intressante uiteenzetting voor degene die twijfelen tussen SNAT en MASQUERADE,

Both are network address translation (NAT) techniques whereby the source (LAN) address gets automagically converted to another address (typically the WAN address) by the router.

MASQUERADE converts the address to the WAN address, whatever it happens to be. In other words, at every conversion, it has to check what the WAN address is.

SNAT converts the address to a fixed address, set to the WAN address by the firewall initialization. While this would be a problem if the WAN address subsequently changes, Tomato will restart the firewall (and therby re-initialize the SNAT address) when that happens.

In theory, SNAT should be faster, since both are performing the same translation but MASQUERADE has to perform that extra lookup. In practice, we're only talking about a few machine instructions here, so the difference is not noticeable.