Mikrotik IPsec VPN site to site

[sxbcl]

Επειδή δεν θυμάμαι τι έγραψες...
το ΜΤ είναι πίσω από το speed με passthrough ή απλά το έχεις πίσω από το speed;

Το ΜΤ είναι απλά πίσω από το Speedport.
Δηλαδή:
Speedport 192.168.1.1
MT: 192.168.1.254

Στο Speedport port forward 500 & 4500 προς την 192.168.1.254 για το IPsec και static route για τα δίκτυα 192.168.2.0/24 και 10.100.0.0/16 προς το 192.168.1.254
Το ΜΤ έχει όλα τα IPsec policies που χρειάζονται και όλα τα accept srcnat για τα δίκτυα του γραφείου.

[sokin87]

Δοκίμασε να κάνεις disable τον κανόνα drop invalid στο filter (ή όλους τους DROP και στα 2 router για δοκιμή να διαπιστώσεις αν σε κόβει κάποιος κανόνας) να δείς αν κάνει διαφορά και επίσης παρακολούθησε τα connection όταν χτυπάς κάποιο web interface να δείς πραγματικά από τι IP έρχονται τα request. Επίσης δώσε ως gateway σε κάποια συσκευή στο 1.0/24 την 1.254 ώστε να μη περνάς από το Cosmote. Είχα παρόμοιο πρόβλημα με PPTP, δεν το βρήκα ποτέ, με L2TP μέχρι τώρα δουλεύουν μια χαρά, αν βρείς τι φταίει κάποια στιγμή ενημέρωσε μας, καλή συνέχεια.

[sxbcl]

Δοκίμασε να κάνεις disable τον κανόνα drop invalid στο filter (ή όλους τους DROP και στα 2 router για δοκιμή να διαπιστώσεις αν σε κόβει κάποιος κανόνας) να δείς αν κάνει διαφορά και επίσης παρακολούθησε τα connection όταν χτυπάς κάποιο web interface να δείς πραγματικά από τι IP έρχονται τα request. Επίσης δώσε ως gateway σε κάποια συσκευή στο 1.0/24 την 1.254 ώστε να μη περνάς από το Cosmote. Είχα παρόμοιο πρόβλημα με PPTP, δεν το βρήκα ποτέ, με L2TP μέχρι τώρα δουλεύουν μια χαρά, αν βρείς τι φταίει κάποια στιγμή ενημέρωσε μας, καλή συνέχεια.

Δυστυχώς τα έκανα και τα 2 που αναφέρεις χωρίς αποτέλεσμα. Και όλα τα rules στο firewall έριξα, αν και δεν έχω τίποτα ιδιαίτερο από τη στιγμή που δεν είναι εκτεθειμένο το ΜΤ στο ίντερνετ, αλλά και στη VoIP συσκευή έβαλα gateway το ΜΤ για να μην γίνεται το ρουτάρισμα από το Speedport. Καμιά διαφορά.
Η εγκατάσταση είναι στο εξοχικό, θα το δω όταν πάω ανάμεσα στη θάλασσα και τη μεσημεριανο-απογευματινή σιέστα, συνοδεία καλού τσίπουρου. Μόνο έτσι θα λυθεί!

- - - Updated - - -

Νομίζω ότι μια από τις σκέψεις μου βγαίνει σωστή.
Κάτι παίζει με το MTU size.
Δείτε το παρακάτω και εξηγώ:

PS C:\Users\c> ping 192.168.1.254 -l 1402 -f

Pinging 192.168.1.254 with 1402 bytes of data:
Reply from 192.168.1.254: bytes=1402 time=20ms TTL=63
Reply from 192.168.1.254: bytes=1402 time=20ms TTL=63
Reply from 192.168.1.254: bytes=1402 time=21ms TTL=63
Reply from 192.168.1.254: bytes=1402 time=19ms TTL=63

Ping statistics for 192.168.1.254:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 19ms, Maximum = 21ms, Average = 20ms
PS C:\Users\c> ping 192.168.1.254 -l 1403 -f

Pinging 192.168.1.254 with 1403 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 192.168.1.254:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
PS C:\Users\c> ping 10.1.1.1 -l 1403 -f

Pinging 10.1.1.1 with 1403 bytes of data:
Reply from 10.1.1.1: bytes=1403 time=10ms TTL=62
Reply from 10.1.1.1: bytes=1403 time=7ms TTL=62
Reply from 10.1.1.1: bytes=1403 time=3ms TTL=62
Reply from 10.1.1.1: bytes=1403 time=12ms TTL=62

Ping statistics for 10.1.1.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 3ms, Maximum = 12ms, Average = 8ms

Κάνω ping από το γραφείο στο ΜΤ του εξοχικού με 1402 bytes, όλα ΟΚ.
Κάνω πάλι το ίδιο ping με 1403 bytes, πρέπει να γίνει fragmented.

Για να συγκρίνω, κάνω ping με άλλο IPsec VPN που έχω και λειτουργεί με 1403 bytes, περνάει κανονικά! Δουλεύει το ping μέχρι και 1464 bytes.

Για πείτε οι πιο ειδικοί από εμένα τι μπορεί να συμβαίνει!!!

[sokin87]

Δες εδώ, θυμίζει πολύ το δικό σου πρόβλημα.
https://forum.mikrotik.com/viewtopic.php?t=143990
Δοκίμασε να αλλάζεις το MTU στη κίνηση που θα περάσει από το Tunnel με Mangle, το clamp-to-pmtu πιθανός να μη παίξει οπότε δώσε καρφί το 1402 ή 1382 π.χ.

[sxbcl]

Κάτι τέτοιο δηλαδή:

add action=change-mss chain=forward new-mss=1452 out-interface=bridge1 passthrough=yes protocol=tcp tcp-flags=syn,!rst tcp-mss=1453-65535
add action=change-mss chain=forward in-interface=bridge1 new-mss=1452 passthrough=yes protocol=tcp tcp-flags=syn,!rst tcp-mss=1453-65535

Σε ποιο interface να το κάνω; Στο bridge, όπως το παράδειγμα; Ή μήπως καλύτερα να βάλω src-address & dst-address;

[sokin87]

Με Dst καλύτερα όχι πάνω στο bridge, δε χρειλαζεται να αλλάζει το mtu για όλη την κίνηση, σε κάθε router αντίστοιχα τα dst του remote. Αν είναι κάντο με address list για λόγους επεκτασιμότητας αργότερα.

[sxbcl]

Με Dst καλύτερα όχι πάνω στο bridge, δε χρειλαζεται να αλλάζει το mtu για όλη την κίνηση, σε κάθε router αντίστοιχα τα dst του remote. Αν είναι κάντο με address list για λόγους επεκτασιμότητας αργότερα.

Με δοκιμές έβαλα το παρακάτω και σχεδόν δούλεψε:

/ip firewall mangle
 add action=change-mss chain=forward new-mss=1390 passthrough=yes protocol=tcp tcp-flags=syn,!rst tcp-mss=1391-65535

Βασικά δε με πειράζει να αλλάζει το MTU όλης της κίνησης, καθώς η μόνη κίνηση που περνάει από το ΜΤ είναι για το VPN.

Να εξηγήσω το "σχεδόν" στο ότι δούλεψε. Ανοίγει πλέον το web interface της απομακρυσμένης VoIP συσκευής και του H1600. Εξακολουθεί όμως να μην ανοίγει του ΜΤ. Και με winbox ναι μεν συνδέεται στο ΜΤ απομακρυσμένα, αλλά δε φέρνει δεδομένα και μετά από λίγο κόβεται η επικοινωνία.
Φυσικά και δε γίνεται να αλλάξω το MTU στο input chain, επομένως κάποια πρόταση;
Δεν είναι θέμα /ip services, εκεί δεν έχω βάλει κάποιο rule

[deniSun]

Το ΜΤ είναι απλά πίσω από το Speedport.

Όλη η κίνηση περνάει μέσα από το speed.
Τι κάνει το qos στο speed δεν μπορούμε να είμαστε σίγουροι.

αλλά και στη VoIP συσκευή έβαλα gateway το ΜΤ για να μην γίνεται το ρουτάρισμα από το Speedport.

Λόγω του παραπάνω δεν θα δεις διαφορά.
Εγώ ακόμα και τις passthrough υλοποιήσεις δεν τις εμπιστεύομαι.
Πιστεύω ότι και εκεί υπάρχει κάποιος έλεγχος από το speed.
Η πιο καθαρή λύση είναι κλήση ΡΡΡοΕ από το ΜΤ.

Κάτι παίζει με το MTU size.

Αυτό γίνεται όταν κάνεις vpn σύνδεση ή/και χωρίς αυτή.
Αν το κάνει χωρίς vpn τότε ναι ευθύνεται το MTU αν και μου φαίνεται περίεργο γιατί στο speed το αλλάζει (εκτός και αν για κάποιον λόγο δεν πέρασαν το σωστό προφίλ, που και πάλι μου φαίνεται περίεργο).
Επίσης... η καμπίνα είναι του ΟΤΕ ή voda/wind;

[sxbcl]

Όλη η κίνηση περνάει μέσα από το speed.
Επίσης... η καμπίνα είναι του ΟΤΕ ή voda/wind;

Καλή ερώτηση! Δεν έχω ιδέα! Πώς μπορώ να το καταλάβω;
Πάντως με την αλλαγή στο mangle του mtu σε 1390 παίζει στο βαθμό που ανέφερα πιο πάνω.
Από αυτά που διάβασα γύρω γύρω, το overhead του IPsec είναι 28 bytes. Άρα η σύνδεση σηκώνει MTU μέχρι 1418;; Πρώτη φορά το βλέπω αυτό

[sxbcl]

Επειδή πρώτη φορά το συναντάω αυτό, έκατσα και το έψαξα αρκετά.
Σύγκρινα αυτό το VPN με ένα άλλο.
Από λάθος έγραψα παραπάνω ότι το μέγιστο πακέτο στο άλλο VPN είναι 1464.
Το σωστό είναι ότι σε ping προς το VPN δίκτυο που δουλεύει σωστά το μέγιστο πακέτο είναι 1410, ενώ σε αυτό που δε δουλεύει σωστά είναι 1390.
Άρα, λέω εγώ τώρα μπακαλίστικα, 1410 + 28 (ICMP overhead) + 54 (IPsec overhead)=1492 bytes
Ενώ σε αυτό που δε δουλεύει σωστά, 1390 + 28 (ICMP overhead) + 54 (IPsec overhead)=1472 bytes
Καταλήγω επομένως στο συμπέρασμα ότι είτε το speedport είναι ρυθμισμένη η PPPoE σύνδεσή του με MTU 1472, πράγμα που νομίζω είχα ελέγξει και δεν ισχύει, ή κάτι γίνεται πιο πίσω στο DSLAM ή κάπου αλλού

[BillyVan]

Καπου το εχασα γιατι στην αρχη λεγαμε για πιθανο προβλημα στο ZTE 1600.

Διαβαζω ομως για Speedport τωρα.

Τελικα αλλαξες modem και συνεχιζουν τα προβληματα?

[sxbcl]

Καπου το εχασα γιατι στην αρχη λεγαμε για πιθανο προβλημα στο ZTE 1600.

Διαβαζω ομως για Speedport τωρα.

Τελικα αλλαξες modem και συνεχιζουν τα προβληματα?

Συγγνώμη έχεις δίκιο, το Η1600 έχω ακόμη, αυτό εννοούσα.
Η δύναμη της συνήθειας....

- - - Updated - - -

Χθες μου έτυχε περίπτωση σε πελάτη που είχε 2 σημεία και έστησα 2 ΜΤ για IPsec VPN.
Στο ένα σημείο είχε router Oxygen και στο άλλο ΖΤΕ Η1600. Αντιμετώπισα ακριβώς το ίδιο θέμα.
Από το σημείο με το H1600 ping, traceroute δουλεύει, όπως επίσης ανοίγω π.χ. το web interface του MT στο σημείο με το Η1600.
Από το σημείο με το Oxygen ping, traceroute δουλεύει, αλλά δεν άνοιγε κανένα web interface στη μεριά του H1600, πόρτα 80 ή 443 δηλαδή.

Έκανα και εδώ αυτό που ανέφερα παραπάνω με την αλλαγή του mtu στο forward chain του MT στο σημείο με το H1600 και δουλεύει.

[BillyVan]

OK αρα εντοπιστηκε το προβλημα.

Τωρα που γραφω μου ηρθε στο μυαλο κατι σχετικο που αντιμετωπιζω.

Μου εχει τυχει σε μεγαλο δικτυο με vpn (100 περιπου clients)

Μπαινω με vpn στον σερβερ και δεν μου εμφανιζει τιποτε...κενο το winbox.

Αλλαζω mtu στο pptp ή l2tp και μου τα εμφανιζει κανονικα.

Ομοιως και στους clients.

Η αληθεια ειναι οτι δεν εχω εντοπισει το ποσο ακριβως πρεπει να ειναι το mtu σε τετοιες περιπτωσεις και παω

λιγο μπακαλιστικα.

Πχ τωρα εχει mtu 1300 στο pptp και μου το κανει καπου καπου να ειναι κενο.

Σε αλλη περιπτωση μου επαιζει μια χαρα με 1380 και σε αλλη με 1450.

Πως μπορω να το υπολογιζω σωστα?

Εχω failover απο 4G και νομιζω οταν τουμπαρει κι εκει κανει το ιδιο.

[dmitspan]

Είχα site to site L2TP/IPSec μεταξύ mt σπιτιού και δουλειάς (από το σπίτι προς τη δουλειά). Σήμερα έγινε αναβάθμιση στη δουλειά από 6.49 σε 7.7.
Σταμάτησε να δουλεύει. Το connection δείχνει ότι έχει γίνει, αλλά δεν υπάρχει καμία κίνηση. Όλα τα ping επιστρέφουν timeout.
Απενεργοποίησα το firewall αλλά δεν άλλαξε κάτι. Δεν έχω πρόσβαση αυτή τη στιγμή στο mt του σπιτιού, θα δω το απόγευμα αν μπορώ να αλλάξω κάτι από εκεί.

[deniSun]

Είχα site to site L2TP/IPSec μεταξύ mt σπιτιού και δουλειάς (από το σπίτι προς τη δουλειά). Σήμερα έγινε αναβάθμιση στη δουλειά από 6.49 σε 7.7.
Σταμάτησε να δουλεύει. Το connection δείχνει ότι έχει γίνει, αλλά δεν υπάρχει καμία κίνηση. Όλα τα ping επιστρέφουν timeout.
Απενεργοποίησα το firewall αλλά δεν άλλαξε κάτι. Δεν έχω πρόσβαση αυτή τη στιγμή στο mt του σπιτιού, θα δω το απόγευμα αν μπορώ να αλλάξω κάτι από εκεί.

Δουλειά και σπίτι έχουν ρούτερ ΜΤ;