Site-to-Site Tunnel mit IPSec - Durchsatz nur 4 kB/s

Eine Drosselung oder Uploadlimits hast Du nicht versehentlich für den Tunnel gesetzt?

Wüßte nicht, wo ich dies hätte einstellen müssen...

Wo müsste ich den die MTU-Werte verkleinern und auf welchen Wert?

Mir ist noch aufgefallen, dass bei IPSec - Advanced und VPN ID Ip address steht. Dort wird dann automatisch die dynamische IPv4 verwendet, dich ich vom ISP bei ausgehendem Verkehr zugewiesen bekomme. Setzte ich dort die interne IPv4 des Interfaces, kommt kein Verbindungsaufbau zustande. Die feste IPv6 nimmt er nicht an.

Bei Verwendung von Hostname klappt's auch nicht, da der Name nicht bekannt ist. Verstehe es nicht .... ;-(

Hallo DDr,

Erstmal herzlich willkommen hier in der Community !

(Sorry, my German-speaking brain isn't creating thoughts at the moment. [:(])

From both sides, please show pictures of the Edits of the IPsec Connection and Remote Gateway with 'Advanced' open.

Also, please explain how you have measured the speed.

MfG - Bob (Bitte auf Deutsch weiterhin.)

Die MTU stellst Du direkt in den Schnittstellen ein.

Den optimalen Wert kannst Du ermitteln. Gibt genug Anleitungen im Netz.

Danke für die Antworten.

WEnn ich die MTU-Size an der UTM ändere, dann gilt die anschließend für ALLES ANDERE AUCH.

Im Logfile von ipsec sehe ich immer wieder sowas:

2018:07:30-21:33:05 sg135 pluto[6284]: |    length/value: 5
2018:07:30-21:33:05 sg135 pluto[6284]: | preparse_isakmp_policy: peer requests PSK authentication
2018:07:30-21:33:05 sg135 pluto[6284]: packet from axxx:xxxx::xxxx:500: initial Main Mode message received on axxx:xxxx::xxxx:500 but no
connection has been authorized with policy=PSK
2018:07:30-21:33:05 sg135 pluto[6284]: | next event EVENT_SA_EXPIRE in 86 seconds for #12

Ich messe aktuell die Geschwindigkeit mit rsync. Dazu mounte ich auf einem linux-Rechner eine AD-Freigabe und kopiere von dort aus Files nach lokal. Ist die Datei schon vorhanden, erhalte ich direkt ein Ergebnis. Ist die Datei nicht vorhanden, dauert es ewig und im tcpdump auf dem entfernten Server bzw. auf der UTM passiert sehr viel.

21:36:59.388628 IP6 (hlim 64, next-header ESP (50) payload length: 164) bxxx:xxxx::xxxx8 > axxx:xxxx::xxxx: ESP(spi=0xf1146d68,seq=0x2c7), length 164
21:36:59.434837 IP6 (hlim 250, next-header ESP (50) payload length: 84) axxx:xxxx::xxxx > bxxx:xxxx::xxxx8: ESP(spi=0xd404e05c,seq=0x33e), length 84
21:37:04.797926 IP6 (hlim 250, next-header ESP (50) payload length: 84) axxx:xxxx::xxxx > bxxx:xxxx::xxxx8: ESP(spi=0xd404e05c,seq=0x33f), length 84
21:37:05.187060 IP6 (hlim 62, next-header UDP (17) payload length: 264) axxx:xxxx::xxxx.500 > bxxx:xxxx::xxxx8.500: [udp sum ok] isakmp 1.0 msgid 00000000 cookie 1b267b2706582b98->0000000000000000: phase 1 I ident:
    (sa: doi=ipsec situation=identity
        (p: #0 protoid=isakmp transform=1
            (t: #0 id=ike (type=lifetype value=sec)(type=lifeduration value=1e78)(type=enc value=aes)(type=hash value=md5)(type=keylen value=0100)(type=auth value=preshared)(type=group desc value=modp1536))))
    (vid: len=16)
    (vid: len=16)
    (vid: len=8)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
    (vid: len=16)
21:37:05.817556 IP6 (hlim 250, next-header ESP (50) payload length: 84) axxx:xxxx::xxxx > bxxx:xxxx::xxxx8: ESP(spi=0xd404e05c,seq=0x340), length 84
21:37:05.978413 IP6 (hlim 250, next-header ESP (50) payload length: 84) axxx:xxxx::xxxx > bxxx:xxxx::xxxx8: ESP(spi=0xd404e05c,seq=0x341), length 84
21:37:06.641638 IP6 (hlim 250, next-header ESP (50) payload length: 84) axxx:xxxx::xxxx > bxxx:xxxx::xxxx8: ESP(spi=0xd404e05c,seq=0x342), length 84
21:37:09.386195 IP6 (hlim 64, next-header ESP (50) payload length: 132) bxxx:xxxx::xxxx8 > axxx:xxxx::xxxx: ESP(spi=0xf1146d68,seq=0x2c8), length 132
21:37:09.432501 IP6 (hlim 250, next-header ESP (50) payload length: 84) axxx:xxxx::xxxx > bxxx:xxxx::xxxx8: ESP(spi=0xd404e05c,seq=0x343), length 84

...

Die letzten Zeilen wiederholen sich immer wieder ...

On both sides, select 'Support path MTU discovery'.  Any better luck with that?

MfG - Bob (Bitte auf Deutsch weiterhin.)

Habe ich auch schon probiert. Keine Verbesserung.

Ein Ping  mit großer paketgröße wird schnell beantwortet. Die mtu auf beiden utm beträgt 1500.

Setze ich auf einem Client (192.168.1.99) einen ping zu einem Server (192.168.30.254) auf der anderen Seite ab, so sieht der tcpdump auf der utm (auf der der Server ist), wie folgt aus:

Normale ping Paketgröße:

12:50:49.626845 IP srv2012 > 192.168.1.99: ICMP echo reply, id 20544, seq 1, length 64
12:50:50.627582 IP 192.168.1.99 > srv2012: ICMP echo request, id 20544, seq 2, length 64
12:50:50.627934 IP srv2012 > 192.168.1.99: ICMP echo reply, id 20544, seq 2, length 64
12:50:51.629604 IP 192.168.1.99 > srv2012: ICMP echo request, id 20544, seq 3, length 64
12:50:51.629879 IP srv2012 > 192.168.1.99: ICMP echo reply, id 20544, seq 3, length 64

ping 192.168.30.1 -s 1800

12:53:26.005123 IP srv2012 > 192.168.1.99: ICMP echo reply, id 20554, seq 4, length 1480
12:53:26.005125 IP srv2012 > 192.168.1.99: icmp
12:53:27.005833 IP 192.168.1.99 > srv2012: ICMP echo request, id 20554, seq 5, length 1480
12:53:27.005843 IP 192.168.1.99 > srv2012: icmp
12:53:27.006294 IP srv2012 > 192.168.1.99: ICMP echo reply, id 20554, seq 5, length 1480
12:53:27.006296 IP srv2012 > 192.168.1.99: icmp

You said you allowed path MTU discovery - was ICMP type 3 code 4 allowed between the two devices?

Try a ping from the internal interface of one UTM to the internal interface of the other - something like:

ping -I 192.168.1.1 192.168.30.1 -s 1500 -M do

Cheers - Bob