Mikrotik-OpenSwan IPSec tunnel erg traag

[LiquidSmoke]

Ik heb thuis een Mikrotik RB2011 staan welke een IPSec tunnel heeft naar een VPS voorzien van CentOS met OpenSwan, de tunnel is inmiddels up and running en pingen van thuis<>vps is geen probleem.

De VPN tunnel is extreem traag, en verder onbruikbaar, echter krijg ik maar niet gevonden waar het aan ligt.

De Mikrotik draait op versie 6.32.2 en is als volgt geconfigureerd:

Firewall (regels staan bovenaan):

code:

/ip firewall filter
add chain=input protocol=ipsec-ah
add chain=input protocol=ipsec-esp
add chain=input port=500 protocol=udp
add chain=input port=4500 protocol=udp
/ip firewall nat
add chain=srcnat comment="IPSec NAT" dst-address=192.168.10.1 src-address=192.168.0.0/24

IPSec:

code:

/ip ipsec proposal
add enc-algorithms=aes-256-cbc name=vps
/ip ipsec peer
add address=2.2.2.2/32 enc-algorithm=aes-256 lifetime=8h secret=preshared_key
/ip ipsec policy
add dst-address=192.168.10.1/32 proposal=vps sa-dst-address=2.2.2.2 sa-src-address=1.1.1.1 src-address=192.168.0.0/24 tunnel=yes

De VPS heeft 1 publiek IP, ik heb een virtuel adres toegevoegd:

code:

[root@vps network-scripts]# cat ifcfg-eth0:1
DEVICE=eth0:1
ONBOOT=yes
BOOTPROTO=static
NETMASK=255.255.255.255
IPADDR=192.168.10.1

De ipsec.conf ziet er als volgt uit:

code:

[root@vps network-scripts]# cat /etc/ipsec.conf
version 2.0

config setup
        nat_traversal=yes
        oe=off
        protostack=netkey
        force_keepalive=yes
        keep_alive=60
        nhelpers=0

conn thuis
        authby=secret
        auto=start
        type=tunnel
        left=2.2.2.2
        leftid=2.2.2.2
        leftsourceip=192.168.10.1
        leftsubnet=192.168.10.1/32
        right=1.1.1.1
        rightsubnet=192.168.0.0/24
        rightid=1.1.1.1
        pfs=no
        forceencaps=yes
        ike=aes256-sha1;modp1024
        ikelifetime=8h
        phase2=esp
        phase2alg=aes256-sha1

Sysctl.conf:

code:

[root@vps network-scripts]# cat /etc/sysctl.conf
# Kernel sysctl configuration file for Red Hat Linux
#
# For binary values, 0 is disabled, 1 is enabled.  See sysctl(8) and
# sysctl.conf(5) for more details.

# Controls IP packet forwarding
net.ipv4.ip_forward = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0


# Controls source route verification
net.ipv4.conf.default.rp_filter = 1

# Do not accept source routing
net.ipv4.conf.default.accept_source_route = 0

Ik heb er geen subnet achter liggen, er zijn dan ook geen masq of snat regels aan iptables toegevoegd, vanaf het thuis ip is alles toegestaan:

code:

Chain INBOUND (1 references)
target     prot opt source               destination
ACCEPT     all  -- 1.1.1.1 anywhere

Nadat de tunnel opkomt zien de route tabellen er als volgt uit:

code:

[root@vps network-scripts]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     *               255.255.255.0   U     0      0        0 eth0
2.2.2.0     *               255.255.255.0   U     0      0        0 eth0
link-local      *               255.255.0.0     U     1002   0        0 eth0
default         2.2.2.1     0.0.0.0         UG    0      0        0 eth0
[root@vps network-scripts]# ip route
192.168.0.0/24 dev eth0  scope link  src 192.168.10.1
2.2.2.0/24 dev eth0  proto kernel  scope link  src 2.2.2.2
169.254.0.0/16 dev eth0  scope link  metric 1002
default via 2.2.2.1 dev eth0

Waarbij 1.1.1.1 het thuis ip is, en 2.2.2.2 het publiek IP van de VPS.

Als de tunnel opkomt kan ik vanaf het 192.168.0/24 net probleemloos pingen naar 192.168.10.1 en vice versa.

Zodra ik echter vanaf de VPS iets over http probeer te openen van een thuis server gaat het mis, de tunnel lijkt extreem traag, bijvoorbeeld icons een paar KB laden wel, maar daar houd het wel op. Van een IP camera krijg ik wel het inlogvenster, maar daarna niet meer.

UDP werkt ook niet echt; er gaat wel wat verkeer over de lijn, maar het is zo extreem traag dat dit niet bruikbaar is.

Ook omgekeerd kan ik geen SSH sessie opzetten naar 192.168.10.1, terwijl daar wel op geluisterd wordt.

Het is net of packets >x verloren gaan, echter heb ik geen idee meer waar ik het moet zoeken.

Iemand enig idee?

[The Fatal]

iperf testje draaien?
Staat er niet een firewall aan aan de VPS kant?

[nescafe]

Ik weet niet hoe het met een ipsec-tunnel werkt, maar voor pptp voegt de MikroTik (dynamisch) wat mangle-rules toe:

code:

/ip firewall mangle
add action=change-mss chain=forward new-mss=1410 out-interface=all-ppp protocol=tcp tcp-flags=syn tcp-mss=1411-65535
add action=change-mss chain=forward in-interface=all-ppp new-mss=1410 protocol=tcp tcp-flags=syn tcp-mss=1411-65535

Je zou dit voor ipsec iets om kunnen bouwen, als volgt:

code:

/ip firewall mangle
add action=change-mss chain=forward ipsec-policy=out,ipsec new-mss=1410 protocol=tcp tcp-flags=syn tcp-mss=1411-65535
add action=change-mss chain=forward ipsec-policy=in,ipsec new-mss=1410 protocol=tcp tcp-flags=syn tcp-mss=1411-65535

Zie ook: http://wiki.bluecrow.net/...SEC.2FIPIP.2FMSS_Mangling

[LiquidSmoke]

Na wat puzzelen ben ik eruit dat het komt door het gebruik van fasttrack op de MikroTik, zodra ik deze regels uitzet is de connectie in orde...

Nu nog uitvissen hoe ik IPsec verkeer de fasttrack regels laat bypassen

[nescafe]

Ah ja, daar lijken meer mensen tegenaan gelopen te zijn.

Helaas werkt fasttrack bij mij nog niet omdat ik met een PPPoE-tunnel werk voor internet (XS4ALL).
Dus heb hier 'gelukkig' geen last van.

Zie deze post voor een workaround:

http://forum.mikrotik.com...&t=99970&p=497085#p497067

[LiquidSmoke]

Die had ik reeds gevonden en succeesvol toegepast
Alle verkeer heen en terug werkt nu zoals het hoort, volgens iperf is de bandbreedte zo'n 20Mbit richting VPS, wat exact klopt met de max upload van Ziggo.

Het gaf ook wel erg vreemde effecten op het IPsec verkeer, vandaar dat het wat lastig te pinpointen was.