ich versuche bereits seit einigen Monaten immer mal wieder ein Problem zu lösen, was aber keine große Priorität hat, da es bisher nur mich stört und ich weiß, wie ich es umgehen kann.
Ich habe einen 1900EF (bis vor kurzem 10.72SU2, mittlerweile 10.72RU5), der unsere VPN-Verbindungen zu externen Dienstleistern bedient. Früher hatte ich noch einen weiteren 1900EF, der nur die VPN-Verbindungen von unseren eigenen Nichthandelsaußenstellen terminiert hat. Da beide Kisten mit ihrer Aufgabe deutlich unterfordert waren, habe ich beide zusammengefasst.
Also auf dem einen 1900EF ist jetzt beides zusammengefasst und via ARF getrennt. VPN von Externen auf Tag 431, VPN von Internen auf Tag 430. Der Traffic geht dann VLAN-separiert über ein LACP-Bundle zur übergeordneten Firewall. Die ARF-Kontexte lernen die jeweils anderen Verbindungen via OSPF über die Firewall. Ist in der Routingtabelle auch korrekt abgebildet.
Soweit klingt es erstmal gut und funktioniert, bis auf eine Sache: Wenn eine interne Außenstelle auf einen externen Dienstleister zugreifen will.
Ein traceroute vom Router einer Außenstelle zum externen Dienstleister endet in einer Schleife zwischen Firewall und 1900EF (.74 ist die IP des 1900EF Tag 430, .78 die des 1900EF Tag 431 und die .73 die der externen Firewall)
Code: Alles auswählen
root@RTR_BUERO_BERLIN:/
> ping -r 10.213.10.57
0 Traceroute 172.21.42.74 seq.no=0 time=17.960 ms
1 Traceroute 172.21.42.73 seq.no=1 time=17.192 ms
2 Traceroute 172.21.42.78 seq.no=2 time=17.674 ms
3 Traceroute 172.21.42.73 seq.no=3 time=17.917 ms
4 Traceroute 172.21.42.78 seq.no=4 time=17.423 ms
5 Traceroute 172.21.42.73 seq.no=5 time=17.929 ms
6 Traceroute 172.21.42.78 seq.no=6 time=17.436 ms
7 Traceroute 172.21.42.73 seq.no=7 time=17.927 ms
8 Traceroute 172.21.42.78 seq.no=8 time=17.678 ms
9 Traceroute 172.21.42.73 seq.no=9 time=17.182 ms
10 Traceroute 172.21.42.78 seq.no=10 time=17.672 ms
11 Traceroute 172.21.42.73 seq.no=11 time=18.705 ms
12 Traceroute 172.21.42.78 seq.no=12 time=17.431 ms
13 Traceroute 172.21.42.73 seq.no=13 time=17.185 ms
14 Traceroute 172.21.42.78 seq.no=14 time=17.933 ms
15 Traceroute 172.21.42.73 seq.no=15 time=17.936 ms
16 Traceroute 172.21.42.78 seq.no=16 time=17.941 ms
17 Traceroute 172.21.42.73 seq.no=17 time=17.935 ms
18 Traceroute 172.21.42.78 seq.no=18 time=17.936 ms
19 Traceroute 172.21.42.73 seq.no=19 time=18.196 ms
20 Traceroute 172.21.42.78 seq.no=20 time=18.440 ms
---10.213.10.57 ping statistic---
56 Bytes Data, 22 Packets transmitted, 21 Packets received, 4% loss
root@RTR_BUERO_BERLIN:/
Jetzt habe ich mal den Tracer angeworfen und habe dieses hier herausbekommen:
Code: Alles auswählen
[IP-Router] 2023/11/26 13:42:34,484 Devicetime: 2023/11/26 13:42:34,008
IP-Router Rx (BUNDLE-1, VPN_EXTERN, RtgTag: 430):
DstIP: 10.213.10.55, SrcIP: 10.8.41.1, Len: 84, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0x0070, seq: 0x0000
Route: 172.21.42.73, BUNDLE-1 Tx (VPN_INTERN)
Code: Alles auswählen
BUNDLE-1, VPN_EXTERN, RtgTag: 431
Code: Alles auswählen
Route: WAN Tx (VPN_HOSTER)
So sieht das gleiche aus, wenn ich nicht von einer Außenstelle über den 1900EF reinkomme, sondern einen Host an einer anderen Stelle im Netz nutze:
Code: Alles auswählen
[IP-Router] 2023/11/26 14:07:27,975 Devicetime: 2023/11/26 14:07:27,438
IP-Router Rx (BUNDLE-1, VPN_EXTERN, RtgTag: 431):
DstIP: 10.213.10.57, SrcIP: 172.21.30.240, Len: 60, DSCP: CS0/BE (0x00), ECT: 0, CE: 0
Prot.: ICMP (1), echo request, id: 0x0001, seq: 0x04fd
Route: WAN Tx (VPN_HOSTER)
Der externe Router ist kein LANCOM, kann also mit ARF-Tags nicht umgehen und mein Verständnis ist, dass diese den Router nicht verlassen sollten.