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

Evtl mag dein ISP nicht den ganzen Overhead und du könntest mal gucken was passiert wenn du die MTU für den tunnel was nach unten drehst?

Oder liegt es vielleicht sogar am Routing?

ICh baue die IPSec-Verbindung zwischen den beiden UTMs über eine feste IPv6 auf.

Anschließend möchte ich mit den Netzen dahinter per IPv4 kommunizieren.

Anbei nochmal das Logfile. Wenn ich es richtig verstehe, wird der Tunnel aufgebaut. Ein ping funktioniert wunderbar. Nur ein Zugriff auf Daten will nicht wirklich ...

2018:07:28-13:48:18 sg115 ipsec_starter[24137]: Starting strongSwan 4.4.1git20100610 IPsec [starter]...
2018:07:28-13:48:18 sg115 pluto[24154]: Starting IKEv1 pluto daemon (strongSwan 4.4.1git20100610) THREADS VENDORID CISCO_QUIRKS
2018:07:28-13:48:18 sg115 ipsec_starter[24147]: pluto (24154) started after 20 ms
2018:07:28-13:48:19 sg115 pluto[24154]: loaded plugins: curl ldap aes des blowfish serpent twofish sha1 sha2 md5 random x509 pubkey pkcs1 pgp dnskey pem sqlite hmac gmp xauth attr attr-sql resolve
2018:07:28-13:48:19 sg115 pluto[24154]:   including NAT-Traversal patch (Version 0.6c)
2018:07:28-13:48:19 sg115 pluto[24154]: Using Linux 2.6 IPsec interface code
2018:07:28-13:48:19 sg115 pluto[24154]: loading ca certificates from '/etc/ipsec.d/cacerts'
2018:07:28-13:48:19 sg115 pluto[24154]:   loaded ca certificate from '/etc/ipsec.d/cacerts/REF_CaVerVpnSigniCaSun2.pem'
2018:07:28-13:48:19 sg115 pluto[24154]:   loaded ca certificate from '/etc/ipsec.d/cacerts/REF_CaVerVpnSigniCaSun.pem'
2018:07:28-13:48:19 sg115 pluto[24154]:   loaded ca certificate from '/etc/ipsec.d/cacerts/REF_CaSigVpnSigniCa.pem'
2018:07:28-13:48:19 sg115 pluto[24154]: loading aa certificates from '/etc/ipsec.d/aacerts'
2018:07:28-13:48:19 sg115 pluto[24154]: loading ocsp certificates from '/etc/ipsec.d/ocspcerts'
2018:07:28-13:48:19 sg115 pluto[24154]: Changing to directory '/etc/ipsec.d/crls'
2018:07:28-13:48:19 sg115 pluto[24154]: loading attribute certificates from '/etc/ipsec.d/acerts'
2018:07:28-13:48:19 sg115 pluto[24154]: adding interface tun0/tun0 10.10.30.1:500
2018:07:28-13:48:19 sg115 pluto[24154]: adding interface tun0/tun0 10.10.30.1:4500
2018:07:28-13:48:19 sg115 pluto[24154]: adding interface eth2/eth2 192.168.10.1:500
2018:07:28-13:48:19 sg115 pluto[24154]: adding interface eth2/eth2 192.168.10.1:4500
2018:07:28-13:48:19 sg115 pluto[24154]: adding interface eth1/eth1 192.168.3.1:500
2018:07:28-13:48:19 sg115 pluto[24154]: adding interface eth1/eth1 192.168.3.1:4500
2018:07:28-13:48:19 sg115 pluto[24154]: adding interface eth0/eth0 192.168.1.1:500
2018:07:28-13:48:19 sg115 pluto[24154]: adding interface eth0/eth0 192.168.1.1:4500
2018:07:28-13:48:19 sg115 pluto[24154]: adding interface lo/lo 127.0.0.1:500
2018:07:28-13:48:19 sg115 pluto[24154]: adding interface lo/lo 127.0.0.1:4500
2018:07:28-13:48:19 sg115 pluto[24154]: adding interface eth1/eth1 2yyyy:yyyy::yyyy:500
2018:07:28-13:48:19 sg115 pluto[24154]: adding interface lo/lo ::1:500
2018:07:28-13:48:19 sg115 pluto[24154]: loading secrets from "/etc/ipsec.secrets"
2018:07:28-13:48:19 sg115 pluto[24154]:   loaded PSK secret for 2yyyy:yyyy::yyyy 2xxx:xxxx::xxxx
2018:07:28-13:48:19 sg115 pluto[24154]: listening for IKE messages
2018:07:28-13:48:19 sg115 pluto[24154]: added connection description "IpSitA2B0"
2018:07:28-13:48:19 sg115 pluto[24154]: "IpSitA2B0" #1: initiating Main Mode
2018:07:28-13:48:19 sg115 pluto[24154]: added connection description "IpSitA2B1"
2018:07:28-13:48:19 sg115 pluto[24154]: "IpSitA2B0" #1: received Vendor ID payload [strongSwan]
2018:07:28-13:48:19 sg115 pluto[24154]: "IpSitA2B0" #1: ignoring Vendor ID payload [Cisco-Unity]
2018:07:28-13:48:19 sg115 pluto[24154]: "IpSitA2B0" #1: received Vendor ID payload [XAUTH]
2018:07:28-13:48:19 sg115 pluto[24154]: "IpSitA2B0" #1: received Vendor ID payload [Dead Peer Detection]
2018:07:28-13:48:19 sg115 pluto[24154]: "IpSitA2B0" #1: received Vendor ID payload [RFC 3947]
2018:07:28-13:48:19 sg115 pluto[24154]: "IpSitA2B0" #1: enabling possible NAT-traversal with method 3
2018:07:28-13:48:19 sg115 pluto[24154]: "IpSitA2B0" #1: NAT-Traversal: Result using RFC 3947: no NAT detected
2018:07:28-13:48:19 sg115 pluto[24154]: "IpSitA2B0" #1: Peer ID is ID_IPV6_ADDR: '2xxx:xxxx::xxxx'
2018:07:28-13:48:19 sg115 pluto[24154]: "IpSitA2B0" #1: Dead Peer Detection (RFC 3706) enabled
2018:07:28-13:48:19 sg115 pluto[24154]: "IpSitA2B0" #1: ISAKMP SA established
2018:07:28-13:48:19 sg115 pluto[24154]: "IpSitA2B1" #2: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP {using isakmp#1}
2018:07:28-13:48:19 sg115 pluto[24154]: "IpSitA2B0" #3: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP {using isakmp#1}
2018:07:28-13:48:19 sg115 pluto[24154]: id="2203" severity="info" sys="SecureNet" sub="vpn" event="Site-to-site VPN up" variant="ipsec" connection="REF_IpsSitA2B" address="2yyyy:yyyy::yyyy" local_net="192.168.1.0/24" remote_net="192.168.30.0/24"
2018:07:28-13:48:19 sg115 pluto[24154]: "IpSitA2B1" #2: sent QI2, IPsec SA established {ESP=>0x7ff2410a <0x9d06f096 DPD}
2018:07:28-13:48:19 sg115 pluto[24154]: "IpSitA2B0" #1: ignoring informational payload, type INVALID_ID_INFORMATION
2018:07:28-13:48:28 sg115 pluto[24154]: "IpSitA2B0" #1: ignoring Delete SA payload: PROTO_IPSEC_ESP SA(0xd9eea003) not found (maybe expired)
2018:07:28-13:48:28 sg115 pluto[24154]: packet from 2xxx:xxxx::xxxx:500: received Vendor ID payload [strongSwan]
2018:07:28-13:48:28 sg115 pluto[24154]: packet from 2xxx:xxxx::xxxx:500: ignoring Vendor ID payload [Cisco-Unity]
2018:07:28-13:48:28 sg115 pluto[24154]: packet from 2xxx:xxxx::xxxx:500: received Vendor ID payload [XAUTH]
2018:07:28-13:48:28 sg115 pluto[24154]: packet from 2xxx:xxxx::xxxx:500: received Vendor ID payload [Dead Peer Detection]
2018:07:28-13:48:28 sg115 pluto[24154]: packet from 2xxx:xxxx::xxxx:500: received Vendor ID payload [RFC 3947]
2018:07:28-13:48:28 sg115 pluto[24154]: packet from 2xxx:xxxx::xxxx:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
2018:07:28-13:48:28 sg115 pluto[24154]: packet from 2xxx:xxxx::xxxx:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
2018:07:28-13:48:28 sg115 pluto[24154]: packet from 2xxx:xxxx::xxxx:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
2018:07:28-13:48:28 sg115 pluto[24154]: packet from 2xxx:xxxx::xxxx:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
2018:07:28-13:48:28 sg115 pluto[24154]: "IpSitA2B1" #4: responding to Main Mode
2018:07:28-13:48:28 sg115 pluto[24154]: "IpSitA2B1" #4: NAT-Traversal: Result using RFC 3947: no NAT detected
2018:07:28-13:48:28 sg115 pluto[24154]: "IpSitA2B1" #4: Peer ID is ID_IPV6_ADDR: '2xxx:xxxx::xxxx'
2018:07:28-13:48:28 sg115 pluto[24154]: "IpSitA2B1" #4: Dead Peer Detection (RFC 3706) enabled
2018:07:28-13:48:28 sg115 pluto[24154]: "IpSitA2B1" #4: sent MR3, ISAKMP SA established
2018:07:28-13:48:28 sg115 pluto[24154]: "IpSitA2B1" #5: responding to Quick Mode
2018:07:28-13:48:28 sg115 pluto[24154]: "IpSitA2B1" #5: IPsec SA established {ESP=>0x2870b384 <0x6c26ef33 DPD}
2018:07:28-13:48:29 sg115 pluto[24154]: "IpSitA2B0" #1: ignoring informational payload, type INVALID_MESSAGE_ID
2018:07:28-13:48:49 sg115 pluto[24154]: "IpSitA2B0" #1: ignoring informational payload, type INVALID_MESSAGE_ID
2018:07:28-13:49:29 sg115 pluto[24154]: "IpSitA2B0" #3: max number of retransmissions (2) reached STATE_QUICK_I1.  No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
2018:07:28-13:49:29 sg115 pluto[24154]: "IpSitA2B0" #3: starting keying attempt 2 of an unlimited number
2018:07:28-13:49:29 sg115 pluto[24154]: "IpSitA2B0" #6: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP to replace #3 {using isakmp#4}
2018:07:28-13:49:29 sg115 pluto[24154]: "IpSitA2B1" #4: next payload type of ISAKMP Hash Payload has an unknown value: 54
2018:07:28-13:49:29 sg115 pluto[24154]: "IpSitA2B1" #4: malformed payload in packet
2018:07:28-13:49:39 sg115 pluto[24154]: "IpSitA2B1" #4: ignoring informational payload, type INVALID_MESSAGE_ID
2018:07:28-13:49:59 sg115 pluto[24154]: "IpSitA2B1" #4: ignoring informational payload, type INVALID_MESSAGE_ID
2018:07:28-13:50:39 sg115 pluto[24154]: "IpSitA2B0" #6: max number of retransmissions (2) reached STATE_QUICK_I1.  No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
2018:07:28-13:50:39 sg115 pluto[24154]: "IpSitA2B0" #6: starting keying attempt 3 of an unlimited number
2018:07:28-13:50:39 sg115 pluto[24154]: "IpSitA2B0" #7: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP to replace #6 {using isakmp#4}
2018:07:28-13:50:39 sg115 pluto[24154]: "IpSitA2B1" #4: next payload type of ISAKMP Hash Payload has an unknown value: 221
2018:07:28-13:50:39 sg115 pluto[24154]: "IpSitA2B1" #4: malformed payload in packet
2018:07:28-13:50:49 sg115 pluto[24154]: "IpSitA2B1" #4: ignoring informational payload, type INVALID_MESSAGE_ID
2018:07:28-13:51:09 sg115 pluto[24154]: "IpSitA2B1" #4: ignoring informational payload, type INVALID_MESSAGE_ID
2018:07:28-13:51:49 sg115 pluto[24154]: "IpSitA2B0" #7: max number of retransmissions (2) reached STATE_QUICK_I1.  No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
2018:07:28-13:51:49 sg115 pluto[24154]: "IpSitA2B0" #7: starting keying attempt 4 of an unlimited number
2018:07:28-13:51:49 sg115 pluto[24154]: "IpSitA2B0" #8: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP to replace #7 {using isakmp#4}
2018:07:28-13:51:49 sg115 pluto[24154]: "IpSitA2B1" #4: next payload type of ISAKMP Hash Payload has an unknown value: 157
2018:07:28-13:51:49 sg115 pluto[24154]: "IpSitA2B1" #4: malformed payload in packet
2018:07:28-13:51:59 sg115 pluto[24154]: "IpSitA2B1" #4: ignoring informational payload, type INVALID_MESSAGE_ID
2018:07:28-13:52:19 sg115 pluto[24154]: "IpSitA2B1" #4: ignoring informational payload, type INVALID_MESSAGE_ID
2018:07:28-13:52:59 sg115 pluto[24154]: "IpSitA2B0" #8: max number of retransmissions (2) reached STATE_QUICK_I1.  No acceptable response to our first Quick Mode message: perhaps peer likes no proposal

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 .... ;-(

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

I execute the above command on the sophos utm and after that my connection was lost. I have no remote access anymore.

The static ipv6 address to outsite is no longer available. I think that I will power off (and on) the utm via power manually.

Let's drive with my car ...

On the other site, the utmA has the IP 192.168.50.81 and ipsec for eth7 (wan and ipv6)) and eth0 (lan) 192.168.30.254. The ip 192.168.30.1 is the windows server in the lan.

A normal ping from utmB with its IP 192.168.1.1 (lan) and 192.168.3.1 (wan and ipv6) can be seen on utmA with tcpdump

sg135:/root # tcpdump -i eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
19:23:34.291413 IP 192.168.1.1 > srv2012: ICMP echo request, id 37664, seq 1, length 64
19:23:34.291801 IP srv2012 > 192.168.1.1: ICMP echo reply, id 37664, seq 1, length 64

The ping you posted is not seen on sg135 (utmA). And utmB is hanging after execution of the command ;-(

Is the test scenario the right one? Should I use other IP addresses?

In UTM B, please copy and paste the following to the command line:

ping -I 192.168.1.1 192.168.30.254 -s 1500 -M do

What result does that give?

I have to admit that I'm a little confused about the topology.  Is the 4kB/sec download between two devices communicating via their IPv4 addresses - or are some local IPv6 addresses connected via the IPsec tunnel?

MfG - Bob (Bitte auf Deutsch weiterhin.)

Ergibt das gleiche REsultat. Die Box hängt sich für eine gewisse Zeit weg und ist nicht mehr erreichbar.

Der Download ist von zwei Geräten mit IPv4 hinter den UTMs.

srv2012 - utm <-> utm - linux

Der linux Rechner mountet per cifs eine Freigabe vom MS-Server und kopiert dann mit rsync von remote zu lokal.

Sind eventuell noch ipsec Kommandos nützlich?

Ergibt das gleiche REsultat. Die Box hängt sich für eine gewisse Zeit weg und ist nicht mehr erreichbar.

Der Download ist von zwei Geräten mit IPv4 hinter den UTMs.

srv2012 - utm <-> utm - linux

Der linux Rechner mountet per cifs eine Freigabe vom MS-Server und kopiert dann mit rsync von remote zu lokal.

Sind eventuell noch ipsec Kommandos nützlich?

MTU Size des Netzbetreibers (Glasfaser) scheint 1500 zu sein.

That's strange.  I didn't think an MSS issue (the issue that I suspect) could cause a lockup.

What do you get in the other UTM with this?

ping -I 192.168.30.254 192.168.1.1 -s 1500 -M do

MfG - Bob (Bitte auf Deutsch weiterhin.)

Ich bin gerade auch ein wenig verwirrt. Auf einer UTM sehe ich dieses im tcpdump...

21:07:32.506885 IP (tos 0x0, ttl 64, id 706, offset 0, flags [none], proto UDP (17), length 29)
    192.168.1.127.4500 > 89.204.136.64.4500: [no cksum] isakmp-nat-keep-alive
21:07:32.636080 IP (tos 0x0, ttl 52, id 41463, offset 0, flags [none], proto UDP (17), length 164)
    89.204.136.64.4500 > 192.168.1.127.4500: [udp sum ok] UDP-encap: ESP(spi=0x02f1d4c2,seq=0x44), length 136
21:07:32.676742 IP (tos 0x50, ttl 64, id 53525, offset 0, flags [none], proto UDP (17), length 164)
    192.168.1.127.4500 > 89.204.136.64.4500: [no cksum] UDP-encap: ESP(spi=0x00f44c5d,seq=0x49), length 136
21:07:32.678301 IP (tos 0x50, ttl 64, id 57356, offset 0, flags [none], proto UDP (17), length 164)
    192.168.1.127.4500 > 89.204.136.64.4500: [no cksum] UDP-encap: ESP(spi=0x00f44c5d,seq=0x4a), length 136
21:07:55.453097 IP (tos 0x0, ttl 64, id 31820, offset 0, flags [none], proto UDP (17), length 29)
    192.168.1.127.4500 > 89.204.136.64.4500: [no cksum] isakmp-nat-keep-alive

Dies ist nicht mein IPv6 IPSec Tunnel. Scheint einer von intern zu extern zu sein (ob da jemand eine NAS-Platte oder sowas eingesteckt hat)...

Kann dies meinen IPSec Tunnel beeinflußen?

Der ping hing natürlich wieder ...

loginuser@sg135:/home/login > ping -I 192.168.30.254 192.168.1.1 -s 1500 -M do -c 1
PING 192.168.1.1 (192.168.1.1) from 192.168.30.254 : 1500(1528) bytes of data.

Aber -M do besagt ja auch, dass er nicht fragmentieren soll. Und an die 1500 werden scheinbar noch weitere 28 bytes gehangen ...

I would have expected something like the following which is the result I usually see from a don't-fragment ping.

loginuser@sg135:/home/login # ping -I 192.168.30.254 192.168.1.1 -s 1500 -M do
PING 192.168.1.1 (192.168.1.1) from 192.168.30.254 : 1500(1528) bytes of data.
ping: local error: Message too long, mtu=1406
ping: local error: Message too long, mtu=1406
ping: local error: Message too long, mtu=1406

 You can look inside an IPsec tunnel.  Find the _REF of a tunnel named Allee with:

cc get_object_by_name ipsec_connection site_to_site Allee |grep \'ref\'

Assuming that that gave you REF_IpsSitAllee, you can do a tcpdump on the traffic inside the tunnel with:

espdump -n --conn REF_IpsSitAllee -vv

MfG - Bob (Bitte auf Deutsch weiterhin.)

Danke für die gute Hilfe bisher ...

Ein ping geht scheinbar nur bis ...

loginuser@sg135:/home/login > ping -I 192.168.50.81 192.168.1.1 -s 1362
PING 192.168.1.1 (192.168.1.1) from 192.168.50.81 : 1362(1390) bytes of data.
1370 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=5.72 ms
1370 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=5.57 ms
^C
--- 192.168.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 5.578/5.649/5.720/0.071 ms
loginuser@sg135:/home/login > ping -I 192.168.50.81 192.168.1.1 -s 1364 -c 1
PING 192.168.1.1 (192.168.1.1) from 192.168.50.81 : 1364(1392) bytes of data.

--- 192.168.1.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

Das cc Kommando kenne ich nicht. Nur die ipsec <optionen>.

sg135:/root # cc get_object_by_name ipsec_connection site_to_site Allee
0

Beim dump für eine der Verbindungen...

sg135:/root # espdump -n --conn S_REF_IpsSitA2B
Running: tcpdump -ieth7 -Efile /tmp/espdump.12552/sas -s0 -n (esp) and ((host bxxx:xxxx::xxxx8 and host axxx:xxxx::xxxx9))
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth7, link-type EN10MB (Ethernet), capture size 65535 bytes
22:11:03.083223 IP6 bxxx:xxxx::xxxx8 > axxx:xxxx::xxxx9: ESP(spi=0xd4934d25,seq=0x341), length 100: IP 192.168.30.145.1022 > 192.168.1.99.2049: Flags [.], ack 1337913436, win 229, options [nop,nop,TS val 3818201 ecr 81674839], length 0
22:11:03.088914 IP6 axxx:xxxx::xxxx9 > bxxx:xxxx::xxxx8: ESP(spi=0x3b705b02,seq=0x442), length 100: IP 192.168.1.99.2049 > 192.168.30.145.1022: Flags [.], ack 1, win 235, options [nop,nop,TS val 81689841 ecr 3803201], length 0
22:11:03.239305 IP6 bxxx:xxxx::xxxx8 > axxx:xxxx::xxxx9: ESP(spi=0xd4934d25,seq=0x342), length 212: IP 192.168.30.145.3718963109 > 192.168.1.99.2049: 104 getattr [|nfs]
22:11:03.244660 IP6 axxx:xxxx::xxxx9 > bxxx:xxxx::xxxx8: ESP(spi=0x3b705b02,seq=0x443), length 148: IP 192.168.1.99.2049 > 192.168.30.145.3718963109: reply ok 44 getattr [|nfs]
22:11:03.245127 IP6 bxxx:xxxx::xxxx8 > axxx:xxxx::xxxx9: ESP(spi=0xd4934d25,seq=0x343), length 100: IP 192.168.30.145.1022 > 192.168.1.99.2049: Flags [.], ack 49, win 229, options [nop,nop,TS val 3818241 ecr 81689879], length 0
22:11:03.634498 IP6 axxx:xxxx::xxxx9 > bxxx:xxxx::xxxx8: ESP(spi=0x3b705b02,seq=0x444), length 884: IP 192.168.1.226.5060 > 192.168.30.3.5060: SIP, length: 814

Anbei noch die Ausgabe vom cc Kommando (ich musste den Namen mit Leerzeichen verwenden, den ich im Webadmin angegeben habe):

sg135:/root # cc get_object_by_name ipsec_connection site_to_site "standortA - standortB"
{
          'autoname' => 0,
          'class' => 'ipsec_connection',
          'data' => {
                      'auto_pf_in' => 'REF_PacPacAnyFromFritz',
                      'auto_pf_out' => 'REF_PacPacAnyFromGlasf',
                      'auto_pfrule' => 1,
                      'bind' => 0,
                      'comment' => '',
                      'interface' => 'REF_IntEthEth7',
                      'name' => 'standortA - standortB',
                      'networks' => [
                                      'REF_NetIntEth7Networ',
                                      'REF_DefaultInternalNetwork'
                                    ],
                      'policy' => 'REF_OrkXmBRdER',
                      'remote_gateway' => 'REF_IpsRemStandortAStandortB',
                      'status' => 1,
                      'strict_routing' => 0
                    },
          'hidden' => 0,
          'lock' => '',
          'nodel' => '',
          'ref' => 'REF_IpsSitStandortAStandortB',
          'type' => 'site_to_site'
        }

sg135:/root # espdump -n --conn REF_IpsSitStandortAStandortB -vv
Running: tcpdump -ieth7 -Efile /tmp/espdump.25934/sas -s0 -n -vv (esp) and ((host axxx:xxxx::xxxx and host bxxx:xxxx::xxxx))
tcpdump: listening on eth7, link-type EN10MB (Ethernet), capture size 65535 bytes
08:02:34.504311 IP6 (hlim 250, next-header ESP (50) payload length: 404) bxxx:xxxx::xxxx > axxx:xxxx::xxxx: ESP(spi=0x455ce51e,seq=0x880), length 404: IP (tos 0x0, ttl 127, id 1090, offset 0, flags [DF], proto TCP (6), length 356)
    192.168.1.117.49165 > 192.168.30.1.445: Flags [P.], cksum 0xefce (correct), seq 330896638:330896954, ack 39452055, win 254, length 316SMB-over-TCP packet:(raw data or continuation?)

08:02:34.505193 IP6 (hlim 64, next-header ESP (50) payload length: 324) axxx:xxxx::xxxx > bxxx:xxxx::xxxx: ESP(spi=0x3f04ecc7,seq=0x71f), length 324: IP (tos 0x0, ttl 127, id 1548, offset 0, flags [DF], proto TCP (6), length 284)
    192.168.30.1.445 > 192.168.1.117.49165: Flags [P.], cksum 0x2dd1 (correct), seq 1:245, ack 316, win 253, length 244SMB-over-TCP packet:(raw data or continuation?)

08:02:34.510626 IP6 (hlim 250, next-header ESP (50) payload length: 180) bxxx:xxxx::xxxx > axxx:xxxx::xxxx: ESP(spi=0x455ce51e,seq=0x881), length 180: IP (tos 0x0, ttl 127, id 1091, offset 0, flags [DF], proto TCP (6), length 132)
    192.168.1.117.49165 > 192.168.30.1.445: Flags [P.], cksum 0xaed3 (correct), seq 316:408, ack 245, win 253, length 92SMB-over-TCP packet:(raw data or continuation?)

08:02:34.511289 IP6 (hlim 64, next-header ESP (50) payload length: 212) axxx:xxxx::xxxx > bxxx:xxxx::xxxx: ESP(spi=0x3f04ecc7,seq=0x720), length 212: IP (tos 0x0, ttl 127, id 1549, offset 0, flags [DF], proto TCP (6), length 168)
    192.168.30.1.445 > 192.168.1.117.49165: Flags [P.], cksum 0xa41f (correct), seq 245:373, ack 408, win 253, length 128SMB-over-TCP packet:(raw data or continuation?)

08:02:34.516666 IP6 (hlim 250, next-header ESP (50) payload length: 308) bxxx:xxxx::xxxx > axxx:xxxx::xxxx: ESP(spi=0x455ce51e,seq=0x882), length 308: IP (tos 0x0, ttl 127, id 1092, offset 0, flags [DF], proto TCP (6), length 260)
    192.168.1.117.49165 > 192.168.30.1.445: Flags [P.], cksum 0xfad2 (correct), seq 408:628, ack 373, win 253, length 220SMB-over-TCP packet:(raw data or continuation?)

08:02:34.517365 IP6 (hlim 64, next-header ESP (50) payload length: 324) axxx:xxxx::xxxx > bxxx:xxxx::xxxx: ESP(spi=0x3f04ecc7,seq=0x721), length 324: IP (tos 0x0, ttl 127, id 1550, offset 0, flags [DF], proto TCP (6), length 284)
    192.168.30.1.445 > 192.168.1.117.49165: Flags [P.], cksum 0x46af (correct), seq 373:617, ack 628, win 252, length 244SMB-over-TCP packet:(raw data or continuation?)

...

and some sip traffic which is working...

08:03:07.395197 IP6 (hlim 250, next-header ESP (50) payload length: 900) axxx:xxxx::xxxx > bxxx:xxxx::xxxx: ESP(spi=0x455ce51e,seq=0x8ab), length 900: IP (tos 0x68, ttl 63, id 0, offset 0, flags [DF], proto UDP (17), length 859)
    192.168.1.227.5060 > 192.168.30.3.5060: [udp sum ok] SIP, length: 831
        REGISTER sip:192.168.30.3:5060 SIP/2.0
        Via: SIP/2.0/UDP 192.168.1.227:5060;branch=z9hG4bK2452320308
        From: "B User1" <sip:05@192.168.30.3:5060>;tag=2178585412
        To: "B User1" <sip:05@192.168.30.3:5060>
        Call-ID: 0_116685649@192.168.1.227
        CSeq: 1274 REGISTER
        Contact: <sip:05@192.168.1.227:5060>
        Proxy-Authorization: Digest username="hi1nvkt", realm="3CXPhoneSystem", nonce="414d535c11732f9c42:51923f46fcf2023e0407ca2ad9ebcc1b", uri="sip:192.168.30.3:5060", response="6a858d2e0ceda603e09de93cf3ad31b7", algorithm=MD5
        Allow: INVITE, INFO, PRACK, ACK, BYE, CANCEL, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE, REFER, PUBLISH, UPDATE, MESSAGE
        Max-Forwards: 70
        User-Agent: Yealink SIP-T46S 66.82.0.20 805ec0223814
        Expires: 120
        Allow-Events: talk,hold,conference,refer,check-sync
        Mac: 80:5e:c0:22:38:14
        Content-Length: 0


        0x0000:  5245 4749 5354 4552 2073 6970 3a31 3932
        0x0010:  2e31 3638 2e33 302e 333a 3530 3630 2053
        0x0020:  4950 2f32 2e30 0d0a 5669 613a 2053 4950
        0x0030:  2f32 2e30 2f55 4450 2031 3932 2e31 3638
        0x0040:  2e31 2e32 3237 3a35 3036 303b 6272 616e
        0x0050:  6368 3d7a 3968 4734 624b 3234 3532 3332
        0x0060:  3033 3038 0d0a 4672 6f6d 3a20 2254 5033
        0x0070:  2042 656e 6a61 6d69 6e22 203c 7369 703a
        0x0080:  3035 4031 3932 2e31 3638 2e33 302e 333a
        0x0090:  3530 3630 3e3b 7461 673d 3231 3738 3538

Ist dies hier eventuell die Lösung???

https://ideas.sophos.com/forums/17359-utm-formerly-asg-feature-requests/suggestions/7735803-option-to-manage-mss-size

https://community.sophos.com/products/unified-threat-management/f/general-discussion/89663/issue-of-mss-on-ipsec-vpn

iptables -I FORWARD 1 -o -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1320

oder aus 1360?

Verstehe nur nicht so ganz, woher ich diesen Wert bekomme?

You might want to read Problems viewing some websites when accessed through an IPsec tunnel and Issue of MSS on IPSEC VPN.  I would try setting the mss to 1362 per your tests.

MfG - Bob (Bitte auf Deutsch weiterhin.)

Die iptables Regel aber dann auf beiden utms?

Muss ich an der mtu auch noch was umstellen?