This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

Hallo zusammen,

ich habe zwischen zwei Standorten mit einer SG115 und SG135 eine IPSec Verbindung über IPv6 eingerichtet. Ein Anschluß hat 100Mbit/s Down/Up und der andere hat 200Mbit down/up. Ein ping zwischen beiden UTM's dauert ca. 8ms. Das Einbinden von Freigaben und anschließende Kopieren dauert ewig. Es werden nur 4 kB/s angezeigt.

Leider habe ich keine Idee mehr, wo ich ansetzen soll.

 

Übersicht der IPSec VErbindung in der Site-to-Site Übersicht:

SA: 192.168.30.0/24=2a00:xxxxx   2a00:xxxxx=192.168.1.0/24
VPN ID: 2a00:xxxxxx
IKE: Auth PSK / Enc AES_CBC_256 / Hash HMAC_MD5 / Lifetime 7800s / DPD
ESP: Enc AES_CBC_256 / Hash HMAC_MD5 / Lifetime 3600s
 
   

 

 

Danke!



This thread was automatically locked due to age.
Parents
  • 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

  • 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.)

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 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.)

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Die iptables Regel aber dann auf beiden utms?

    Muss ich an der mtu auch noch was umstellen?

  • So, ich habe auf beiden UTMs die iptables-Regel hinzugefügt:

    iptables -t filter -I FORWARD 1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1362

     

    Kann jedoch leider keine wirkliche Verbesserung feststellen (5kb Durchsatz ;-()

    (Auf einem linux client wird per cifs eine Windows-Freigabe gemountet)

     

    Im espdump kann ich auf der Zielutm sowas hier sehen:

        192.168.1.99.52574 > 192.168.30.1.445: Flags [.], cksum 0xb265 (correct), seq 1, ack 203376, win 1430, options [nop,nop,TS val 112676115 ecr 84816576,nop,nop,sack 1 {224784:226122}], length 0
        192.168.30.1.445 > 192.168.1.99.52574: Flags [.], cksum 0x1d73 (correct), seq 203376:204714, ack 1, win 255, options [nop,nop,TS val 84816607 ecr 112676115], length 1338SMB-over-TCP packet:(raw data or continuation?)
        192.168.1.99.52574 > 192.168.30.1.445: Flags [.], cksum 0xacb0 (correct), seq 1, ack 204714, win 1444, options [nop,nop,TS val 112676193 ecr 84816607,nop,nop,sack 1 {224784:226122}], length 0
        192.168.30.1.445 > 192.168.1.99.52574: Flags [.], cksum 0x17cc (correct), seq 204714:206052, ack 1, win 255, options [nop,nop,TS val 84816638 ecr 112676193], length 1338SMB-over-TCP packet:(raw data or continuation?)
        192.168.1.99.52574 > 192.168.30.1.445: Flags [.], cksum 0xa70f (correct), seq 1, ack 206052, win 1438, options [nop,nop,TS val 112676271 ecr 84816638,nop,nop,sack 1 {224784:226122}], length 0
        192.168.30.1.445 > 192.168.1.99.52574: Flags [.], cksum 0x1225 (correct), seq 206052:207390, ack 1, win 255, options [nop,nop,TS val 84816669 ecr 112676271], length 1338SMB-over-TCP packet:(raw data or continuation?)
        192.168.1.99.52574 > 192.168.30.1.445: Flags [.], cksum 0xa163 (correct), seq 1, ack 207390, win 1444, options [nop,nop,TS val 112676348 ecr 84816669,nop,nop,sack 1 {224784:226122}], length 0
        192.168.30.1.445 > 192.168.1.99.52574: Flags [.], cksum 0x0c7f (correct), seq 207390:208728, ack 1, win 255, options [nop,nop,TS val 84816700 ecr 112676348], length 1338SMB-over-TCP packet:(raw data or continuation?)
        192.168.1.99.52574 > 192.168.30.1.445: Flags [.], cksum 0x9bbc (correct), seq 1, ack 208728, win 1444, options [nop,nop,TS val 112676426 ecr 84816700,nop,nop,sack 1 {224784:226122}], length 0
        192.168.30.1.445 > 192.168.1.99.52574: Flags [.], cksum 0x06d8 (correct), seq 208728:210066, ack 1, win 255, options [nop,nop,TS val 84816731 ecr 112676426], length 1338SMB-over-TCP packet:(raw data or continuation?)
        192.168.1.99.52574 > 192.168.30.1.445: Flags [.], cksum 0x961c (correct), seq 1, ack 210066, win 1438, options [nop,nop,TS val 112676503 ecr 84816731,nop,nop,sack 1 {224784:226122}], length 0
        192.168.30.1.445 > 192.168.1.99.52574: Flags [.], cksum 0x0132 (correct), seq 210066:211404, ack 1, win 255, options [nop,nop,TS val 84816762 ecr 112676503], length 1338SMB-over-TCP packet:(raw data or continuation?)

     

    An der MTU Größe habe ich bsiher noch nichts geändert.

     

    Kopiere ich per rsync file von einem Linux-Rechner zu einem anderen über den Tunnel, sieht die Performance besser aus (habe zuvor auf der Gegenseite mit dd unterschiedlich große files angelegt):

    root@homer:~/test# rsync -avz --progress test@192.168.30.145:/home/test/*.file .
    test@192.168.30.145's password:
    receiving incremental file list
    1000mb.file
      1,048,576,000 100%   42.86MB/s    0:00:23 (xfr#1, to-chk=3/4)
    100mb.file
        104,857,600 100%   24.59MB/s    0:00:04 (xfr#2, to-chk=2/4)
    10mb.file
         10,485,760 100%   35.97MB/s    0:00:00 (xfr#3, to-chk=1/4)
    1mb.file
          1,048,576 100%    3.50MB/s    0:00:00 (xfr#4, to-chk=0/4)

    sent 100 bytes  received 1,133,248 bytes  35,979.30 bytes/sec
    total size is 1,164,967,936  speedup is 1,027.90

  • Und noch was herausfinden können:

     

    ping6 -s 1432 -I axxx:xxxx::xxxx bxxx:xxxx::xxxx -i 1 -c 1 -M do

    1440 bytes from bxxx:xxxx::xxxx: icmp_seq=1 ttl=250 time=5.72 ms

     

    funktioniert. Alles darüber an Größe endet in Error.

     

    From bxxx:xxxx::xxxx icmp_seq=1 Packet too big: mtu=1480

     

    Jetzt habe ich zwar viele Informationen gewinnen können, jedoch ist mir noch nicht klar, wie und was ich nun an der Sophos UTM anpassen muss?

    Die MTU-Größe auf 1432 (+ 8 byte icmp header + 40 byte ipv6 header = 1480) oder direkt auf 1480? Oder muss/soll ich die gar nicht ändern (eventuell Auswirkungen auf das restliche Netzwerk hinter der mtu)?

    Muss ich die iptables FORWARD Regel auch anpassen?

Reply
  • Und noch was herausfinden können:

     

    ping6 -s 1432 -I axxx:xxxx::xxxx bxxx:xxxx::xxxx -i 1 -c 1 -M do

    1440 bytes from bxxx:xxxx::xxxx: icmp_seq=1 ttl=250 time=5.72 ms

     

    funktioniert. Alles darüber an Größe endet in Error.

     

    From bxxx:xxxx::xxxx icmp_seq=1 Packet too big: mtu=1480

     

    Jetzt habe ich zwar viele Informationen gewinnen können, jedoch ist mir noch nicht klar, wie und was ich nun an der Sophos UTM anpassen muss?

    Die MTU-Größe auf 1432 (+ 8 byte icmp header + 40 byte ipv6 header = 1480) oder direkt auf 1480? Oder muss/soll ich die gar nicht ändern (eventuell Auswirkungen auf das restliche Netzwerk hinter der mtu)?

    Muss ich die iptables FORWARD Regel auch anpassen?

Children
  • Leider bringt nur diese iptables Regel keinen wirklichen Erfolg. Von einem Windows-Rechner aus kann ich auch nur einen ping mit angegeben Größe von 1362 durchführen.

    Sorry, aber was muss ich noch alles ändern (und wo), damit der IPv6-Tunnel mit den dahinterliegenden IPv4 Netzen endlich funktioniert.

     

    Vielen Dank!

  • Puh, ich komme nicht weiter ...

     

     

    IPv4 LAN <-> UTM IPv6 < ---- > UTM IPv6 <-> LAN IPv4

     

    ping6 -s zw. den UTM's IPv6 geht bis 1432 (MTU der UTM's habe ich auf 1480 gesetellt)

    ping -s 1362 im LAN zu LAN (IPv4) ist maximum

     

    Die MTU der UTM's habe ich auf 1480 gestellt. Muss ich die MTU der Clients im LAN (IPv4) auch entsprechend herabsetzen?

    Wenn ja, auf welchen Wert? MTU 1390?

     

    So wird es zumindestens beim ping angezeigt ....

    ping -s 1364 192.168.30.254 -D -c 1
    PING 192.168.30.254 (192.168.30.254): 1364 data bytes
    556 bytes from 192.168.2.1: frag needed and DF set (MTU 1390)
    Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
     4  5  00 7005 52f1   0 0000  40  01 404a 192.168.2.3  192.168.30.254

     

    Seltsamerweise geht eine OpenVPN-Verbindung über feste-ip "ohne Probleme". Nur komme ich dort nur auf die Geschwindigkeit von feste-ip und nicht auf die vom möglichen Glasfaseranschluß im Netz der Deutschen Glasfaser (100 up and down).

     

    Hat vlt. noch jemand eine Idee oder einen Tipp für mich???

     

    Vielen Dank...

  • 556 bytes from 192.168.2.1: frag needed

    Ahh, it looks like you have the dreaded MTU problem.  try a Google:

    site:community.sophos.com/products/unified-threat-management/f MTU 576

    MfG - Bob (Bitte auf Deutsch weiterhin.)

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Schon mal vielen Dank für die Antwort.

     

    Allerdings verstehe ich sie nicht ganz, da ich keine Dynamic IP nutze. Ich habe auf dem WAN die MTU manuell von 1500 auf 1480 gesetzt.

  • Der Ping geht wieder wie zuvor beschrieben bis size 1362 durch. Ansonsten erhalte ich die Fehlermeldung Message to Long, mtu=1382

    Allerdings bricht die ubertragungsgeschwindigkeit bei größeren Dateien ein.

    Was kann ich noch machen/versuchen?

    Werden noch irgendwelche tcpdumps benötigt?

    Vielen Dank!

  • Noch jemand eine Idee, was ich noch probieren kann?

  • Did you enable the option:  "Support path MTU discovery" under the "remote gateway"?


    Managing several Sophos firewalls both at work and at some home locations, dedicated to continuously improve IT-security and feeling well helping others with their IT-security challenges.

  • Thanks for your answer. Yes, I did.

    The next idea is to change the mtu size on the Tunnel end points (Clients) to 1390.

    I do Not have any Problems with small packets, like voip.

  • Sorry, but I Need your help!

    I changed the mtu to 1390 on both Computer endpoints. After Mounting a Share and transfering Data, the Speed of the connecting slows down again.

    What can I do NOW to get the Tunnel working as expected?

    Thanks

  • Additional Info:

    I can See the following in the espdump onnthe Sophos

    ....length 1338SMB-over-TCP packet: (raw Data or continuation?)

    One side is a Windows with Share mounted via cifs on Linux Client. I also disabled lso in Windows.