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

  • 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?

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

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

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

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