The NTP Pool is a volunteer organization that provides time synchronization service to hundreds of millions of computers worldwide. A typical client might query a particular NTP Pool server ~10-60 times/hour. Wikipedia lists some abusive clients that far exceeded the normal rate. This wastes NTP server resources, may interfere with other clients, and can trigger DDoS protections. In late 2019, a software update made some FortiGate firewalls very unfriendly to the NTP Pool.
Fortinet is a multinational corporation that produces computer security devices, including the FortiGate firewall. The firewall product documentation describes how to use the NTP Pool for time synchronization, e.g., by using:
DNS will resolve 0.europe.pool.ntp.org into one of the hundreds of NTP servers in the NTP Pool. Let’s say that at firewall startup 1.2.3.4 was the NTP server selected by DNS. What happens if sometime later the administrator of 1.2.3.4 decides to stop participating in the NTP Pool and shuts down the public NTP service? We were told that older FortiGate NTP software did not handle that condition gracefully. A software update, FortiOS 6.2.3, was issued in December 2019 that periodically reissued the DNS lookup. In our example, if 0.europe.pool.ntp.org no longer resolved into 1.2.3.4 some re-initialization was done by the new software. That new code had a serious flaw. Bursts of NTP requests with rates that sometimes exceeded 20,000/sec were sent for up to 10 seconds duration. As DNS resolution changed, which is common for the NTP pools, a single FortiGate firewall would send bursts to different NTP pool servers.
A burst from a single FortiGate firewall is shown below
In early 2020, NTP pool operators noticed these distinctive bursts. They sometimes represented over 20 % of the total NTP traffic on a single server! Diagnostic work by several NTP Pool volunteers identified FortiGate firewalls as the source of these bursts. In April 2020, we contacted Fortinet support who acknowledged the bug and said that the next software release containing a fix would soon be deployed. However, the new software had unrelated bugs that prevented it from being widely deployed. On August 22, 2020, FortiOS 6.2.5 was released to eliminate the bursts.
The fix for FortiGate administrators is simple:
Do not use FortiOS release 6.2.3, or
if using release 6.2.3, do not use the NTP Pool.
FortiGate notified a handful of customers of the problem. However, as of this writing (November 2020), the NTP Pool is still receiving frequent NTP bursts from hundreds (at least) of FortiGate firewalls. While Fortinet was responsive in email and phone discussions, on the whole, their corrective actions were disappointing. Hopefully, FortiGate administrators will read this note and take corrective action as appropriate.
The diagnostic work was done by Miroslav Lichvar, Hal Murray, and Steven Sommars with contributions from several other NTP Pool volunteers.
More than 6 years ago (!) I published a tutorial on how to set up an IPsec VPN tunnel between a Palo Alto Networks firewall and a Cisco ASA. As time flies by, ASA is now able to terminate route-based VPN tunnels (which is great!), we have IKEv2 running everywhere and enhanced security proposals. Hence, it’s time for an update:
This is my setup for this tutorial: (Yes, public IPv4 addresses behind the Palo.)
I am using a Palo Alto Networks PA-220 with PAN-OS 10.0.2 and a Cisco ASA 5515 with version 9.12(3)12 and ASDM 7.14(1). These are the VPN parameters:
Route-based VPN, that is: numbered tunnel interface and real route entries for the network(s) to the other side. But no proxy-IDs aka traffic selection aka crypto map. Thank goodness for that.
IKEv2 (no distinction anymore between main or aggressive mode as with IKEv1)
PSK: 30 chars alphanumeric, generated with a password generator! (ref)
IKE crypto/policies:
Diffie-Hellman group 20
AES-256-CBC (because Palo has no -GCM here, don’t know why)
SHA-512 (you could use SHA-256 if you like)
8 hours
IPsec crypto/proposals/transform sets:
AES-256-GCM (here it is GCM)
SHA-512 (again, you can use SHA-256 as well)
Diffie-Hellman group 20
1 hour
Tunnel monitor on the Palo to ping the tunnel interface of the ASA constantly – this keeps the tunnel up and running.
Since there is the “intrazone-default allow” policy on the Palo, you don’t need an explicit policy for allowing the VPN connection from “untrust to untrust”. If you have an own explicit deny any policy at the end of your policy set, you need an explicit allow policy for “ike” and “ipsec-esp”.
No NAT between the internal networks (of course not ;))!
Palo Alto NGFW
Everything is done via the GUI:
Cisco ASA
You can do the configuration either via the ASDM “GUI”:
or through CLI commands (of course you have to change the IPv4 addresses, the PSK, the number of the VTI or the crypto ikev2 policy, etc.) Furthermore, the ACL is not listed:
On the Palo you can see these information in the GUI:
Or you can use some of these CLI commands
showvpn{ike-sa|ipsec-sa|gateway|tunnel|flow} :
weberjoh@pa> show vpn ike-sa gateway asa
There is no IKEv1 phase-1 SA found.
There is no IKEv1 phase-2 SA found.
IKEv2 SAs
Gateway ID Peer-Address Gateway Name Role SN Algorithm Established Expiration Xt Child ST
---------- ------------ ------------ ---- -- --------- ----------- ---------- -- ----- --
2 185.23.77.7 asa Init 90 PSK/DH20/A256/SHA512 Oct.07 14:23:04 Oct.07 22:23:04 0 1 Established
IKEv2 IPSec Child SAs
Gateway Name TnID Tunnel ID Parent Role SPI(in) SPI(out) MsgID ST
------------ ---- ------ -- ------ ---- ------- -------- ----- --
asa 4 asa 390604 90 Init D8EF49DF CF6D9FC7 00000793 Mature
Show IKEv2 SA: Total 2 gateways found. 1 ike sa found.
weberjoh@pa>
weberjoh@pa>
weberjoh@pa> show vpn ipsec-sa tunnel asa
GwID/client IP TnID Peer-Address Tunnel(Gateway) Algorithm SPI(in) SPI(out) life(Sec/KB) remain-time(Sec)
-------------- ---- ------------ --------------- --------- ------- -------- ------------ ----------------
2 4 185.23.77.7 asa(asa) ESP/G256/ D8EF49DF CF6D9FC7 3600/Unlimited 1185
Show IPSec SA: Total 1 tunnels found. 1 ipsec sa found.
weberjoh@pa>
weberjoh@pa>
weberjoh@pa> show vpn gateway name asa
GwID Name Peer-Address/ID Local Address/ID Protocol Proposals
---- ---- --------------- ---------------- -------- ---------
2 asa 185.23.77.7 193.24.227.9(ipaddr:193.24.227 IKEv2 [PSK][DH20][AES256][SHA512]28800-sec
IKEv2 cookie will be enabled if the number of half opened SA is over 500
IKEv2 max allowed half opened SA: 65535
weberjoh@pa>
weberjoh@pa>
weberjoh@pa> show vpn tunnel name asa
TnID Name Gateway Local Proxy IP Ptl:Port Remote Proxy IP Ptl:Port Proposals
---- ---- ------- -------------- -------- --------------- -------- ---------
4 asa asa 0.0.0.0/0 0:0 0.0.0.0/0 0:0 ESP tunl [DH20][AES256-GCM16][SHA512] 3600-sec 0-kb
Show IPSec tunnel config: Total 1 tunnels found.
weberjoh@pa>
weberjoh@pa>
weberjoh@pa> show vpn flow name asa
tunnel asa
id: 4
type: IPSec
gateway id: 2
local ip: 193.24.227.9
peer ip: 185.23.77.7
inner interface: tunnel.4
outer interface: ethernet1/1
state: active
session: 62916
tunnel mtu: 1432
soft lifetime: 3494
hard lifetime: 3600
lifetime remain: 1075 sec
lifesize remain: N/A
latest rekey: 2525 seconds ago
monitor: on
monitor status: up
monitor dest: 10.1.227.2
monitor interval: 3 seconds
monitor threshold: 5 probe losses
monitor bitmap: 11111
monitor packets sent: 318909
monitor packets recv: 318905
monitor packets seen: 0
monitor packets reply:0
en/decap context: 967
local spi: D8EF49DF
remote spi: CF6D9FC7
key type: auto key
protocol: ESP
auth algorithm: NULL
enc algorithm: AES256GCM16
traffic selector:
protocol: 0
local ip range: 0.0.0.0 - 255.255.255.255
local port range: 0 - 65535
remote ip range: 0.0.0.0 - 255.255.255.255
remote port range: 0 - 65535
anti replay check: yes
copy tos: no
enable gre encap: no
initiator: yes
authentication errors: 0
decryption errors: 0
inner packet warnings: 0
replay packets: 0
packets received
when lifetime expired:0
when lifesize expired:0
sending sequence: 1224
receive sequence: 1215
encap packets: 324665
decap packets: 324016
encap bytes: 38722120
decap bytes: 36924228
key acquire requests: 14
owner state: 0
owner cpuid: s1dp0
ownership: 1
On the ASA these are the GUI information. Note the proxy-IDs aka “Local Addr. / Subnet Mask / Protocol / Port” which is “0.0.0.0/0.0.0.0/0/0” which is absolutely correct, due to the usage of a route-based VPN. Nice!
And here are some CLI commands as well. Note that you have a valid static route to the other side, which is great!
asa# show crypto ikev2 sa detail
IKEv2 SAs:
Session-id:14, Status:UP-ACTIVE, IKE count:1, CHILD count:1
Tunnel-id Local Remote Status Role
1064907123 185.23.77.7/500 193.24.227.9/500 READY RESPONDER
Encr: AES-CBC, keysize: 256, Hash: SHA512, DH Grp:20, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 28800/19548 sec
Session-id: 14
Status Description: Negotiation done
Local spi: 7717F9B4C00B4B1F Remote spi: 9C74DCB332A67F2C
Local id: 185.23.77.7
Remote id: 193.24.227.9
Local req mess id: 3 Remote req mess id: 3911
Local next mess id: 3 Remote next mess id: 3911
Local req queued: 3 Remote req queued: 3911
Local window: 1 Remote window: 1
DPD configured for 10 seconds, retry 2
NAT-T is not detected
IKEv2 Fragmentation Configured MTU: 576 bytes, Overhead: 28 bytes, Effective MTU: 548 bytes
Child sa: local selector 0.0.0.0/0 - 255.255.255.255/65535
remote selector 0.0.0.0/0 - 255.255.255.255/65535
ESP spi in/out: 0x608b2209/0xe8a8c944
AH spi in/out: 0x0/0x0
CPI in/out: 0x0/0x0
Encr: AES-GCM, keysize: 256, esp_hmac: N/A
ah_hmac: None, comp: IPCOMP_NONE, mode tunnel
Parent SA Extended Status:
Delete in progress: FALSE
Marked for delete: FALSE
asa#
asa#
asa# show crypto ipsec sa peer 193.24.227.9 detail
peer address: 193.24.227.9
Crypto map tag: __vti-crypto-map-6-0-2, seq num: 65280, local addr: 185.23.77.7
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer: 193.24.227.9
#pkts encaps: 35910, #pkts encrypt: 35910, #pkts digest: 35910
#pkts decaps: 23421, #pkts decrypt: 23421, #pkts verify: 23421
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 35910, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#TFC rcvd: 0, #TFC sent: 0
#Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
#pkts no sa (send): 0, #pkts invalid sa (rcv): 0
#pkts encaps failed (send): 0, #pkts decaps failed (rcv): 0
#pkts invalid prot (rcv): 0, #pkts verify failed: 0
#pkts invalid identity (rcv): 0, #pkts invalid len (rcv): 3974389472
#pkts invalid pad (rcv): 0,
#pkts invalid ip version (send): 0, #pkts invalid ip version (rcv): 0
#pkts invalid len (send): 0, #pkts invalid len (rcv): 0
#pkts invalid ctx (send): 0, #pkts invalid ctx (rcv): 0
#pkts invalid ifc (send): 0, #pkts invalid ifc (rcv): 0
#pkts failed (send): 0, #pkts failed (rcv): 0
#pkts replay rollover (send): 0, #pkts replay rollover (rcv): 0
#pkts replay failed (rcv): 0
#pkts min mtu frag failed (send): 0, #pkts bad frag offset (rcv): 0
#pkts internal err (send): 0, #pkts internal err (rcv): 0
local crypto endpt.: 185.23.77.7/500, remote crypto endpt.: 193.24.227.9/500
path mtu 1500, ipsec overhead 55(36), media mtu 1500
PMTU time remaining (sec): 0, DF policy: copy-df
ICMP error validation: disabled, TFC packets: disabled
current outbound spi: E8A8C944
current inbound spi : 608B2209
inbound esp sas:
spi: 0x608B2209 (1619730953)
SA State: active
transform: esp-aes-gcm-256 esp-null-hmac no compression
in use settings ={L2L, Tunnel, PFS Group 20, IKEv2, VTI, }
slot: 0, conn_id: 41, crypto-map: __vti-crypto-map-6-0-2
sa timing: remaining key lifetime (kB/sec): (3962843/2426)
IV size: 8 bytes
replay detection support: Y
Anti replay bitmap:
0xFFFFFFFF 0xFFFFFFFF
outbound esp sas:
spi: 0xE8A8C944 (3903375684)
SA State: active
transform: esp-aes-gcm-256 esp-null-hmac no compression
in use settings ={L2L, Tunnel, PFS Group 20, IKEv2, VTI, }
slot: 0, conn_id: 41, crypto-map: __vti-crypto-map-6-0-2
sa timing: remaining key lifetime (kB/sec): (3916764/2426)
IV size: 8 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
asa#
asa#
asa# show route static
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, V - VPN
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, + - replicated route
Gateway of last resort is 185.23.77.1 to network 0.0.0.0
S* 0.0.0.0 0.0.0.0 [1/0] via 185.23.77.1, outside
S 193.24.227.224 255.255.255.224 [1/0] via 10.1.227.1, pa
More than 6 years ago (!) I published a tutorial on how to set up an IPsec VPN tunnel between a FortiGate firewall and a Cisco ASA. As time flies by, ASA is now able to terminate route-based VPN tunnels (which is great!), we have IKEv2 running everywhere and enhanced security proposals. Hence, it’s time for an update:
This is my setup for this tutorial: (Yes, public IPv4 addresses behind the Forti.)
I am using a Fortinet FortiWiFi FWF-61E with FortiOS v6.2.5 build1142 (GA) and a Cisco ASA 5515 with version 9.12(3)12 and ASDM 7.14(1). These are the VPN parameters:
Route-based VPN, that is: numbered tunnel interface and real route entries for the network(s) to the other side. But no proxy-IDs aka traffic selection aka crypto map. Thank goodness for that.
The tunnel interface on the Forti is added during the VPN setup automatically. However, you have to set the IP address on the tunnel interface manually after that. The static route on the ASA needs an IP address as the gateway.
IKEv2 (no distinction anymore between main or aggressive mode as with IKEv1)
PSK: 30 chars alphanumeric, generated with a password generator! (ref)
IKE crypto/policies:
Diffie-Hellman group 21
AES-256-GCM
SHA-512 (you could use SHA-256 if you like)
8 hours
IPsec crypto/proposals/transform sets:
AES-256-GCM
SHA-512 (again, you can use SHA-256 as well)
Diffie-Hellman group 21
1 hour
No NAT between the internal networks (of course not ;))!
FortiGate
You can do the configuration through the GUI:
or through the CLI: (incl. the zone commands <- can be omitted if you aren’t using zones)
config system interface
edit "asa"
set vdom "root"
set ip 10.1.37.1 255.255.255.255
set allowaccess ping
set type tunnel
set remote-ip 10.1.37.2 255.255.255.252
set interface "wan1"
next
end
config system zone
edit "s2s-vpns"
set interface "asa"
next
end
config vpn ipsec phase1-interface
edit "asa"
set interface "wan1"
set ike-version 2
set keylife 28800
set peertype any
set net-device enable
set proposal aes256gcm-prfsha512
set dhgrp 21
set nattraversal disable
set remote-gw 185.23.77.7
set psksecret ThisIsThePreSharedKey
next
end
config vpn ipsec phase2-interface
edit "asa"
set phase1name "asa"
set proposal aes256gcm
set dhgrp 21
set keylifeseconds 3600
next
end
config router static
edit 5
set dst 172.16.37.0 255.255.255.0
set device "asa"
next
end
Cisco ASA
Same on the ASA, either via the “GUI”:
or via classical CLI commands: (The ACL is omitted.)
The other day I was searching for a trace file with a decent protocol mix that could be used to introduce a few colleagues to Wireshark. This brought me to Johannes Weber and his Ultimate PCAP.
To get a first impression of a trace file I used Wireshark’s protocol hierarchy – and boy, that’s a lot of protocols. This was not exactly what I was looking for: This single trace file holds snippets from 2014 to 2020 with a myriad of protocols and IP networks. Unfortunately, it’s nothing like the protocol mix found in a network analysis project.
Nevertheless, the trace file caught my interest as a long time Wireshark user. After nearly 20 years of network analysis, I had my own collection of traces with a few odd frames. To my big surprise, I had recorded a few protocols that are not yet part of the Ultimate PCAP.
So here is my small contribution to this collection:
RARP – The Reverse Address Resolution Protocol
Today we use DHCP for dynamic IP address assignment. DHCP relay servers keep the number of DHCP servers to a minimum. You might remember that DHCP is an improvement over the BOOTP protocol, with which it shares the UDP port numbers.
Fun fact: Back in the days, Wireshark used the display filter bootp to identify either BOOTP or DHCP packets. Wireshark 3.0 introduced the new display filter dhcp and deprecated the bootp filter.
RARP, even older than BOOTP, is a layer 2 protocol that shares its data structure with the well-known ARP protocol. A host can (or could) request its own IP address. BOOTP, running on IP, would also deliver more details like the IP address for the default gateway.
Please note that RARP is identified by the Ether type 0x8035. Otherwise, it’s looking pretty much like an ARP frame (you might remember that ARP uses Ether type 0x0806).
The vendor ID suggests that this frame was transmitted by a network printer. I often found the most amusing frames coming from network printers. That is if you are into that type of humor…
ARP with a SNAP header
Another oddball in my collection is an ARP packet that is using a SNAP header:
Please note that Wireshark just shows the protocol ARP in the packet list. Usually, the source MAC address is followed by the Ether type 0x0806, just as the RARP frame is identified by the Ether type 0x8035.
The ethernet header consists of three parts:
Destination MAC address
Source MAC address
Type / Length
The third part is either a type field or a length field, which can be quite confusing. If this value is at least 0x0600 (or 1536 decimal) these two bytes hold an Ethertype. (Refer: IEEE 802 Numbers) Notice how Wireshark decodes the RARP value of 0x8035 as “Type”.
A value of 0x05ff (1535 decimal) or smaller indicates that the two bytes indicate the frame length. This would be 36 byte in the previous screenshot.
Here is a marvel of the type / length field: Over the last decades an incredible number of network protocols were invented. A good part of them was forgotten or superseded by newer, more efficient protocols. A two-byte field would only support 65,536 different network protocols. The smart heads behind Ethernet sacrificed 1,536 of them for a lot flexibility. If the type / length field is smaller than 0x0600 it is considered to be a frame length followed by yet another header, the LLC (Logical Link Control). In this much bigger data structure, a vastly larger number of protocols can be implemented.
I admire the guys who invented Ethernet and build a protocol that held firm in a fast-moving industry for 40 years.
Nowadays the SNAP is mostly used for plain L2 protocols like STP or DTP. ARP is usually identified by an Ethertype, although it is an L2 protocol. Obviously, a few devices still support ARP over LLC. Microsoft has published an article on the inner workings of the TCP/IP implementation of Windows XP. Here is a screenshot from the web page:
If you take a good look at the trace file you will notice that the ARP frames here are not from a Windows system. (Hint: The same MAC address is used for CDP. Also, the ICMP echo requests (“ping”) holds a payload that is pointing to a Cisco device.)
Cisco supports ARP with SNAP encapsulation. Here is one of many pages from the Cisco website:
HDLC over L2TP over IP over MPLS
Johannes, being a keen observer and connoisseur of trace files, also found another interesting detail in my trace file: A L2 VPN tunnel:
This tunnel is the result of a VPLS connection that I had configured in my router lab. VPLS is a technology that can form an Ethernet link between two sites. The full protocol stack will be revealed when we instruct Wireshark to decode the data part as Ethernet: Right-click on the last line of the protocol decode where it says “Data (72 bytes)” and select Decode As …
Now change the protocol to Ethernet, click OK and look what happens to the protocol decode:
The L2TP protocol itself has some control messages as well:
To filter for these HDLC packets you have to use “chdlc”, since it is Cisco HDLC (cHDLC) that is used here.
MPLS & LDP
MPLS stands for Multiprotocol Label Switching, a technology designed for internet service providers and corporate networks of similar size. The other day I picked up a great explanation of MPLS in one sentence: Like a VLAN tag allows for multiple virtual LANs in one local network, the MPLS label allows for multiple virtual WANs in one wide area network.
As seen in the screenshot above, the router inserts a small header between the Ethernet and the IP Header if a packet is forwarded through MPLS. The receiving node will make a forwarding decision based on the label that is found inside the MPLS header. Looking up a label is much faster than a lookup in the routing table.
LDP stands for Label Distribution Protocol. You might guess that it is used between MPLS-enabled routers to inform the remote end how to forward packets marked with a label. Besides “Hello” packets there are initialization, keep alive, and especially “Label Mapping Message” packets. LDP runs on UDP port 646 (discovery) and TCP port 646 (session). As always, you can use “ldp” as the display filter which only shows the mere LDP packets. In case you’re interested in the whole TCP session, you have to use “tcp.port eq 646” or the like. The following screenshot only shows LDP packets without the TCP overhead:
I am constantly trying to add more protocols to the Ultimate PCAP. Hence I used some time in my (old) Cisco lab to configure and capture the following protocols: IS-IS, GLBP, and VRRP. And since Alexis La Goutte sent me some CAPWAP traffic, this protocol is also added. All packets are now found in another update of the Ultimate PCAP. Here are some details:
Lab
This was my lab for those captures:
IS-IS
Haha, to be honest, I have not worked with the Integrated Intermediate System to Intermediate System routing protocol anytime in my life. ;) I just used Google and some tutorials to configure it on routers R1, R4, and R5. The goal was to propagate the default route from R1 to R4 & R5, and the networks (IPv6 and legacy IP) from VLAN 42 to R1.
I captured between R1 and the switch. Right before the capture, I removed the cable from R4 gi0/0, while I plugged it in again during the capture. You can use “isis” as the display filter in Wireshark. This “Integrated IS-IS” is neither a TCP/UDP nor an IP protocol. Yep, no IP addresses here. Hence Wireshark displays the source/destination MAC addresses of the Ethernet frames:
Here are my configs from the three involved routers:
########## R1 ##########
interface FastEthernet0/1
ip address 172.16.9.1 255.255.255.0
ip router isis
ip nat inside
ip virtual-reassembly in
duplex auto
speed auto
ipv6 address 2001:470:1F15:F61::1/64
ipv6 router isis
!
router isis
net 49.0001.0000.0000.0001.00
log-adjacency-changes
default-information originate
!
address-family ipv6
default-information originate
exit-address-family
!
########## R4 ##########
interface GigabitEthernet0/0
ip address 172.16.9.4 255.255.255.0
ip router isis
duplex auto
speed auto
ipv6 address 2001:470:1F15:F61::4/64
ipv6 router isis
!
interface GigabitEthernet0/1
ip address 192.168.42.4 255.255.255.0
glbp 42 ip 192.168.42.1
duplex auto
speed auto
ipv6 address 2001:470:7FEB::4/64
!
router isis
net 49.0001.0000.0000.0004.00
log-adjacency-changes
passive-interface GigabitEthernet0/1
!
########## R5 ##########
interface GigabitEthernet0/0
ip address 172.16.9.5 255.255.255.0
ip router isis
duplex auto
speed auto
ipv6 address 2001:470:1F15:F61::5/64
ipv6 router isis
!
interface GigabitEthernet0/1
ip address 192.168.42.5 255.255.255.0
glbp 42 ip 192.168.42.1
duplex auto
speed auto
ipv6 address 2001:470:7FEB::5/64
!
router isis
net 49.0001.0000.0000.0005.00
log-adjacency-changes
passive-interface GigabitEthernet0/1
!
And some show commands from those three routers as well:
R1#show isis neighbors
System Id Type Interface IP Address State Holdtime Circuit Id
R4 L1 Fa0/1 172.16.9.4 UP 29 R5.01
R4 L2 Fa0/1 172.16.9.4 UP 22 R5.01
R5 L1 Fa0/1 172.16.9.5 UP 7 R5.01
R5 L2 Fa0/1 172.16.9.5 UP 7 R5.01
R1#
R1#
R1#show isis neighbors detail
System Id Type Interface IP Address State Holdtime Circuit Id
R4 L1 Fa0/1 172.16.9.4 UP 22 R5.01
Area Address(es): 49.0001
SNPA: 0015.626a.fef0
IPv6 Address(es): FE80::215:62FF:FE6A:FEF0
State Changed: 00:14:27
LAN Priority: 64
Format: Phase V
Remote TID: 0
Local TID: 0
Interface name: FastEthernet0/1
R4 L2 Fa0/1 172.16.9.4 UP 21 R5.01
Area Address(es): 49.0001
SNPA: 0015.626a.fef0
IPv6 Address(es): FE80::215:62FF:FE6A:FEF0
State Changed: 00:14:26
LAN Priority: 64
Format: Phase V
Remote TID: 0
Local TID: 0
Interface name: FastEthernet0/1
R5 L1 Fa0/1 172.16.9.5 UP 7 R5.01
Area Address(es): 49.0001
SNPA: 0025.4560.17c0
IPv6 Address(es): FE80::225:45FF:FE60:17C0
State Changed: 00:14:17
LAN Priority: 64
Format: Phase V
Remote TID: 0
Local TID: 0
Interface name: FastEthernet0/1
R5 L2 Fa0/1 172.16.9.5 UP 8 R5.01
Area Address(es): 49.0001
SNPA: 0025.4560.17c0
IPv6 Address(es): FE80::225:45FF:FE60:17C0
State Changed: 00:14:18
LAN Priority: 64
Format: Phase V
Remote TID: 0
Local TID: 0
Interface name: FastEthernet0/1
R1#
R1#
R1#show isis database
IS-IS Level-1 Link State Database:
LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
R1.00-00 * 0x00000019 0xFB26 1078 0/0/0
R1.01-00 * 0x00000004 0xEB0B 0 (329) 0/0/0
R4.00-00 0x00000018 0xB859 1078 0/0/0
R5.00-00 0x00000014 0x1EF3 624 0/0/0
R5.01-00 0x00000015 0xA303 1095 0/0/0
IS-IS Level-2 Link State Database:
LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
R1.00-00 * 0x00000019 0xB851 442 0/0/0
R1.01-00 * 0x00000003 0xED0A 0 (328) 0/0/0
R4.00-00 0x00000013 0x3BDB 1119 0/0/0
R5.00-00 0x0000000D 0x8A8E 624 0/0/0
R5.01-00 0x0000000F 0x61D3 1041 0/0/0
R1#
R1#
R1#show isis database detail
IS-IS Level-1 Link State Database:
LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
R1.00-00 * 0x00000019 0xFB26 1070 0/0/0
Area Address: 49.0001
NLPID: 0xCC 0x8E
Hostname: R1
IP Address: 172.16.9.1
Metric: 10 IP 172.16.9.0 255.255.255.0
IPv6 Address: 2001:470:1F15:F61::1
Metric: 10 IPv6 2001:470:1F15:F61::/64
Metric: 10 IS R5.01
R1.01-00 * 0x00000004 0xEB0B 0 (321) 0/0/0
R4.00-00 0x00000018 0xB859 1070 0/0/0
Area Address: 49.0001
NLPID: 0xCC 0x8E
Hostname: R4
IP Address: 192.168.42.4
Metric: 10 IP 172.16.9.0 255.255.255.0
Metric: 0 IP 192.168.42.0 255.255.255.0
IPv6 Address: 2001:470:7FEB::4
Metric: 10 IPv6 2001:470:1F15:F61::/64
Metric: 0 IPv6 2001:470:7FEB::/64
Metric: 10 IS R5.01
R5.00-00 0x00000014 0x1EF3 616 0/0/0
Area Address: 49.0001
NLPID: 0xCC 0x8E
Hostname: R5
IP Address: 192.168.42.5
Metric: 10 IP 172.16.9.0 255.255.255.0
Metric: 0 IP 192.168.42.0 255.255.255.0
IPv6 Address: 2001:470:7FEB::5
Metric: 10 IPv6 2001:470:1F15:F61::/64
Metric: 0 IPv6 2001:470:7FEB::/64
Metric: 10 IS R5.01
R5.01-00 0x00000015 0xA303 1086 0/0/0
Metric: 0 IS R5.00
Metric: 0 IS R1.00
Metric: 0 IS R4.00
IS-IS Level-2 Link State Database:
LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
R1.00-00 * 0x00000019 0xB851 433 0/0/0
Area Address: 49.0001
NLPID: 0xCC 0x8E
Hostname: R1
IP Address: 172.16.9.1
IPv6 Address: 2001:470:1F15:F61::1
Metric: 10 IS R5.01
Metric: 0 IP 0.0.0.0 0.0.0.0
Metric: 10 IP 172.16.9.0 255.255.255.0
Metric: 10 IP 192.168.42.0 255.255.255.0
Metric: 0 IPv6 ::/0
Metric: 10 IPv6 2001:470:1F15:F61::/64
Metric: 10 IPv6 2001:470:7FEB::/64
R1.01-00 * 0x00000003 0xED0A 0 (319) 0/0/0
R4.00-00 0x00000013 0x3BDB 1110 0/0/0
Area Address: 49.0001
NLPID: 0xCC 0x8E
Hostname: R4
IP Address: 192.168.42.4
IPv6 Address: 2001:470:7FEB::4
Metric: 10 IS R5.01
Metric: 10 IP 172.16.9.0 255.255.255.0
Metric: 0 IP 192.168.42.0 255.255.255.0
Metric: 10 IPv6 2001:470:1F15:F61::/64
Metric: 0 IPv6 2001:470:7FEB::/64
R5.00-00 0x0000000D 0x8A8E 616 0/0/0
Area Address: 49.0001
NLPID: 0xCC 0x8E
Hostname: R5
IP Address: 192.168.42.5
IPv6 Address: 2001:470:7FEB::5
Metric: 10 IS R5.01
Metric: 10 IP 172.16.9.0 255.255.255.0
Metric: 0 IP 192.168.42.0 255.255.255.0
Metric: 10 IPv6 2001:470:1F15:F61::/64
Metric: 0 IPv6 2001:470:7FEB::/64
R5.01-00 0x0000000F 0x61D3 1033 0/0/0
Metric: 0 IS R5.00
Metric: 0 IS R1.00
Metric: 0 IS R4.00
R1#
R1#
R1#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is 193.24.225.1 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 193.24.225.1, FastEthernet0/0
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.16.9.0/24 is directly connected, FastEthernet0/1
L 172.16.9.1/32 is directly connected, FastEthernet0/1
i L1 192.168.42.0/24 [115/10] via 172.16.9.5, 00:06:22, FastEthernet0/1
[115/10] via 172.16.9.4, 00:06:22, FastEthernet0/1
193.24.225.0/24 is variably subnetted, 2 subnets, 2 masks
C 193.24.225.0/24 is directly connected, FastEthernet0/0
L 193.24.225.54/32 is directly connected, FastEthernet0/0
R1#
R1#
R1#show ipv6 route
IPv6 Routing Table - default - 7 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, HA - Home Agent, MR - Mobile Router, R - RIP
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
D - EIGRP, EX - EIGRP external, NM - NEMO, ND - Neighbor Discovery
l - LISP
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
S ::/0 [1/0]
via Tunnel0, directly connected
C 2001:470:1F14:F62::/64 [0/0]
via Tunnel0, directly connected
L 2001:470:1F14:F62::2/128 [0/0]
via Tunnel0, receive
C 2001:470:1F15:F61::/64 [0/0]
via FastEthernet0/1, directly connected
L 2001:470:1F15:F61::1/128 [0/0]
via FastEthernet0/1, receive
I1 2001:470:7FEB::/64 [115/10]
via FE80::225:45FF:FE60:17C0, FastEthernet0/1
via FE80::215:62FF:FE6A:FEF0, FastEthernet0/1
L FF00::/8 [0/0]
via Null0, receive
R1#
####################
R4#show isis neighbors
System Id Type Interface IP Address State Holdtime Circuit Id
R1 L1 Gi0/0 172.16.9.1 UP 29 R5.01
R1 L2 Gi0/0 172.16.9.1 UP 28 R5.01
R5 L1 Gi0/0 172.16.9.5 UP 9 R5.01
R5 L2 Gi0/0 172.16.9.5 UP 9 R5.01
R4#
R4#
R4#show isis neighbors detail
System Id Type Interface IP Address State Holdtime Circuit Id
R1 L1 Gi0/0 172.16.9.1 UP 24 R5.01
Area Address(es): 49.0001
SNPA: 001e.7a79.3f11
IPv6 Address(es): FE80::21E:7AFF:FE79:3F11
State Changed: 00:01:35
LAN Priority: 64
Format: Phase V
Remote TID: 0
Local TID: 0
Interface name: GigabitEthernet0/0
R1 L2 Gi0/0 172.16.9.1 UP 23 R5.01
Area Address(es): 49.0001
SNPA: 001e.7a79.3f11
IPv6 Address(es): FE80::21E:7AFF:FE79:3F11
State Changed: 00:01:34
LAN Priority: 64
Format: Phase V
Remote TID: 0
Local TID: 0
Interface name: GigabitEthernet0/0
R5 L1 Gi0/0 172.16.9.5 UP 9 R5.01
Area Address(es): 49.0001
SNPA: 0025.4560.17c0
IPv6 Address(es): FE80::225:45FF:FE60:17C0
State Changed: 00:01:35
LAN Priority: 64
Format: Phase V
Remote TID: 0
Local TID: 0
Interface name: GigabitEthernet0/0
R5 L2 Gi0/0 172.16.9.5 UP 8 R5.01
Area Address(es): 49.0001
SNPA: 0025.4560.17c0
IPv6 Address(es): FE80::225:45FF:FE60:17C0
State Changed: 00:01:34
LAN Priority: 64
Format: Phase V
Remote TID: 0
Local TID: 0
Interface name: GigabitEthernet0/0
R4#
R4#
R4#show isis topology
IS-IS TID 0 paths to level-1 routers
System Id Metric Next-Hop Interface SNPA
R1 10 R1 Gi0/0 001e.7a79.3f11
R4 --
R5 10 R5 Gi0/0 0025.4560.17c0
IS-IS TID 0 paths to level-2 routers
System Id Metric Next-Hop Interface SNPA
R1 10 R1 Gi0/0 001e.7a79.3f11
R4 --
R5 10 R5 Gi0/0 0025.4560.17c0
R4#
R4#
R4#show isis rib
IPv4 local RIB for IS-IS process
IPV4 unicast topology base (TID 0, TOPOID 0x0) =================
172.16.9.0/24
[115/L1/20] via 172.16.9.1(GigabitEthernet0/0), from 172.16.9.1, tag 0, LSP[8/9]
[115/L1/20] via 172.16.9.5(GigabitEthernet0/0), from 192.168.42.5, tag 0, LSP[7/12]
[115/L2/20] via 172.16.9.1(GigabitEthernet0/0), from 172.16.9.1, tag 0, LSP[6/10]
[115/L2/20] via 172.16.9.5(GigabitEthernet0/0), from 192.168.42.5, tag 0, LSP[5/12]
192.168.42.0/24
[115/L1/10] via 172.16.9.5(GigabitEthernet0/0), from 192.168.42.5, tag 0, LSP[7/12]
[115/L2/10] via 172.16.9.5(GigabitEthernet0/0), from 192.168.42.5, tag 0, LSP[5/12]
[115/L2/20] via 172.16.9.1(GigabitEthernet0/0), from 172.16.9.1, tag 0, LSP[6/10]
0.0.0.0/0
[115/L2/10] via 172.16.9.1(GigabitEthernet0/0), from 172.16.9.1, tag 0, LSP[6/10]
R4#
R4#
R4#show isis ipv6 rib
IS-IS IPv6 process , local RIB
2001:470:1F15:F61::/64
via FE80::21E:7AFF:FE79:3F11/GigabitEthernet0/0, type L1 metric 20 LSP [8/9]
via FE80::225:45FF:FE60:17C0/GigabitEthernet0/0, type L1 metric 20 LSP [7/C]
via FE80::21E:7AFF:FE79:3F11/GigabitEthernet0/0, type L2 metric 20 LSP [6/A]
via FE80::225:45FF:FE60:17C0/GigabitEthernet0/0, type L2 metric 20 LSP [5/C]
2001:470:7FEB::/64
via FE80::225:45FF:FE60:17C0/GigabitEthernet0/0, type L1 metric 10 LSP [7/C]
via FE80::225:45FF:FE60:17C0/GigabitEthernet0/0, type L2 metric 10 LSP [5/C]
via FE80::21E:7AFF:FE79:3F11/GigabitEthernet0/0, type L2 metric 20 LSP [6/A]
* ::/0
via FE80::21E:7AFF:FE79:3F11/GigabitEthernet0/0, type L2 metric 10 LSP [6/A]
R4#
R4#
R4#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is 172.16.9.1 to network 0.0.0.0
i*L2 0.0.0.0/0 [115/10] via 172.16.9.1, 00:05:56, GigabitEthernet0/0
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.16.9.0/24 is directly connected, GigabitEthernet0/0
L 172.16.9.4/32 is directly connected, GigabitEthernet0/0
192.168.42.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.42.0/24 is directly connected, GigabitEthernet0/1
L 192.168.42.4/32 is directly connected, GigabitEthernet0/1
R4#
R4#
R4#show ipv6 route
IPv6 Routing Table - default - 6 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, HA - Home Agent, MR - Mobile Router, R - RIP
I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
D - EIGRP, EX - EIGRP external, NM - NEMO, ND - Neighbor Discovery
l - LISP
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
I2 ::/0 [115/10]
via FE80::21E:7AFF:FE79:3F11, GigabitEthernet0/0
C 2001:470:1F15:F61::/64 [0/0]
via GigabitEthernet0/0, directly connected
L 2001:470:1F15:F61::4/128 [0/0]
via GigabitEthernet0/0, receive
C 2001:470:7FEB::/64 [0/0]
via GigabitEthernet0/1, directly connected
L 2001:470:7FEB::4/128 [0/0]
via GigabitEthernet0/1, receive
L FF00::/8 [0/0]
via Null0, receive
R4#
R4#
####################
R5#show isis neighbors
System Id Type Interface IP Address State Holdtime Circuit Id
R1 L1 Gi0/0 172.16.9.1 UP 23 R5.01
R1 L2 Gi0/0 172.16.9.1 UP 21 R5.01
R4 L1 Gi0/0 172.16.9.4 UP 29 R5.01
R4 L2 Gi0/0 172.16.9.4 UP 26 R5.01
R5#
R5#
R5#show isis database
IS-IS Level-1 Link State Database:
LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
R1.00-00 0x00000019 0xFB26 509 0/0/0
R4.00-00 0x0000001B 0xB25C 785 0/0/0
R5.00-00 * 0x00000015 0x1CF4 931 0/0/0
R5.01-00 * 0x00000017 0x9F05 784 0/0/0
IS-IS Level-2 Link State Database:
LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
R1.00-00 0x0000001A 0xB652 687 0/0/0
R4.00-00 0x00000017 0x33DF 785 0/0/0
R5.00-00 * 0x0000000E 0x888F 770 0/0/0
R5.01-00 * 0x00000011 0x5DD5 788 0/0/0
R5#
R5#
GLBP
I configured the Cisco proprietary first-hop redundancy protocol Gateway Load Balancing Protocol on routers R4 and R5 to have a redundant connection to the Internet from the network in which the Raspberry Pi resides. I captured right before the Raspberry Pi and performed the following steps:
started the capture
booted the Raspi
started pinging “netsec.blog” via v6 and v4
NOW I rebooted R4 in order to have some GLBP changes
Using “glbp” as the display filter you can see both sessions for each Internet protocol. (Don’t know why the red coloring rules from Wireshark for GLBP with IPv4 kicks in. To my mind, this shouldn’t be the case. Will discuss this later.)
These are the GLBP states before the reload of R4:
R4#show glbp brief
Interface Grp Fwd Pri State Address Active router Standby router
Gi0/1 42 - 100 Standby 192.168.42.1 192.168.42.5 local
Gi0/1 42 1 - Active 0007.b400.2a01 local -
Gi0/1 42 2 - Listen 0007.b400.2a02 192.168.42.5 -
Gi0/1 43 - 100 Standby FE80::7:B4FF:FE00:2B00
FE80::225:45FF:FE60:17C1
local
Gi0/1 43 1 - Active 0007.b400.2b01 local -
Gi0/1 43 2 - Listen 0007.b400.2b02 FE80::225:45FF:FE60:17C1
-
R5#show glbp brief
Interface Grp Fwd Pri State Address Active router Standby router
Gi0/1 42 - 100 Active 192.168.42.1 local 192.168.42.4
Gi0/1 42 1 - Listen 0007.b400.2a01 192.168.42.4 -
Gi0/1 42 2 - Active 0007.b400.2a02 local -
Gi0/1 43 - 100 Active FE80::7:B4FF:FE00:2B00
local FE80::215:62FF:FE6A:FEF1
Gi0/1 43 1 - Listen 0007.b400.2b01 FE80::215:62FF:FE6A:FEF1
-
Gi0/1 43 2 - Active 0007.b400.2b02 local -
Log messages from R5 during the reload of R4:
Nov 25 2020 16:44:07.986 UTC: %GLBP-6-FWDSTATECHANGE: GigabitEthernet0/1 Grp 42 Fwd 1 state Listen -> Active
Nov 25 2020 16:44:07.986 UTC: %GLBP-6-FWDSTATECHANGE: GigabitEthernet0/1 Grp 43 Fwd 1 state Listen -> Active
And after the reload:
Nov 25 2020 16:47:05.447 UTC: %GLBP-6-FWDSTATECHANGE: GigabitEthernet0/1 Grp 43 Fwd 1 state Active -> Listen
Nov 25 2020 16:47:08.551 UTC: %GLBP-6-FWDSTATECHANGE: GigabitEthernet0/1 Grp 42 Fwd 1 state Active -> Listen
Configuration and some show commands of both routers:
########## R4 ##########
interface GigabitEthernet0/1
ip address 192.168.42.4 255.255.255.0
glbp 42 ip 192.168.42.1
glbp 43 ipv6 autoconfig
glbp 43 authentication md5 key-string 7 022C0B53055539245E5D0C4853
duplex auto
speed auto
ipv6 address 2001:470:7FEB::4/64
!
R4#show glbp
GigabitEthernet0/1 - Group 42
State is Standby
1 state change, last state change 00:06:00
Virtual IP address is 192.168.42.1
Hello time 3 sec, hold time 10 sec
Next hello sent in 0.192 secs
Redirect time 600 sec, forwarder timeout 14400 sec
Preemption disabled
Active is 192.168.42.5, priority 100 (expires in 11.072 sec)
Standby is local
Priority 100 (default)
Weighting 100 (default 100), thresholds: lower 1, upper 100
Load balancing: round-robin
Group members:
0015.626a.fef1 (192.168.42.4) local
0025.4560.17c1 (192.168.42.5)
There are 2 forwarders (1 active)
Forwarder 1
State is Active
1 state change, last state change 00:05:42
MAC address is 0007.b400.2a01 (default)
Owner ID is 0015.626a.fef1
Preemption enabled, min delay 30 sec
Active is local, weighting 100
Forwarder 2
State is Listen
MAC address is 0007.b400.2a02 (learnt)
Owner ID is 0025.4560.17c1
Time to live: 14399.456 sec (maximum 14400 sec)
Preemption enabled, min delay 30 sec
Active is 192.168.42.5 (primary), weighting 100 (expires in 9.984 sec)
GigabitEthernet0/1 - Group 43
State is Standby
1 state change, last state change 00:06:00
Virtual IP address is FE80::7:B4FF:FE00:2B00 (auto-configured)
Hello time 3 sec, hold time 10 sec
Next hello sent in 0.160 secs
Redirect time 600 sec, forwarder timeout 14400 sec
Authentication MD5, key-string
Preemption disabled
Active is FE80::225:45FF:FE60:17C1, priority 100 (expires in 9.280 sec)
Standby is local
Priority 100 (default)
Weighting 100 (default 100), thresholds: lower 1, upper 100
Load balancing: round-robin
Group members:
0015.626a.fef1 (FE80::215:62FF:FE6A:FEF1) local
0025.4560.17c1 (FE80::225:45FF:FE60:17C1) authenticated
There are 2 forwarders (1 active)
Forwarder 1
State is Active
1 state change, last state change 00:05:45
MAC address is 0007.b400.2b01 (default)
Owner ID is 0015.626a.fef1
Preemption enabled, min delay 30 sec
Active is local, weighting 100
Forwarder 2
State is Listen
MAC address is 0007.b400.2b02 (learnt)
Owner ID is 0025.4560.17c1
Time to live: 14398.912 sec (maximum 14400 sec)
Preemption enabled, min delay 30 sec
Active is FE80::225:45FF:FE60:17C1 (primary), weighting 100 (expires in 8.928 sec)
R4#
R4#
R4#show glbp detail
GigabitEthernet0/1 - Group 42
State is Standby
1 state change, last state change 00:06:24
Virtual IP address is 192.168.42.1
Hello time 3 sec, hold time 10 sec
Next hello sent in 1.088 secs
Redirect time 600 sec, forwarder timeout 14400 sec
Preemption disabled
Active is 192.168.42.5, priority 100 (expires in 10.208 sec)
Standby is local
Priority 100 (default)
Weighting 100 (default 100), thresholds: lower 1, upper 100
Load balancing: round-robin
Group members:
0015.626a.fef1 (192.168.42.4) local
0025.4560.17c1 (192.168.42.5)
There are 2 forwarders (1 active)
Forwarder 1
State is Active
1 state change, last state change 00:06:05
MAC address is 0007.b400.2a01 (default)
Owner ID is 0015.626a.fef1
Preemption enabled, min delay 30 sec
Active is local, weighting 100
Forwarder 2
State is Listen
MAC address is 0007.b400.2a02 (learnt)
Owner ID is 0025.4560.17c1
Time to live: 14398.464 sec (maximum 14400 sec)
Preemption enabled, min delay 30 sec
Active is 192.168.42.5 (primary), weighting 100 (expires in 8.800 sec)
GigabitEthernet0/1 - Group 43
State is Standby
1 state change, last state change 00:06:24
Virtual IP address is FE80::7:B4FF:FE00:2B00 (auto-configured)
Hello time 3 sec, hold time 10 sec
Next hello sent in 1.120 secs
Redirect time 600 sec, forwarder timeout 14400 sec
Authentication MD5, key-string
Preemption disabled
Active is FE80::225:45FF:FE60:17C1, priority 100 (expires in 9.824 sec)
Standby is local
Priority 100 (default)
Weighting 100 (default 100), thresholds: lower 1, upper 100
Load balancing: round-robin
Group members:
0015.626a.fef1 (FE80::215:62FF:FE6A:FEF1) local
0025.4560.17c1 (FE80::225:45FF:FE60:17C1) authenticated
There are 2 forwarders (1 active)
Forwarder 1
State is Active
1 state change, last state change 00:06:08
MAC address is 0007.b400.2b01 (default)
Owner ID is 0015.626a.fef1
Preemption enabled, min delay 30 sec
Active is local, weighting 100
Forwarder 2
State is Listen
MAC address is 0007.b400.2b02 (learnt)
Owner ID is 0025.4560.17c1
Time to live: 14399.360 sec (maximum 14400 sec)
Preemption enabled, min delay 30 sec
Active is FE80::225:45FF:FE60:17C1 (primary), weighting 100 (expires in 10.624 sec)
R4#
R4#
R4#show glbp brief
Interface Grp Fwd Pri State Address Active router Standby router
Gi0/1 42 - 100 Standby 192.168.42.1 192.168.42.5 local
Gi0/1 42 1 - Active 0007.b400.2a01 local -
Gi0/1 42 2 - Listen 0007.b400.2a02 192.168.42.5 -
Gi0/1 43 - 100 Standby FE80::7:B4FF:FE00:2B00
FE80::225:45FF:FE60:17C1
local
Gi0/1 43 1 - Active 0007.b400.2b01 local -
Gi0/1 43 2 - Listen 0007.b400.2b02 FE80::225:45FF:FE60:17C1
-
R4#
R4#
########## R5 ##########
interface GigabitEthernet0/1
ip address 192.168.42.5 255.255.255.0
glbp 42 ip 192.168.42.1
glbp 43 ipv6 autoconfig
glbp 43 authentication md5 key-string 7 12330A1F1C583A013838217965
duplex auto
speed auto
ipv6 address 2001:470:7FEB::5/64
!
R5#show glbp
GigabitEthernet0/1 - Group 42
State is Active
5 state changes, last state change 00:14:57
Virtual IP address is 192.168.42.1
Hello time 3 sec, hold time 10 sec
Next hello sent in 1.440 secs
Redirect time 600 sec, forwarder timeout 14400 sec
Preemption disabled
Active is local
Standby is 192.168.42.4, priority 100 (expires in 9.408 sec)
Priority 100 (default)
Weighting 100 (default 100), thresholds: lower 1, upper 100
Load balancing: round-robin
Group members:
0015.626a.fef1 (192.168.42.4)
0025.4560.17c1 (192.168.42.5) local
There are 2 forwarders (1 active)
Forwarder 1
State is Listen
8 state changes, last state change 00:07:23
MAC address is 0007.b400.2a01 (learnt)
Owner ID is 0015.626a.fef1
Redirection enabled, 599.424 sec remaining (maximum 600 sec)
Time to live: 14399.424 sec (maximum 14400 sec)
Preemption enabled, min delay 30 sec
Active is 192.168.42.4 (primary), weighting 100 (expires in 10.464 sec)
Client selection count: 24
Forwarder 2
State is Active
3 state changes, last state change 00:18:15
MAC address is 0007.b400.2a02 (default)
Owner ID is 0025.4560.17c1
Redirection enabled
Preemption enabled, min delay 30 sec
Active is local, weighting 100
Client selection count: 24
GigabitEthernet0/1 - Group 43
State is Active
4 state changes, last state change 00:14:57
Virtual IP address is FE80::7:B4FF:FE00:2B00 (auto-configured)
Hello time 3 sec, hold time 10 sec
Next hello sent in 2.272 secs
Redirect time 600 sec, forwarder timeout 14400 sec
Authentication MD5, key-string
Preemption disabled
Active is local
Standby is FE80::215:62FF:FE6A:FEF1, priority 100 (expires in 9.120 sec)
Priority 100 (default)
Weighting 100 (default 100), thresholds: lower 1, upper 100
Load balancing: round-robin
Group members:
0015.626a.fef1 (FE80::215:62FF:FE6A:FEF1) authenticated
0025.4560.17c1 (FE80::225:45FF:FE60:17C1) local
There are 2 forwarders (1 active)
Forwarder 1
State is Listen
4 state changes, last state change 00:07:26
MAC address is 0007.b400.2b01 (learnt)
Owner ID is 0015.626a.fef1
Redirection enabled, 599.136 sec remaining (maximum 600 sec)
Time to live: 14399.136 sec (maximum 14400 sec)
Preemption enabled, min delay 30 sec
Active is FE80::215:62FF:FE6A:FEF1 (primary), weighting 100 (expires in 10.272 sec)
Client selection count: 1
Forwarder 2
State is Active
3 state changes, last state change 00:18:10
MAC address is 0007.b400.2b02 (default)
Owner ID is 0025.4560.17c1
Redirection enabled
Preemption enabled, min delay 30 sec
Active is local, weighting 100
Client selection count: 1
R5#
R5#
R5#show glbp detail
GigabitEthernet0/1 - Group 42
State is Active
5 state changes, last state change 00:15:11
Virtual IP address is 192.168.42.1
Hello time 3 sec, hold time 10 sec
Next hello sent in 0.768 secs
Redirect time 600 sec, forwarder timeout 14400 sec
Preemption disabled
Active is local
Standby is 192.168.42.4, priority 100 (expires in 8.704 sec)
Priority 100 (default)
Weighting 100 (default 100), thresholds: lower 1, upper 100
Load balancing: round-robin
Group members:
0015.626a.fef1 (192.168.42.4)
0025.4560.17c1 (192.168.42.5) local
There are 2 forwarders (1 active)
Forwarder 1
State is Listen
8 state changes, last state change 00:07:37
MAC address is 0007.b400.2a01 (learnt)
Owner ID is 0015.626a.fef1
Redirection enabled, 598.720 sec remaining (maximum 600 sec)
Time to live: 14398.720 sec (maximum 14400 sec)
Preemption enabled, min delay 30 sec
Active is 192.168.42.4 (primary), weighting 100 (expires in 9.920 sec)
Client selection count: 24
Forwarder 2
State is Active
3 state changes, last state change 00:18:29
MAC address is 0007.b400.2a02 (default)
Owner ID is 0025.4560.17c1
Redirection enabled
Preemption enabled, min delay 30 sec
Active is local, weighting 100
Client selection count: 24
GigabitEthernet0/1 - Group 43
State is Active
4 state changes, last state change 00:15:11
Virtual IP address is FE80::7:B4FF:FE00:2B00 (auto-configured)
Hello time 3 sec, hold time 10 sec
Next hello sent in 1.344 secs
Redirect time 600 sec, forwarder timeout 14400 sec
Authentication MD5, key-string
Preemption disabled
Active is local
Standby is FE80::215:62FF:FE6A:FEF1, priority 100 (expires in 8.640 sec)
Priority 100 (default)
Weighting 100 (default 100), thresholds: lower 1, upper 100
Load balancing: round-robin
Group members:
0015.626a.fef1 (FE80::215:62FF:FE6A:FEF1) authenticated
0025.4560.17c1 (FE80::225:45FF:FE60:17C1) local
There are 2 forwarders (1 active)
Forwarder 1
State is Listen
4 state changes, last state change 00:07:41
MAC address is 0007.b400.2b01 (learnt)
Owner ID is 0015.626a.fef1
Redirection enabled, 598.656 sec remaining (maximum 600 sec)
Time to live: 14398.656 sec (maximum 14400 sec)
Preemption enabled, min delay 30 sec
Active is FE80::215:62FF:FE6A:FEF1 (primary), weighting 100 (expires in 9.056 sec)
Client selection count: 1
Forwarder 2
State is Active
3 state changes, last state change 00:18:25
MAC address is 0007.b400.2b02 (default)
Owner ID is 0025.4560.17c1
Redirection enabled
Preemption enabled, min delay 30 sec
Active is local, weighting 100
Client selection count: 1
R5#
R5#
R5#show glbp brief
Interface Grp Fwd Pri State Address Active router Standby router
Gi0/1 42 - 100 Active 192.168.42.1 local 192.168.42.4
Gi0/1 42 1 - Listen 0007.b400.2a01 192.168.42.4 -
Gi0/1 42 2 - Active 0007.b400.2a02 local -
Gi0/1 43 - 100 Active FE80::7:B4FF:FE00:2B00
local FE80::215:62FF:FE6A:FEF1
Gi0/1 43 1 - Listen 0007.b400.2b01 FE80::215:62FF:FE6A:FEF1
-
Gi0/1 43 2 - Active 0007.b400.2b02 local -
R5#
R5#
VRRP
Instead of GLBP, I used the Virtual Router Redundancy Protocol this time. Unluckily it was only available for legacy IP on my routers. Hence I used HSRP for IPv6 as well. Following procedure:
Start of the capture in front of the Raspi
boot of the Raspi
ping “netsec.blog” via v6 and v4
now: R4 reload (R5 was active for both IPs)
wait (R5 was still active for both IPs)
R5 reload (R4 became active, of course)
wait
R5 was now again active for VRRP (preempt) while not for HSRP
Display filter “vrrp”. That’s how it looks like:
(Oh no, I am not quite sure whether or not I missed some VRRP packets which are possibly direct Ethernet traffic between the two routes, as I captured on the Raspi. Shit. Ok, at least I have VRRP traffic. ;))
Syslogs at R4 during the reload of R5:
R4#
Dec 2 2020 16:11:52.872 UTC: %HSRP-5-STATECHANGE: GigabitEthernet0/1 Grp 6 state Standby -> Active
R4#
Dec 2 2020 16:12:00.456 UTC: %VRRP-6-STATECHANGE: Gi0/1 Grp 1 state Backup -> Master
R4#
Dec 2 2020 16:12:06.184 UTC: %CLNS-5-ADJCHANGE: ISIS: Adjacency to R5 (GigabitEthernet0/0) Down, hold time expired
R4#
Dec 2 2020 16:14:17.118 UTC: %CLNS-5-ADJCHANGE: ISIS: Adjacency to R5 (GigabitEthernet0/0) Up, new adjacency
Dec 2 2020 16:14:17.122 UTC: %CLNS-5-ADJCHANGE: ISIS: Adjacency to R5 (GigabitEthernet0/0) Up, new adjacency
R4#
Dec 2 2020 16:14:29.722 UTC: %VRRP-6-STATECHANGE: Gi0/1 Grp 1 state Master -> Backup
R4#
Final config and show commands:
########## R4 ##########
!
track 1 interface GigabitEthernet0/0 line-protocol
!
track 6 interface GigabitEthernet0/0 line-protocol
!
!
interface GigabitEthernet0/1
ip address 192.168.42.4 255.255.255.0
standby version 2
standby 6 ipv6 autoconfig
standby 6 preempt
standby 6 authentication password
standby 6 track 6 decrement 10
duplex auto
speed auto
ipv6 address 2001:470:7FEB::4/64
vrrp 1 ip 192.168.42.1
vrrp 1 authentication md5 key-string 7 106406110B44240E1E172F7A72
vrrp 1 track 1
!
R4#show standby
GigabitEthernet0/1 - Group 6 (version 2)
State is Active
2 state changes, last state change 00:09:32
Virtual IP address is FE80::5:73FF:FEA0:6
Active virtual MAC address is 0005.73a0.0006
Local virtual MAC address is 0005.73a0.0006 (v2 IPv6 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 0.272 secs
Authentication text, string "password"
Preemption enabled
Active router is local
Standby router is FE80::225:45FF:FE60:17C1, priority 100 (expires in 11.552 sec)
Priority 100 (default 100)
Track object 6 state Up decrement 10
Group name is "hsrp-Gi0/1-6" (default)
R4#
R4#
R4#
R4#show standby brief
P indicates configured to preempt.
|
Interface Grp Pri P State Active Standby Virtual IP
Gi0/1 6 100 P Active local FE80::225:45FF:FE60:17C1
FE80::5:73FF:FEA0:6
R4#
R4#
R4#
R4#show vrrp
GigabitEthernet0/1 - Group 1
State is Backup
Virtual IP address is 192.168.42.1
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption enabled
Priority is 100
Track object 1 state Up decrement 10
Authentication MD5, key-string
Master Router is 192.168.42.5, priority is 100
Master Advertisement interval is 1.000 sec
Master Down interval is 3.609 sec (expires in 2.949 sec)
R4#
R4#
R4#
R4#show vrrp brief
Interface Grp Pri Time Own Pre State Master addr Group addr
Gi0/1 1 100 3609 Y Backup 192.168.42.5 192.168.42.1
R4#
R4#
R4#show track
Track 1
Interface GigabitEthernet0/0 line-protocol
Line protocol is Up
1 change, last change 00:12:00
Tracked by:
VRRP GigabitEthernet0/1 1
Track 6
Interface GigabitEthernet0/0 line-protocol
Line protocol is Up
1 change, last change 00:12:00
Tracked by:
HSRP GigabitEthernet0/1 6
R4#
R4#
########## R5 ##########
!
track 1 interface GigabitEthernet0/0 line-protocol
!
track 6 interface GigabitEthernet0/0 line-protocol
!
interface GigabitEthernet0/1
ip address 192.168.42.5 255.255.255.0
standby version 2
standby 6 ipv6 autoconfig
standby 6 preempt
standby 6 authentication password
standby 6 track 6 decrement 10
duplex auto
speed auto
ipv6 address 2001:470:7FEB::5/64
vrrp 1 ip 192.168.42.1
vrrp 1 authentication md5 key-string 7 0966410117562117191F017B7D
vrrp 1 track 1
!
R5#show standby
GigabitEthernet0/1 - Group 6 (version 2)
State is Standby
1 state change, last state change 00:07:47
Virtual IP address is FE80::5:73FF:FEA0:6
Active virtual MAC address is 0005.73a0.0006
Local virtual MAC address is 0005.73a0.0006 (v2 IPv6 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 1.376 secs
Authentication text, string "password"
Preemption enabled
Active router is FE80::215:62FF:FE6A:FEF1, priority 100 (expires in 10.016 sec)
MAC address is 0015.626a.fef1
Standby router is local
Priority 100 (default 100)
Track object 6 state Up decrement 10
Group name is "hsrp-Gi0/1-6" (default)
R5#
R5#
R5#show standby brief
P indicates configured to preempt.
|
Interface Grp Pri P State Active Standby Virtual IP
Gi0/1 6 100 P Standby FE80::215:62FF:FE6A:FEF1
local FE80::5:73FF:FEA0:6
R5#
R5#
R5#show vrrp
GigabitEthernet0/1 - Group 1
State is Master
Virtual IP address is 192.168.42.1
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption enabled
Priority is 100
Track object 1 state Up decrement 10
Authentication MD5, key-string
Master Router is 192.168.42.5 (local), priority is 100
Master Advertisement interval is 1.000 sec
Master Down interval is 3.609 sec
R5#
R5#
R5#show vrrp brief
Interface Grp Pri Time Own Pre State Master addr Group addr
Gi0/1 1 100 3609 Y Master 192.168.42.5 192.168.42.1
R5#
R5#
R5#show track
Track 1
Interface GigabitEthernet0/0 line-protocol
Line protocol is Up
1 change, last change 00:08:47
Tracked by:
VRRP GigabitEthernet0/1 1
Track 6
Interface GigabitEthernet0/0 line-protocol
Line protocol is Up
1 change, last change 00:08:47
Tracked by:
HSRP GigabitEthernet0/1 6
R5#
R5#
CAPWAP
Again, thanks to Alexis for the packets. ;) Wireshark uses two different display filters for CAPWAP: “capwap” for the control channel on UDP port 5246 and “capwap.data” for the data on UDP port 5247:
Full Ethernet Frame Capturing
For the captures, I used my ProfiShark from Profitap. This time I enabled the “capture full frames” option which includes the Ethernet preamble, the SMD, and the CRC for each frame:
I was missing a generic layer 4 ping in my toolbox. Initially searching for a mere TCP ping, I have found Nping which completely satisfies my needs and gives so much more. ;)
While I used some special tools for upper-layer protocol pings (ref: Advanced Ping: httping, dnsping, smtpping), I was still missing a generic one as I wanted to test several other TCP ports in a ping style. For a Layer 4 Traceroute, I blogged several years ago.
Nping
“Nping is an open source tool for network packet generation, response analysis and response time measurement”, https://nmap.org/nping/. You can easily get it on any Debian/Ubuntu-based Linux system by installing Nmap, to which Nping belongs to:
sudo apt install nmap
Its usage for TCP/UDP is straightforward. Simply use the
--tcp option along with the port in question
-p <port>, in my test case, the SSH port 22:
weberjoh@nb15-lx:~$ sudo nping --tcp -p 22 lx3.weberlab.de
Starting Nping 0.7.01 ( https://nmap.org/nping ) at 2021-04-22 12:21 CEST
SENT (0.0791s) TCP 192.168.3.85:1181 > 85.215.94.29:22 S ttl=64 id=19852 iplen=40 seq=4080408859 win=1480
RCVD (0.2650s) TCP 85.215.94.29:22 > 192.168.3.85:1181 SA ttl=54 id=0 iplen=44 seq=847994447 win=29200 <mss 1460>
SENT (1.0793s) TCP 192.168.3.85:1181 > 85.215.94.29:22 S ttl=64 id=19852 iplen=40 seq=4080408859 win=1480
RCVD (1.2650s) TCP 85.215.94.29:22 > 192.168.3.85:1181 SA ttl=54 id=0 iplen=44 seq=863592152 win=29200 <mss 1460>
SENT (2.0811s) TCP 192.168.3.85:1181 > 85.215.94.29:22 S ttl=64 id=19852 iplen=40 seq=4080408859 win=1480
RCVD (2.2650s) TCP 85.215.94.29:22 > 192.168.3.85:1181 SA ttl=54 id=0 iplen=44 seq=879302070 win=29200 <mss 1460>
SENT (3.0831s) TCP 192.168.3.85:1181 > 85.215.94.29:22 S ttl=64 id=19852 iplen=40 seq=4080408859 win=1480
RCVD (3.2650s) TCP 85.215.94.29:22 > 192.168.3.85:1181 SA ttl=54 id=0 iplen=44 seq=895059280 win=29200 <mss 1460>
SENT (4.0851s) TCP 192.168.3.85:1181 > 85.215.94.29:22 S ttl=64 id=19852 iplen=40 seq=4080408859 win=1480
RCVD (4.2650s) TCP 85.215.94.29:22 > 192.168.3.85:1181 SA ttl=54 id=0 iplen=44 seq=910622060 win=29200 <mss 1460>
Max rtt: 185.982ms | Min rtt: 179.872ms | Avg rtt: 183.451ms
Raw packets sent: 5 (200B) | Rcvd: 5 (230B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 4.29 seconds
Viewing the packets with Wireshark looks a bit odd since it displays many [TCP Retransmission] and other TCP failures. Never mind, this is correct behaviour from the layer 4 ping tools point of view. After receiving the [SYN, ACK] from the server, Nping sends a [RST] to free the session tables on the server and intermediary NAT/firewalls.
Mission accomplished: Testing whether or not the destination port is listening.
Some notes/caveats:
Using Nping for pinging an HTTP/HTTPS server isn’t the best way, since it only sends TCP SYNs but no HTTP GET or the like. Use httping instead.
This is just the tip of the iceberg of Nping. You can do so much more, e.g., different kind of ICMP based pings (that is: not only echo-request but any ICMP type) as well as some ARP/RARP stuff. Nice!
I’m having trouble using Nping with IPv6. Pings are SENT but not RCVD. Tested it on different systems, but did not succeed. Might be related to the Nping To-Do list that states “Improve IPv6 support. Currently it doesn’t work well.” ;)
As seen in the Wireshark screenshot, Nping uses the same source port for each ping. To my mind, it should use a different random source port for each ping to have unique “tcp streams” among the pings. At least optionally.
Windows users can leverage “tcping.exe” for layer 4 pings.
P.S.: I am still missing an sshping tool that does an SSH login or at least a handshake once per second. Haven’t found one yet.
The other day I wanted to verify whether a service running on my Linux server was listening on IPv6 as well as IPv4. It turned out that it wasn’t that easy to answer – if at all.
Which ports are in the listening state? –> For this question I used
netstat -tulpen for a couple of years now. It turned out, that netstat is kind of deprecated and that I should usess for this. Same options:
ss -tulpen:
t: TCP
u: UDP
l: listening
p: show the corresponding process
e: extended (important, see below)
n: numeric, that is: not resolving IP addresses (DNS PTR records) nor service names (“22” instead of “ssh”)
So, what’s the deal now?
While some processes/services are opening an IPv6 socket and an independent IPv4 socket, some others are opening one single socket shown as IPv6, while listening on both Internet Protocols.
In my case, I was trying to verify whether or not syslog-ng is listening on both IPs. I already knew that my SSH daemon was listening on both protocols. So this was the output (sorry, you have to scroll horizontally):
–> At a first glance, it looks like ssh is running for IPv4 and IPv6, while syslog-ng shows only one line here. In fact, it IS listening on both Internet Protocols as well. Note the “v6only:0” at the end which implies that this socket is also capable of IPv4. The IPv6 line from ssh reads “v6only:1” at the end. (This is what the
-e option is all about.)
In case you’re using netstat, this is the output there. It shows “tcp6” for syslog-ng which is even more inaccurate as it implies “only v6” to my mind:
weberjoh@nb17-lx2:~$ sudo netstat -tulpen
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 22611 1023/sshd
tcp6 0 0 :::22 :::* LISTEN 0 22615 1023/sshd
tcp6 0 0 :::514 :::* LISTEN 0 1753628 1877/syslog-ng
It’s even getting weirder when listing IPv4 services only, because it does not show the “v6only:0” line at all, hence omitting the syslog-ng daemon completely, while it IS listening on IPv4:
weberjoh@nb17-lx2:~$ sudo ss -tulpen4
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1023,fd=3)) ino:22611 sk:3 <->
Twitter user Flüpke gave the following explanation: “Sockets bound to in6addr_any on Linux will receive IPv4 mapped traffic if the sockopt IPV6_V6ONLY is not set”. Uh, okay.
By the way: Since I was really unsure whether the ports are open or not, I used Nmap from a machine in the same layer 3 subnet to check for both Internet Protocols:
pi@pi05-random:~ $ sudo nmap -Pn -sS -p 514 194.247.5.6
Starting Nmap 7.40 ( https://nmap.org ) at 2021-05-20 14:40 CEST
Nmap scan report for 194.247.5.6
Host is up (0.00066s latency).
PORT STATE SERVICE
514/tcp open shell
MAC Address: 00:21:70:B2:0E:6C (Dell)
Nmap done: 1 IP address (1 host up) scanned in 3.76 seconds
pi@pi05-random:~ $
pi@pi05-random:~ $
pi@pi05-random:~ $ sudo nmap -Pn -sS -p 514 -6 2001:470:1f0b:16b0::b17:22
Starting Nmap 7.40 ( https://nmap.org ) at 2021-05-20 14:41 CEST
Nmap scan report for 2001:470:1f0b:16b0::b17:22
Host is up (0.00083s latency).
PORT STATE SERVICE
514/tcp open shell
MAC Address: 00:21:70:B2:0E:6C (Dell)
Nmap done: 1 IP address (1 host up) scanned in 1.23 seconds
To top it off
I wanted syslog-ng to listen on UDP and TCP on both Internet Protocols. Using this source statement:
Ouch. To my mind, this was incorrect anyway, since the second line shows “v6only:0” hence there were two different UDP sockets opened, both capable of IPv4.
Thanks to Twitter Users!
Thanks to my Twitter followers, who helped me out with this question. In the end, “I know that I know nothing”. Even after figuring it out for a couple of hours, I am not quite sure whether I understood it correctly… Any concerns from your site? Please leave a comment!
I got an interesting question through the comments section on my blog:
What does “Bytes sent/ Bytes received” mean in ACC screen of Palo Alto firewall? I mean, if 500MB of packets are sent from a source device and go through a firewall, get permitted to reach the destination, then the firewall should not see the packets as “sent” or “received”; the firewall just “processes” the packets regardless of the direction, I suppose.
Quite a good questions. Let’s have a look:
TL;DR: The “sent/received” values are ALWAYS from the clients perspective.
Indeed the firewall never receives or sends packets directly to/from itself, but rather processes packets. (Ok, there are exceptions such as management access via ping, ssh, https to a data interface or IPsec traffic to the WAN interface or OSPF to an internal interface.)
However, all the “sent/received” values are based on the source -> destination connection aka client -> server. That is: for both, UDP and TCP, the client always starts the connection to the server. For TCP, the client sends the very first TCP SYN packet while for UDP the client simply sends the data immediately without a handshake. That is: The “sent/received” values are ALWAYS from the clients perspective! Just like in the direction of the policies itself.
Let’s have a look at an example: An SSH connection is made from a client to a server. The IP address from the client is the source, while the IP address from the server is the destination. If this SSH connection is used by SCP in which the client uploads a 1 GB file to the server, this 1 GB is listed as “sent“. If in another session the same client downloads a 1 GB file from the server, the “source” and “destination” IP addresses are still the same (since the same client has started the session through the same security policy), while this 1 GB is counted as “received“.
This is what these two scenarios look like on a Palo Alto Networks firewall (with a ∼600 MB file, first uploaded by the client, second downloaded by the client):
Or on a Fortinet FortiGate:
Of course, when you’re looking at the sent/received values from the network interface cards (NIC) on the client or the server, the values correspond to the direction. If the client uploads a file, its own sent values increase while the received values do the same on the server, and vice versa.
Furthermore, everything that has been said here also applies to the count of packets, not only to the count of bytes.
This is a guest blog post by Erik Hjelmvik, an expert in network forensics and network security monitoring at NETRESEC.
PolarProxy is a transparent TLS proxy that outputs decrypted TLS traffic as PCAP files. PolarProxy doesn’t interfere with the tunnelled data in any way, it simply takes the incoming TLS stream, decrypts it, re-encrypts it and forwards it to the destination. Because of this PolarProxy can be used as a generic TLS decryption proxy for just about any protocol that uses TLS encryption, including HTTPS, HTTP/2, DoH, DoT, FTPS, SMTPS, IMAPS, POP3S and SIP-TLS.
PolarProxy is primarily designed for inspecting otherwise encrypted traffic from malware, such as botnets that use HTTPS for command-and-control of victim PCs. Other popular use cases for PolarProxy is to inspect encrypted traffic from IoT devices and other embedded products or to analyze otherwise encrypted traffic from mobile phones and tablets. The fact that PolarProxy exports the decrypted traffic in a decrypted format without any TLS headers also enables users to inspect the decrypted traffic with products that don’t support TLS decryption, such as intrusion detection and network forensics products like Suricata, Zeek and NetworkMiner.
PolarProxy creates a unique root CA certificate for each installation which must be trusted by clients that will have their TLS traffic decrypted. PolarProxy’s root CA must therefore be trusted by the operating systems, browsers and applications that you wish to decrypt TLS traffic from.
The Wireshark screenshot above shows DNS-over-HTTPS (DoH) traffic in the file proxy-191023-091924.pcap, which was captured live during my TLS Interception and Decryption talk at the CS3Sthlm conference in 2019. As you can see, the DoH query is sent inside an HTTP/2 request. You might also notice that the HTTP/2 request is not encapsulated by a TLS record. This is because PolarProxy has removed all TLS data before saving the decrypted traffic to a capture file.
PolarProxy is released under a CC BY-ND 4.0 license, which means you are free to use the software for any purpose, even commercially. To take PolarProxy for a test run, simply run the following commands on a Linux machine:
mkdir ~/PolarProxy
cd ~/PolarProxy/
curl https://www.netresec.com/?download=PolarProxy | tar -xzf -
sudo ./PolarProxy -v -p 443,80 --certhttp 10080 -w /tmp/polarproxy.pcap
You will then have a PolarProxy service listening on TCP port 443 that will output decrypted packets to “/tmp/polarproxy.pcap“. To test the proxy, simply run the following curl command on any PC in your network:
Note: Replace 10.1.2.3 with the IP address of PolarProxy.
This command tells curl to behave as if weberblog.net resolved to PolarProxy’s IP, whereby the outgoing connection is sent via the TLS decryption proxy. The --insecure option is there because PolarProxy will generate a fake X.509 certificate for the domain in question (here: weberblog.net) on the fly and sign it with its own root CA certificate, which neither curl nor your operating system trusts by default. This root CA cert can be downloaded from an HTTP service listening on port 10080 on the PolarProxy machine. For instructions on how to configure a PC to trust this certificate, please see the “Trusting the PolarProxy root CA” section on the PolarProxy documentation.
It’s not possible to decrypt traffic from applications that use techniques like certificate transparency or public key pinning with PolarProxy though since they will not accept the X.509 certificate provided by PolarProxy even though it is signed by a trusted root.
PolarProxy is a transparent proxy, which means that, apart from trusting the root CA cert, no configuration is needed on the client in order to have the TLS traffic intercepted. Instead, you’ll need to deploy a firewall DNAT rule that redirects all outgoing TLS traffic to PolarProxy. For instructions on how to do this with iptables, please see the PolarProxy page. For other firewall solutions, however, you’ll need to figure out how to do this yourself.
Again and again, I am adding some protocol samples to the Ultimate PCAP. Just for reference. And because I can. ;D
HomePlug AV
By coincidence, I encountered this “HomePlug AV” protocol on my home network. It was my home router AVM Fritzbox detecting some other powerline adapters. Wireshark has a display filter
homeplug-av for it, but you can also use an EtherType based filter:
eth.type == 0x88e1.
4in6
While 6in4 is a common technique for tunnel IPv6 packets through IPv4 only networks, 4in6 does it vice versa: connecting v4 islands over native v6. It’s going in the right direction. ;) It’s quite common on residential ISP connections in Germany, where native v4 is not possible anymore. They call it DS-Lite (which brings other technical problems, by the way).
Technically, 4in6 is not an own protocol (which would need an own protocol dissector within Wireshark), but normal IPv4 packets right behind an IPv6 header. Hence, the display filter is just
ipv6.nxt == 4 since the Next Header field in the v6 header points to this generic “IPv4 encapsulation” with protocol number 4. The following screenshot also shows the PPPoE and PPP session as well as VLAN 7, which is the default data VLAN for Deutsche Telekom connections.
The type value for this HTTPS resource record is 65. I am not quite sure how this RR is used. It seems like my Apple devices are querying for it. Note that not every HTTPS query is answered by a corresponding HTTPS response. To find all HTTPS queries or responses, use this display filter:
(dns.qry.type == 65). Looks like this: (with two custom columns, one for the query type and another for the response type)
Only some responses are answering with an HTTPS RR,
(dns.resp.type == 65):
SNMP Trap
No big deal, though missing until now. Some SNMP traps, sent to UDP port 162, connectionless. Wireshark’s display filter
snmp is working just like normal SNMP query/response packets on UDP port 161:
Please note that in my case the SNMP traps were a little longer than a single UDP packet, hence fragmented. And since UDP has no fragmentation (such as TCP), the fragmentation occurs at the IP layer (not recommended in general). Anyway, this is how it looks actually:
Syslog via TCP
No big deal, either. It’s a syslog logging via TCP rather than UDP. However, while the IANA lists UDP port 514 as “syslog”, TCP port 514 is listed as “shell”. Wireshark follows this, hence you can’t use
syslog as the display filter but
rsh for remote shell. Or you use
tcp.port eq 514 to see the whole session incl. TCP overhead (recommended). The “packet bytes” section already decodes the ASCII characters, so does “Follow TCP Stream”.
In the Wireshark preferences, you could change the default port of RSH from 514 to 0 (for example) while changing the syslog TCP port to 514. This would recognize and parse the syslog messages sent over TCP.
To be honest, I am not quite sure whether 514 is the correct port for syslog over TCP at all. Some sources list TCP port 601 (RFC 3195), while others state that 514 is used mostly (RFC 6587). Anyway, Wireshark has no default TCP port for syslog at all. If you want to be conflict-free, you can use TCP port 601 for it, while setting this port as the default TCP port for syslog in Wireshark:
That is, you can use the display filter
syslog again for TCP 601 sessions. And the protocol dissector works within the packet details section:
Anyway, you’ll find syslog over TCP sessions on both ports in the pcap, 514 and 601. ;)
Endlich war es soweit: Das eigene Haus stand vor der Tür und Johannes hat sich um die Netzwerkverkabelung und das Netzwerkdesign gekümmert. Hier eine Zusammenfassung meiner Gedanken und deren Umsetzung – offen für kritische Rückfragen, Verbesserungsvorschläge und Bewunderungsbekundungen. :)
Ausgangssituation
Gebrauchtes Haus, keine Netzwerkverkabelung vorhanden. Drei Geschosse (Keller, Erdgeschoss, Dachgeschoss), alle sollen vernünftig mit WLAN versorgt werden. Trotzdem möchte ich möglichst viele Geräte direkt per Kabel anschließen. Also natürlich nur die, die einen LAN-Anschluss haben, wie der Fernseher oder die Sonos Lautsprecher. Internetanschluss über klassisches 2-Draht der Telekom, DSLAM mit VDSL auf der gegenüberliegenden Straßenseite. 100/40 MBit/s Leitung läuft super stabil. Fritzbox 7430 seit Jahren vorhanden und weiterhin funktionstüchtig. Zwar nur 100 Mbit/s Ports, aber das reicht ja für den Internetanschluss. Fürs vernünftige Verteilen von verschiedenen WLANs werde ich auf Ubiquiti UniFi setzen, weil AVM da leider nichts gescheites zu bieten hat.
Verkabelung
Verlegt habe ich ausschließlich Cat 7 Doppelkabel (scheint man wohl auch Duplex zu nennen, was mir aber komisch vorkommt). Cat 6 oder 6a hätte natürlich für Gigabit LAN auch völlig ausgereicht, aber auf Grund irgendwelcher physikalischen Gegebenheiten hatte man mir geraten, stets die aktuell beste Variante zu nehmen. Und überhaupt!
Insgesamt 21 Doppelkabel, also sage und schreibe 42 Anschlüsse liegen nun im Haus. Hehe. Ausgangspunkt ist stets meine Netzwerk-Nische im Keller, wo ich zwei Rackschienen im 19″ Abstand reingebaut habe. Über ein 6 mm² grün/weiß Kabel habe ich die Schose an die Potentialausgleichsschiene angeschlossen und somit abgesichrt. Horizontal habe ich alle Netzwerkkabel entweder im Keller verlegt (um dann ins EG hochzubohren), bzw. durch einen stillgelegten Schornstein nach oben auf dem Dachboden verlegt, um dann wiederum ins Obergeschoss runterzubohren.
Die Aufteilung ist wie folgt:
6x Büro Schreibtisch: PC, Laptop-Dock, VoIP, diverse Reserve
4x Büro hinten: Drucker, Access Point, Testnotebook, NTP Uhr
2x Heizungsraum: IoT kommt bestimmt
6x Waschkeller: Weil hier der Telekom Anschluss und die Fritzbox liegt, die dann weiter durchgepatcht wird. Außerdem Anschlüsse für den Außenbereich (falls nötig). Fun fact: Waschmaschine und Trocker haben bereits IP, allerdings rein über WLAN.
2x Strom Hauptverteilung: Raspberry Pi für Stromzähler/Hausautomation
2x Flur EG: Access Point und Philips Hue Bridge
4x Wohnzimmer: Fernseher, Playstation, Sonos-Bar und -Sub
2x Esszimmer: Weils ging
2x Zwischenraum: dito
4x Spielzimmer: Die Kids werden hier irgendwann mal Fernseher und Zeugs haben, aktuell aber noch nichts belegt
8x Dachboden: An aktuell einer Stelle habe ich vom Dachboden “nach unten” in das Obergeschoss gebort, nämlich für den Access Point. Ansonsten: Raspberry Pis für Spielereien wie NTP, ADS-B oder Temperatur/Wetterstation, Reserve.
Weil es ging und ich entsprechende Kabel hatte habe ich auch 3x Glasfaserkabel (Shortrange) verlegt:
1x Waschraum: neben den Übergabepunkt der Telekom, falls mal ein Glasfaseranschluss kommen sollte
1x Büro Schreibtisch: Fiber to the Dockingstation?!?
1x Dachboden: falls dort mal ein eigener Switch hinsoll um keinen Potentialausgleich über die Netzwerkkabel zu haben, vor allem, wenn Geräte mit Antenne auf dem Dach sind
Fun fact: Mittlerweile *haben* wir sogar die Glasfaser per Deutsche Glasfaser, allerdings wurde sie aus verlegungstechnischen Gründen in einem anderen Kellerraum terminiert. Hahaha. Somit habe ich nachträglich noch ein viertes Glasfaser Kabel im Keller verlegt.
Abgeknickt
Tja, trotz aller Vorsicht hatte ich ein Pärchen der Netzwerkkabel etwas zu hart um eine Stromdosen herumgelegt:
Immerhin habe ich fein säuberlich nach jedem Auflegen im Patchpanel bzw. der Dose die Kabel per Pockethernet überprüft. Dort wurde mir der Fehler als Kurzschluss (“short”) vom Pärchen Nummer 2 angezeigt. Tatsächlich kam kein PoE-Link mit 1Gbps hoch:
Naja, also habe ich dieses Dopplekabel halt nochmal verlegt. Zum Glück war es nur eine kurze Strecke innerhalb des Kellers. By the way: Wer sich die Güte meiner LSA-Auflegungen mal anschauen will:
Wie ist das Netzwerk nun logisch designed? Hier zunächst mal ein Bild:
Kerngedanken:
Die Fritzbox baut die IP-Verbindung ins Internet auf. Sprich: Die öffentliche IPv4-Adresse liegt an ihrem WAN Interface an. Das hat den Vorteil, dass VoIP für uns privat ohne Probleme funktioniert. (Nicht so wie hier.) Gleichermaßen verwende ich die DECT-Funktionalität der Fritzbox. Das WLAN ist abgeschaltet (!) weil ich das über andere APs im Haus verteile, siehe unten. Ausgehend wird hier klasschiches NAT/PAT für das veraltete Internet Protokoll gemacht. IPv6 wird natürlich weiter nach innen geroutet.
In dem IP-Netz der Fritzbox befinden sich *keine* Endgeräte. Es dient viel mehr als “DMZ“, in dem ich u.a. meinen Pi-hole und einen Raspi als Stratum 1 NTP Server stehen habe. Auf diese zwei Geräte wird von allen anderen Netzten direkt per Routing zugegriffen. Der NTP Server ist über IPv6 Teil des NTP Pool Projects.
Mein eigentliches Netzwerk wird dann per Ubiquiti UniFi Komponenten bereitgestellt. Im Zentrum der “USG” Router. (Wird gerne als Security Device bezeichnet, was ich mit einem Schmunzeln zur Kenntnis nehme.) Dieser stellt mir drei verschiedene IP-Netzwerke aka VLANs aka WLANs bereit, welche dann über den Switch bzw. über die Access Points verteilt werden. So kann ich jedem Endgerät, egal ob kabellos oder kabelgebunden, das entsprechende VLAN/WLAN zuweisen und so steuern, in welcher Security-Zone es sich befinden soll. Diese wären:
Privates WLAN: Für meine privaten Endgeräte wie Smartphones, Notebooks, NAS, Sonos Lautsprecher
Gäste-WLAN: Reiner Internetzugriff, kein Zugriff auf mein privates Netz
IoT-WLAN: Für gesprächige IoT Geräte wie Fernseher, Thermomix, Waschmaschine, Philips Hue Bridge, …, ebenfalls kein Zugriff auf mein privates Netz
Für mein Homeoffice habe ich eine komplett getrennte Firewall mit Site-to-Site VPN Tunnel in die Firma. Das Dienstnotebook und VoIP Phone laufen hier drüber. Physikalisch getrennt.
Beide nachgelagerten Router (USG und Palo Firewall) verwenden *kein* ausgehendes NAT. Somit erspare ich mir für IPv4 das unnötige Doppel-NAT. Hierfür müssen auf der Fritzbox die statischen Routen für die Layer 3 Netze eingerichtet werden:Das “kein ausgehendes NAT” war auf dem UniFi USG Router übrigens gar nicht so einfach. Über die GUI geht das nämglich gar nicht. Arg. So viel zum Thema “Enterprise Security Gateway”. Hahaha. Und noch was: Wenn demnächst CGNAT beim ISP der Fall ist, habe ich doch wieder ein Doppel-NAT. Hmpf. Aber immerhin erspare ich mir dann das Triple.
Meine Probleme habe ich übrigens (leider) mit IPv6. Hauptproblem sind die wechselnden Präfixe beim Heimanschluss. Theoretisch kann die UniFi USG ja einen Präfix per DHCPv6-PD beziehen und per RA auf den einzelnen Netzwerken bereitstellen. Aktuell (Version 6.4.54) bekomme ich das aber irgendwie nicht vernünftig zum laufen. Geschweigedenn bei einem Wechsel des kompletten /56er zu einem neuen. Was ein sch***.
Netzwerkgeräte
Danke zunächst mal an dieser Stelle an Helms E. für die Vorüberlegungen der Verkabelung, Fabian R. für den Einbau der Schienen, Christian S. für das Helfen beim Auflegen und Timotheus K. beim Verlegen der Erdung!
Hier nun mal zwei paar Fotos von dem Selbstbau.
Wer es genau wissen möchte: Diese Geräte verwende ich konkret:
AVM FRITZ!Box 7430. Wenn die Deutsche Glasfaser dann fertig verlegt ist (Glasfaser: GPON) wird es wohl eine 5491 oder 5530. Es ist eine 7590 geworden. ;)
Hehe. Es werden also nicht nur die APs und der CloudKey, sondern auch die Raspberry Pis und die Philips Hue Bridges (ja, zwei!) per PoE betrieben. Ebenso aktuell noch ein RIPE Atlas Probe. Das ist in der UniFi GUI beim Switch auch schön zu sehen (man achte auf die ganzen Blitz-Symbole in der Übersicht oben):
Das waren so in Kürze meine Gedanken. Und was denkt ihr so? ;D
You probably know already the concept of the Pi-hole. If not: It’s a (forwarding) DNS server that you can install on your private network at home. All your clients, incl. every single smartphone, tablet, laptop, and IoT devices such as smart TVs or light bulb bridges, can use this Pi-hole service as their DNS server. Now here’s the point: it not only caches DNS entries, but blocks certain queries for hostnames that are used for ads, tracking, or even malware. That is: You don’t have to use an ad- or track-blocker on your devices (which is not feasible on smart TVs or smartphone apps, etc.), but you’re blocking this kind of sites entirely. Nice approach!
Yes, there are already some setup tutorials for the Pi-hole out there. However, it’s not only about installing the mere Pi-hole, but setting it up with your own recursive DNS server (since the default installation forwards to public DNS servers), using DNSSEC, and adding some more adlists. That’s why I am listing my installation procedure here as well. However, it’s not a complete beginners guide. You’ll need some basic Linux know-how.
I am using a Raspberry Pi 3 B+ Rev 1.3 with Raspberry Pi OS for this setup. (While in the meantime I’m running Pi-hole on my Intel NUC with Ubuntu server.)
Well, that was easy. It will ask you some questions though. Note the lines at the end about your admin password and how to access the console:
[i] Web Interface password: Q_1kJLS9
[i] This can be changed using 'pihole -a -p'
[i] View the web interface at http://pi.hole/admin or http://192.168.7.53/admin
Own Recursive DNS Server & DNSSEC
By default, Pi-hole uses some public DNS servers for its name resolution. I don’t like that concept because you’re giving 100 % of your queries to some third parties. I prefer using my own recursive DNS server. (Yes, I know that your upstream ISP is still able to see your queries, but that’s by far better than using 8.8.8.8 or the like.) The recursive DNS server of choice is Unbound. The following installation procedure is covered on the Pi-hole site as well.
sudo apt update
sudo apt install unbound
While this installation is working, the Unbound service is not able to start yet because the UDP/TCP port 53 is already used by Pi-hole. You have to use an adapted config anyway:
server:
# If no logfile is specified, syslog is used
# logfile: "/var/log/unbound/unbound.log"
verbosity: 0
interface: 127.0.0.1
port: 5335
do-ip4: yes
do-udp: yes
do-tcp: yes
do-ip6: yes
# You want to leave this to no unless you have *native* IPv6. With 6to4 and
# Terredo tunnels your web browser should favor IPv4 for the same reasons
prefer-ip6: yes
# Use this only when you downloaded the list of primary root servers!
# If you use the default dns-root-data package, unbound will find it automatically
#root-hints: "/var/lib/unbound/root.hints"
# Trust glue only if it is within the server's authority
harden-glue: yes
# Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
harden-dnssec-stripped: yes
# Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
# see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details
use-caps-for-id: no
# Reduce EDNS reassembly buffer size.
# Suggested by the unbound man page to reduce fragmentation reassembly problems
edns-buffer-size: 1472
# Perform prefetching of close to expired message cache entries
# This only applies to domains that have been frequently queried
prefetch: yes
# One thread should be sufficient, can be increased on beefy machines. In reality for most users running on small networks or on a single machine, it should be unnecessar>
num-threads: 1
# Ensure kernel buffer is large enough to not lose messages in traffic spikes
so-rcvbuf: 1m
# Ensure privacy of local IP ranges
private-address: 192.168.0.0/16
private-address: 169.254.0.0/16
private-address: 172.16.0.0/12
private-address: 10.0.0.0/8
private-address: fd00::/8
private-address: fe80::/10
Restart and verify the running service:
sudo systemctl restart unbound
sudo systemctl status unbound
Since the DNS from Unbound is now running on port 5335, use this command to test it:
dig pi-hole.net @127.0.0.1 -p 5335
And since DNSSEC validation is turned on, you should see the “ad” flag for a DNSSEC signed FQDNs, while a “SERVFAIL” for DNSSEC errors:
Use this DNS service within Pi-hole by enabling it in this way:
Including More Lists Automatically
Right now you are using one single ad-list on your Pi-hole. While that’s a good starting point, you definitely want to add some more lists. Note that once a list is added, Pi-hole will automatically update the list entries. What we are doing right now is to automatically add more lists in general. Two steps are required for this: 1) A script that checks a “list of lists” in order to add them into the Pi-hole. I am using this: pihole-updatelists:
Enabling and starting pihole-updatelists.timer...
Created symlink /etc/systemd/system/timers.target.wants/pihole-updatelists.timer /etc/systemd/system/pihole-updatelists.timer.
That is: it installs a timer that runs once a week in order to update the lists.
2) Adding a “list of lists”. You first have to choose such a list. Keep in mind that you must trust the source of this list! I have chosen “The Firebog” project which lists some lists out of the following categories: suspicious, advertising, tracking & telemetry, malicious. With the following list, all the lists that are checked (ticked) from their site are listed: https://v.firebog.net/hosts/lists.php?type=tick. Haha, how many times have I said “lists”? ;)
Add this “list of lists” to the pihole-updatelists configuration like this:
That’s it. You can either wait till next Saturday to have it updated, or you do it manually for this first time (of course!) with the following command:
pihole-updatelists
After that you’ll see some more configured adlists at Group Management -> Adlists:
While the “Domains on Blocklist” counter at the upper right should increase significantly as well. In my case, it’s greater than 250.000 entries. Nice!
Miscellaneous
By the way: Don’t forget to change your DHCP settings on your router to use the Pi-hole as the DNS server. ;) Here’s what it looks like on an AVM Fritzbox (IPv4 and IPv6) and on a Ubiquiti UniFi network:
Here’s a little pitfall I ran into at least two times: If your Pi has no valid time (e.g. when it was offline for a couple of days), while you’re using DNSSEC (as I do!), you’ll have a chicken-and-egg problem. The NTP service won’t be able to lookup its NTP server addresses because of DNSSEC failures (due to the wrong time), while DNSSEC will never be able to validate DNS responses unless NTP corrects the local time. Arg! The only way to solve this is to manually correct the time on the pi with:
sudo date-s'2021-01-04 13:04:00', click for details. If you’re interested in the DNSSEC validation process on the Pi-hole, read this: “Understanding DNSSEC validation using Pi-hole’s Query Log“.
Final tip: I recommend the free Pi-hole Remote App for iOS. It works like a charm and is completely ad-free. Wow. You can donate through in-app purchases, though, which I recommend as well. Here as some screenshots:
I’m ending this story with a screenshot from my Pi-hole dashboard. I really like it:
I wish you a blessed Christmas. Jesus is born <- that’s what Christmas is all about!
During the last weeks, I had an interesting request to publish NTP servers to client systems by using DHCPv6 in an IPv6 only network. Our Fortigate (or me?) had to learn how to publish the information. Hence this post is not only about NTP and IPv6, but a small guide on how to walk through RFCs and how to get out the relevant information. I’m very happy I got the possibility to share my experience here. Thank you, Johannes!
It started with a small question from my co-worker: “Can you send our NTP servers with DHCP in the IPv6 only network?” And my first idea was: “I’m sure, I can configure this within of minutes.” But 10 minutes later I had to change my mind: it takes me more time to understand how I have to configure this. The simple reason for this is the missing option in the system configuration, the vendor didn’t implement (yet)…
I will show how to manage this with a FortiGate (FortiOS 6.0.14, there is no newer version available for this model) operating as a DHCPv6 server. At the time of beginning, the DHCP6 server configuration looks like this:
config system dhcp6 server
edit 641
set rapid-commit enable
set lease-time 3602
set domain "example.com"IP
set subnet 2001:db8:c:641::/64
set interface "IPv6only-01"
config ip-range
edit 1
set start-ip 2001:db8:c:641::6401
set end-ip 2001:db8:c:641::64ff
next
end
set dns-server1 2001:db8:c:a53::53
set dns-server2 2001:db8:c:b53::53
next
end
As you can see, the DHCPv6 server is configured to publish a domain name and two DNS servers for recursive name resolution. Further on there’s an IPv6 range for stateful DHCPv6. But FortiOS didn’t allow me to configure the NTP server directly. But it allows me to send three self-defined options in DHCPv6:
config system dhcp6 server
edit < id >
set option1 {string} Option 1.
set option2 {string} Option 2.
set option3 {string} Option 3.
next
end
Could this be the way to fulfil my co-worker’s request? And how to create the {string} to send an IPv6 address or hostname to the client system? Having a look at the CLI of the FortiGate:
config system dhcp6 server
edit < id >
(server) # set option1 ?
< option-code > [< options >] options must be even number of hexadecimal characters(optional)
This information didn’t help me. Now it looks like nothing else than reading RFCs helps. :-(
Digging through RFCs
In the list of FortiOS 6.0 supported RFCs, RFC 3315 is mentioned. But in RFC 3315 is no useful information about NTP… Reading the new RFC for DHCPv6, RFC 8415, you can find in section 24 a list of DHCPv6 options and the link to the complete list of DHCPv6 parameters assigned by IANA. Looks like that’s the information I need.
There is an option with the name “NTP Server”, number 56 (decimal), but the information about the order and possible values are somewhere else: in RFC 5908.
In RFC typical style there (RFC 5908 on page 4) you can find the required format of the option to send NTP-server information to the client system:
The format of the NTP Server Option is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_NTP_SERVER | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| suboption-1 |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| suboption-2 |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| suboption-n |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_NTP_SERVER (56),
option-len: Total length of the included suboptions.
For the ones who never had the need to read something like this, a few hints which helped me:
The headline of the “table” are the bits, starting from 00 to 31 = 32bit.
The field OPTION_NTP_SERVER is a 16-bit value and the field option-len is a 16bit value, too.
The next fields suboption-1, suboption-2 to suboption-n has, at this point, no fixed length; but at least 32bit. This is because there is a pipe character on the left and right side, that indicates: this line is required. The next line, which has a colon at both sides, tells us it has a variable length, 0 or more lines.
To find the next piece of the puzzle, we continue reading the next page in RFC 5908 (page 5). Here we find how to format the sub-options:
The format of the NTP Server Address Suboption is:
The field NTP_SUBOPTION_SRV_ADDR is a 16-bit value and the field suboption-len is a 16bit value, too.
The next field (IPv6 address of NTP server) has a fixed length of 128 bit (4 lines with 32 bit). I hope you already expected this length. :-)
OK, we try to understand the information we have until now: We have to set the option number for the NTP server, which is 56 (dec) and 0x38 (hex). The NTP_SUBOPTION_SRV_ADDR has a sub-option code of 1 (0x0001 as 16bit hex value) and a suboption-length of 16 octets (if it is easier for you: 16 bytes). Then we have to put in the IPv6 (unicast-) address of the server. We take 2001:0db8:2800:0000:0000:0000:0ac3:0123 as an example. In the end, we calculate the complete length of the option and put the value in the field option-len:
2 octets for the NTP suboption field
2 octets for the NTP suboption length
16 octets for the NTP IPv6 server address
In summary 20 octets (0x14 in hex) is the calculated value for the field option-len. If we put in all the data, the fields look like this:
But in FortiOS this is different than expected (by me?): we don’t have to calculate and put in the option-length here! We just need the option code (in decimal = 56) and the option value in hexadecimal characters as in the following line:
(server) # set option1 56 '0001001020010db828000000000000000ac30123'
NTP_SUBOPTION_SRV_ADDR | |
suboption-lenght | IPv6 unicast address of NTP server
It took me a few hours with Wireshark to realize this…
Publishing FQDNs
My co-worker was quite happy about my phone call with the good news. But: is publishing an IPv6 unicast address a good solution for the future? I decided no, I want to publish an FQDN.
Now, as I did understand the format of the NTP-server option, I had a look for how to publish the name of the NTP server. For this we have to read section 4.3 on page 6 of RFC 5908. The format of the NTP Server FQDN Suboption is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP_SUBOPTION_SRV_FQDN | suboption-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| FQDN of NTP server |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
suboption-code: NTP_SUBOPTION_SRV_FQDN (3),
suboption-len: Length of the included FQDN field,
FQDN: Fully-Qualified Domain Name of the NTP server or SNTP server.
This field MUST be encoded as described in [RFC3315],
Section 8. Internationalized domain names are not allowed
in this field.
Let’s have a try to send the hostname 3.de.pool.ntp.org to the client systems.
The FQDN must be encoded as described in section 8 of RFC 3315. The few lines there tell us to read section 3.1 of RFC 1035 but MUST NOT use the compressed form as described in section 4.1.4 of RFC 1035. And we MUST NOT use an IDN (internationalized domain name)!
This is how encode the hostname 3.de.pool.ntp.org based on section 3.1 in RFC 1035: First of all, we have to specify the length of the next part of the hostname (also called: label):
one character which results in value 1 (0x01) followed by the ascii-code of the character 3: 0x33.
Repeat this for the next label: length of 0x02 followed by 0x6465 for de
For the next label: length (4 octets) and the word pool results in data 0x04706f6f6c
And so on: length (3 octets) and data are 0x036e7470 for ntp
One time similar again: length (3 octets) and data are 0x036f7267 for org
And now, very important: notification for end of hostname: 0x00
I repeat the whole hexadecimal characters (separated with space characters for a better understanding):
01 33 02 6465 04 706f6f6c 03 6e7470 03 6f7267 00
3 . d e . p o o l . n t p . o r g
This is the FQDN for the NTP suboption. Now we have to calculate the length of the suboption: 19 octets, 0x13 in hex.
My line for configuring the hostname 3.de.pool.ntp.org in FortiOS looks is this one:
(server) # set option2 56 '00030013013302646504706f6f6c036e7470036f726700'
suboption type = FQDN | |
suboption length = 19dec = 0x0013 | FQDN as described a few lines above
Do you want to publish two FQDNs? For example 2.de.pool.ntp.org and 3.de.pool.ntp.org? No problem, just do it:
(server) # set option2 56 '00030026013202646504706f6f6c036e7470036f726700013302646504706f6f6c036e7470036f726700'
But this wasn’t a good solution for my co-worker. He was not able to configure his client with the information I sent by DHCPv6. (Please don’t ask me for details!) Next, he asked me to send the SNTP address.
What about SNTP?
A fast search and I found the next interesting RFC with the name Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6: RFC 4075. Looking on page 2:
The format of the Simple Network Time Protocol servers option is as
shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_SNTP_SERVERS | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SNTP server (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SNTP server (IPv6 address) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_SNTP_SERVERS (31)
option-len: Length of the 'SNTP server' fields, in octets;
it must be a multiple of 16
SNTP server: IPv6 address of SNTP server
SNTP is option code 31, FortiOS is calculating the option length itself, we just need the IPv6 unicast (only unicast?) address of the SNTP server
(server) # set option3 31 '20010db828000000000000000ac30123'
Do you want to publish two SNTP servers? No problem, do it like this:
(server) # set option3 31 '20010db828000000000000000ac2012320010db828000000000000000ac30123'
FortiOS and RouterOS Configuration
Today, the DHCP6 server configuration of the FortiGate looks like this:
config system dhcp6 server
edit 641
set rapid-commit enable
set lease-time 3602
set domain "example.com"
set subnet 2001:db8:c:641::/64
set interface "IPv6only-01"
set option1 56 '0001001020010db828000000000000000ac30123'
set option2 56 '00030013013302646504706f6f6c036e7470036f726700'
set option3 21 '20010db828000000000000000ac30123'
config ip-range
edit 1
set start-ip 2001:db8:c:641::6401
set end-ip 2001:db8:c:641::64ff
next
end
set dns-server1 2001:db8:c:a53::53
set dns-server2 2001:db8:c:b53::53
next
end
FortiOS in 6.0.14 allows only 3 custom values, I can’t publish more custom options. One more feature request to Fortinet: please allow more (maybe 9?) custom options here. :-)
In the same way, it’s possible to publish other information with DHCPv6, if the operating systems of the server allow the administrator to publish custom values in DHCPv6. In some operating systems, at the time of writing these lines, it’s the only way to send even basic information to a client system. For example, if you have to do a similar configuration in MikroTik RouterOS (tested with 6.48.5), it looks like this:
In my experience, RouterOS is sending only requested options, other than FortiOS. In RouterOS, we don’t have to calculate the length of the DHCPv6 option, too.
Please always keep in mind: if you don’t send at least the other-flag in RA packets, most client systems don’t try to get DHCPv6 information from the network.
Some months ago, my co-worker and I ran into an interesting issue: a notebook with a newly installed Ubuntu 20.04 does only work with IPv4, but this office network is dual-stacked (IPv4 and IPv6). Other Linux clients as well as Windows and Mac systems still work fine. They all get an IPv4 configuration by DHCPv4 and an IPv6 configuration by stateful DHCPv6 from the same DHCP server, relayed by a Cisco ASA 5500-X. What’s wrong with Ubuntu 20.04?
Our first idea was, that we forgot to activate global IPv6 during installation. But it was enabled. Our next idea was an active local firewall that blocks DHCPv6 packets or IPv6 in general. This is a frequent problem because DHCPv6 is using UDP ports 546 and 547. But the same notebook at a home network works fine with IPv6 and IPv4. We had to look at our network…
In this network, a Cisco ASA is acting as the default router to the internet. It’s also acting as a DHCP relay system for IPv4 and IPv6 to forward DHCP packets of the clients to the central DHCP server and back. But the DHCPv6 server didn’t get a SOLICIT message from the client; DHCPv4 works.
Some log lines from the ASA got out attention:
DHCPv6: Bogus option CLIENTID(1), len 18
IPv6 DHCP_RELAY: Discard SOLICIT with invalid or no options
At this time we didn’t understand the log lines. Because we had no better idea, we decided to activate some debug commands at our ASA:
Maybe that’s a few commands too much, but we wanted to get a hint of what we are doing wrong. Less than 100 seconds later we got the following lines:
8410825.8800: DHCPv6: Received SOLICIT from fe80::3afd:e025:f6b:75d9 on vlan6
8410825.8800: IPv6 DHCP: detailed packet contents
8410825.8800: src fe80::36fc:a6d5:f6b:75d9 (vlan6)
8410825.8800: dst ff02::1:2
8410825.8800: type SOLICIT(1), xid 4903931
8410825.8800: option RAPID-COMMIT(14), len 0
8410825.8800: option IA-NA(3), len 12
8410825.8800: IAID 0x2d1aa133, T1 0, T2 0
8410825.8800: option UNKNOWN(39), len 10
8410825.8800: option ORO(6), len 8
8410825.8800: DNS-SERVERS,DOMAIN-LIST,UNKNOWN,SNTP-ADDRESS
8410825.8800: option CLIENTID(1), len 18
8410825.8800: 0004xxxxxxxxxxxxxxxxxxxxxxxxxxxxFDA2
8410825.8800: option ELAPSED-TIME(8), len 2
8410825.8800:
8410825.8800: IPv6 DHCP_RELAY: DHCPD/RA: Message received from cluster module
8410825.8800: DHCPv6: Bogus option CLIENTID(1), len 18
8410825.8800: IPv6 DHCP_RELAY: Discard SOLICIT with invalid or no options
This tells us: there is a client that wants to get an IPv6 configuration (solicit) but the ASA decides the DHCPv6 client ID with a length of 18 octets is wrong. Because of this, the ASA throws away the solicit message.
OK. Now we know the device which causes the problem. But what’s wrong?
We searched around and found, Cisco knows this issue: ASA dropping DHCPv6 SOLICIT from Unix-based systems (unfortunately only accessible with a Cisco Account). They recommend a workaround: “Modify the client UUID to use UUID of 1”. We had no idea why changing the system UUID should be a way to get DHCPv6 working…
Now we had a more detailed look at the messages we got in the ASA console. There we saw from Windows system lines like this:
8411325.7600: option CLIENTID(1), len 14
8411325.7600: 0001000126C41D660050568FADC3
The Ubuntu system causes these lines:
8411955.8800: option CLIENTID(1), len 18
8411955.8800: 000416BD597F6092FBB0866BC7B6E23DFDA2
Some more hours later we understood the issue like this: Cisco implemented the relaying of DUID types 1-3, [not UUID!] defined in RFC3315 (July 2003), but not the additional DUID type 4, defined in RFC6355 (August 2011). And we get the hidden hint from Cisco for their workaround: change the DUID (DHCP unique identifier) to a type 1 DUID.
For Ubuntu Linux we didn’t find a (for us working) way the change DUID type to 1; but in a new Debian 10 installation of another co-worker, we run in a similar issue. After installation the system used a DUID type 4, too:
For the Debian Linux system, we found the workaround: we delete the lease file and create a new one with a DUID type 1 (DUID-LLT = link-layer address plus time ).
Of course, you can use a DUID type 2 (vendor-assigned unique ID based on Enterprise Number) or DUID type 3 (link-layer address), too.
This is just a workaround for a network with less affected clients. If you have to publish this solution for a large bring-your-own-device (BYOD) network with many affected clients: Have fun!
If someone has a hint on which file we need to change or delete at Ubuntu Linux, please write a few lines about it in the comments. Thanks!
At the time of writing these lines, there is an update at the Cisco case which indicates that there should be a new version of the ASA operating system which should fix the DUID type 4 issue of the DHCPv6 relay agent. We are looking forward to get the new version, maybe in a few years. :-)
Ich durfte zu Gast bei der #heiseshow zum Thema IPv6 sein. In Anlehnung an die Artikelserie über IPv6 in der c’t 7/2022, in der auch mein Artikel über die Vorteile von IPv6-Adressen erschienen ist, ging es bei diesem Video-Podcast um gängige Fragen zu IPv6 sowohl im Heimanwender- als auch im Enterprise-Segment. Ne knappe Stunde lief die Schose und ich empfand es als ziemlich kurzweilig. ;)
Lange Rede, wenig Sinn – hier ist der Podcast:
Natürlich war es keine didaktisch ausgearbeitete Grundlagenschulung für IPv6, sondern mehr ein fröhliches Durcheinander an Fragen und Antworten – wie es sich für einen Podcast nunmal gehört. Ich hoffe, ihr hattet Spaß beim Anschauen.Wer noch Fragen hat, kann sie gerne auch hier stellen. Ich gebe mir Mühe, alle zu beanworten.
Apropos Fragen und Antworten: Kommentare gab es sowohl bei meinem Artikel auf heise+ als auch bei der #heiseshow Seite als auch auf YouTube zuhauf – teilweise mehrere Hundert. Davon sind natürlich nicht alle fachlich ernstzunehmen, aber zumindest ist etwas Regung drin. Sehr gut!
An analysis of some falsified leap second warnings that appeared in November 2021 on public NTP servers out of the NTP Pool Project.
Introduction
When using time scales such as UTC that do not use daylight saving time, each day has a strict 60 x 60 x 24 = 86400 seconds pattern. But due to variation in the earth’s rotation, the last day of a month may have 86399 or 83401 seconds; these are caused by negative/positive leap seconds. Leap seconds are announced by IERS six months prior to the event. All previous leap seconds have been positive and occurred on the last day of December or June. The most recent leap second as of now occurred on December 31, 2016.
Unexpected Leap Second Warning
On November 27, 2021, several public Network Time Protocol (NTP) servers began advertising “LI=1” (leap indicator), meaning that a positive leap second is coming at the end of the day. This was odd since no leap second was scheduled during 2021. Leap seconds normally occur only at the end of June 30 or December 31, UTC. Of the thousands of NTP servers I am monitoring, none had been advertising LI=1 in recent months.
But this wasn’t the end of the warnings. At 2021-11-30 00:00 a largely different set of NTP servers began sending LI=1. Some NTP software keeps an internal leap-second-pending flag and delays leap second processing until the last day of the current month. Following is the count of NTP servers as recognized by my monitoring system:
2021-11-27 LI=1 warning:
72 servers total
53 stratum 1 (all indicated reference ID=GPS); LI=1 was steady when it occurred
17 stratum 2
2 stratum 3
2021-11-30 LI=1 warning:
86 servers total (stratum varied for some servers)
A number of servers had leap indicators that changed from 0 to 1 and back again. Only four stratum 2 NTP servers were common in the November 27 and November 30 sets.
Leap Second Execution
In addition to signalling a pending leap second, many of these servers actually performed the positive leap second procedure; the last minute of the day had 61 seconds. This caused a 1-second time of day difference from actual UTC.
2021-11-28 00:00:00: For most of these NTP servers, the error was corrected after 1 second; during the one-second interval, the time-of-day was frozen at 00:00:00. Eight servers were in error by 1-second for between two and eight minutes. The 1-second error persisted on one server for 00:39:26.
2021-12-01 00:00:00: The duration of the 1-second time of day difference was generally longer, persisting for up to 01:22:31.
Affected Clients
As part of a study on unwanted high-rate NTP request bursts, client NTP requests were regularly recorded on several NTP servers including the client’s leap indicator.
NTP Server Location
Fraction of NTP clients sending LI=1
just before 2021-12-01 00:00 UTC
(based on one 20 minute sample for each server)
Wellington, NZ
0.025% overall, 130 clients affected
San Francisco, US
0.294% overall, 7011 clients affected
London, UK
0.635% overall, 4791 clients affected
All three of these servers had LI set to 0, which is correct. It seems that clients with LI=1 were using one or more of the affected NTP servers.
The New Zealand server was continuously collecting logs which allowed the number of LI=1 clients to be tracked throughout these two days.
Miroslav Lichvar (who maintains chrony) commented: “I suspect the actual percentages were likely even larger as most clients don’t put their leap state in their requests.“
Common Thread – Impacted NTP Servers
Among the NTP servers advertising LI=1 on 2021-11-27 was one of my home servers, an inexpensive, high-performance stratum 1 LeoNTP. This was seen on Twitter:
⏲️ LeoNTP users – please update FW to v1.24 to avoid erroneous Nov 2021 leap second warning: https://t.co/gvbF90VLgF Ublox GPS chipset we use [incorrectly] reports leap second event date as GPS week 2185 (Nov 2021) instead of 1929 (Dec 2016.) pic.twitter.com/ZWEkuAB5U2
Upon applying the new firmware my LeoNTP server correctly set LI=0.
At least 42 of the Stratum 1/GPS servers advertising LI=1 on 2021-11-27 were LeoNTP units. Little is known about the other 16. None of these servers showed incorrect behaviour on 2021-11-30.
I estimate that these 42 LeoNTP servers were receiving in excess of 30,000 requests/second on 2021-11-27. These servers were likely providing time to hundreds of thousands and possibly millions of clients, all were being told that a leap second was coming. It isn’t known how many of those clients executed a leap second on 2021-11-28 00:00:00. The detailed server logs indicate that a number did execute the leap second and were in error by one second for some minutes.
Event Summary and Fallout
November 27, 2021:
53 NTP stratum 1 servers, including 42 LeoNTP units, begin advertising LI=1. A fix was available from the manufacturer but was not installed on many public servers.
At midnight (2021-11-28 00:00:00), most of these servers incorrectly executed a leap second procedure resulting in a short (typically one second) time of day error.
The number of clients executing an unplanned leap second procedure is unknown.
November 30, 2021:
86 NTP servers, largely different from the November 27 set, began advertising LI=1 at various times during the day. The leap indicator was erratic on some servers.
At midnight (2021-12-01 00:00:00), many of the servers executed an unwanted leap second procedure. A one-second time offset was present for up to 1.3 hours.
The number of clients executing an unplanned leap second procedure is unknown.
A few messages were exchanged in Time-nuts and NTP mailing lists. Otherwise, this event apparently passed unnoticed.
Déjà Vu
The erroneous leap second warning was anticipated.
The most recent leap second was 2016-12-31 (MJD 57753). 8 bits or 256 weeks later […] will be 2021-11-27 (MJD 59545). So shortly before, on, or after that date it is possible a faulty GPS receiver will misrepresent a leap second or miscalculate UTC.
Just a few weeks ago on 27 November 2003 a 256-weeks-since-the-last-leap-second timing glitch occurred in some GPS receivers. […] Fortunately, because the hour was 62 o’clock, simple error checking in any host software would reject the erroneous message.
The November 2021 incident had only a 1-second error and was simply accepted by many NTP clients.
Background: Leap Second Dissemination
Leap seconds typically occur on the last day of June or December. Leap seconds can occur in other months, but that has never happened. Bulletin C, published by the International Earth and Rotation Reference Systems Service (IERS) twice per year, gives the upcoming leap second status. The last leap second was December 31, 2016. No leap second was announced for 2021.
Upcoming leap second announcements are redistributed via GPS, NIST’s WWV/WWVB and ACTS service, PTB’s DCF77 and other mechanisms, including NTP. Rather than depending on possibly noisy upstream sources, many use a leap second table as a definitive source of past and upcoming leap seconds.
Leap seconds can only occur on the last day of a month, some NTP software does not enforce that rule.
Leap seconds have triggered many problems. Apparently the impact of the errant November 2021 leap second was insignificant. There is strong sentiment for eliminating leap seconds but the required decisive action has not happened.
Angreifer verwenden gern Ping und Traceroute, um Server im Internet ausfindig zu machen. Das bringt viele Security-Admins in Versuchung, den Ping- und Traceroute-Verkehr mittels ihrer Firewall in ihrem Netz zu unterbinden. Doch damit behindern sie nur die Arbeit von Server-Administratoren, denn es gibt noch viel mehr Möglichkeiten, Server aufzuspüren.
Diesen Artikel habe ich initial für die c’t geschrieben, wo er im Heft 04/2018 erschienen ist. Als Autor habe ich dankenswerterweise die Erlaubnis, ihn hier auf meinem Blog ebenso zu veröffentlichen. Eine Übersicht der von mir geschriebenen c’t Artikel gibt es hier.
Die Kommandozeilen-Tools Ping und Traceroute, die zu jedem modernen PC-Betriebssystem gehören, sind sowohl bei Angreifern als auch bei Server-Administratoren beliebte Werkzeuge – sie lassen sich leicht über Skripte automatisieren und liefern so in kurzer Zeit einfache Antworten auf die Frage: Läuft unter einer bestimmten IP-Adresse ein Server oder nicht? Wenn ja, dann sind Server-Administratoren zufrieden, während Angreifer die Ärmel hochkrempeln, um den Server näher zu untersuchen und möglichst zu übernehmen.
Genau Letzteres wollen Security-Admins unterbinden und manche richten dann eine vermeintliche Totalblockade ein: Sie unterbinden mittels Firewall-Regeln jeglichen Ping- und Traceroute-Verkehr zum und vom Server. Doch das sind Placebo-Regeln – sie beruhigen lediglich, ohne die Sicherheit zu erhöhen und behindern aber das Monitoring des Servers. Denn öffentliche Server lassen sich auch ohne Ping leicht identifizieren.
Dafür gibt es eine Handvoll von Universal- und Spezialwerkzeugen, deren Konzepte und Funktionen wir detailliert vorstellen. Wir stellen Ping und Traceroute an den Anfang, weil sich darüber grundlegende Konzepte am einfachsten erklären lassen. Danach folgen Monitoring-Tools auf Applikationsebene, für die Traceroute mit etwas Know-how ebenfalls nutzbar ist. Alle optionalen Tools finden Sie über ct.de/y8pp.
Ping- und Traceroute-Grundlagen
Der Ping-Befehl ist ein simples Tool, mit dem sich die Netzwerkverbindung zu einem Gerät testen lässt. Die Anfrage des Senders (Echo Request) und die Antwort des Empfängers (Echo Reply) sind in der Protokollspezifikation RFC 792 definiert (Internet Control Message Protocol, ICMP). Wenn der Absender des Ping-Kommandos ein Reply-Paket vom Zielsystem erhält, bedeutet das, dass die Netzwerkstrecke zur angefragten IP-Adresse funktioniert. Zudem liefert Ping die Signallaufzeit für den Hin- und Rückweg. Die Laufzeit (Latenz) ist ein einfaches Maß für die Reaktionsgeschwindigkeit des Servers. Je kürzer die Latenz, desto zufriedener der Admin und die User.
Auf Windows- und Unix-Systemen lautet der Befehl schlicht
ping. Darauf folgt die Zieladresse, also beispielsweise
ping heise.de. Der Befehl gibt pro Antwortpaket eine Zeile aus. Darin sind die Signallaufzeit in Millisekunden sowie die Anzahl der Zwischenstationen auf dem Pfad zum Ziel aufgeführt (Hops bei IPv6, TTL bei IPv4, siehe Kasten „Unterschiede zwischen IPv6 und IPv4“).
Wenn auf Windows und Linux beide Internet-Protokolle konfiguriert sind (IPv4 und IPv6, also Dual-Stack), schickt das Betriebssystem den Request per IPv6 ab. Mit den Optionen
-6 und
-4 erzwingt man eines der beiden Protokolle. Ältere Linuxe nutzen von Haus aus IPv4; für Pings per IPv6 verwenden sie
ping6.
Der Windows-Befehl sendet in der Grundeinstellung vier Echo-Anfragen und stoppt dann. Der Linux-Befehl schickt Anfragen kontinuierlich, bis man ihn mittels Strg+C beendet. Alternativ lässt sich die Anzahl mit der Option
-c begrenzen (z. B.
ping -c 3 für genau drei Pings).
Wenn man auf Ping-Requests keine Antworten erhält, ist es zunächst offen, woran das liegt. Möglicherweise antwortet der Host nicht, aber es ist auch nicht auszuschließen, dass eine Firewall auf der Strecke zum Ziel den ICMP-Request nicht durchlässt. Das kann man mit dem Tool Traceroute genauer untersuchen. Traceroute nutzt den IP-Parameter Hop-Limit (bei IPv4 Time To Live, TTL genannt), um Antworten von bestimmten Routern zu erhalten, die den Pfad zum Host bilden.
Auf Windows lautet der Befehl
tracert, auf Linux und macOS
traceroute; danach folgt die Zieladresse. Der Windows-Befehl nutzt für die Pfadanalyse normalerweise ICMP-Pakete vom Typ Echo Request, also Ping-Pakete. Linux schickt hingegen UDP-Pakete mit Zielports ab 33434 aufwärts. Setzt man die Option
-I, schaltet man auf Linux auf den Versand von ICMP-Echo-Requests um. Dafür sind Root-Rechte erforderlich.
Eigentlich ist das Hop-Limit als Schutzfunktion und Warnmechanismus gedacht: Falls Netzbetreiber versehentlich eine Routing-Loop konfiguriert haben, würden Pakete, die in der Loop landen, sinn- und endlos darin kreisen. Deshalb werden IP-Pakete normalerweise mit einem Hop-Limit von zum Beispiel 64 oder 128 auf die Reise geschickt und jeder Router, der es empfängt, muss das Hop-Limit um 1 dekrementieren, bevor er es weiterreicht. Ist Hop-Limit 0 erreicht, darf ein Paket nicht weitergereicht werden, der Router muss es verwerfen. Zugleich sollte er den Absender des Pakets darüber mit der ICMP-Meldung „Time Exceeded/Hop Limit exceeded“ informieren. Ein Netzwerk-Admin kann dann anhand der Fehlermeldung der Ursache auf den Grund gehen.
Traceroute setzt das Hop-Limit ein, um Antworten von Routern auf dem Pfad zum Zielsystem zu erzwingen, die ein IP-Paket normalerweise stillschweigend weiterreichen. Dafür schickt der Befehl mehrere IP-Pakete zum Ziel. Er startet mit Hop Limit 1 und inkrementiert den Wert schrittweise um 1. Der erste Router, der das Paket mit dem Hop-Limit 1 empfängt, dekrementiert das Hop-Limit und muss es gleich verwerfen und dem Absender „Time Exceeded“ melden. Traceroute findet in der Antwort die IP-Adresse des ersten Routers und führt diese oder den DNS-Namen, den es per Reverse-Lookup zu ermitteln versucht, mitsamt der Latenzangabe in einer Zeile der Ausgabe auf.
Mit dem zweiten Paket (Hop-Limit 2) wird der zweite Router veranlasst, eine Fehlermeldung zu schicken. So geht es weiter, bis das Ziel erreicht ist. Pro Hop-Limit sendet Traceroute typischerweise drei Pakete.
Traceroute in Wireshark-Ansicht: Mit dem IP-Analyse-Tool sind neben dem Trace zu heise.de noch weitere IP-Details zu sehen, darunter etwa, dass das Hop-Limit-Feld nicht nur in den zum Ziel abgeschickten Paketen belegt ist, sondern auch in den Antwortpaketen der Router.
Im Beispiel „Traceroute in Wireshark-Ansicht“ ist das Ergebnis einer IPv6-Pfadanalyse zu heise.de im Netzwerkmonitor Wireshark zu sehen. Der Befehl sendet UDP-Pakete an Port 33434 (grau unterlegt). Darauf folgen die empfangenen Pakete (schwarz unterlegt). Quelle und Ziel (Source, Destination) der Traceroute-Pakete sind gleich, lediglich das Hop-Limit erhöht sich alle drei Pakete um 1. Die Antworten kommen per ICMPv6 und sind vom Typ „hop limit exceeded in transit“. Im Beispiel sind je drei dieser Meldungen von den ersten drei Routern entlang des Pfades zu sehen.
Detail am Rande: Auch die von den Routern gesendeten ICMPv6-Pakete haben ein Hop-Limit. Der erste und der dritte Router haben den Wert auf 64 gesetzt, der zweite auf 255. In der Ausgabe sind beim zweiten und dritten niedrigere Werte zu sehen (254 und 62), weil das Hop-Limit der Pakete unterwegs dekrementiert worden ist.
Wenn Traceroute innerhalb von 5 Sekunden keine Antwort von einem Router auf der Strecke erhält, markiert es diesen mit einem Stern (*). Diese Frist lässt sich mit der Option
-w ändern. Wenn ein Router keine Fehlermeldung schickt, kann das an drei Dingen liegen: Der Admin hat diese Funktion deaktiviert, die Management-Plane des Routers ist überlastet oder eine Firewall blockiert die entsprechenden Pakete.
Server und DMZ: Öffentliche Server sind in Firmen oft Teil größerer Netze und stehen aus Sicht des Breitband-Routers irgendwo im LAN und aus Sicht der Firewall in einer DMZ (Demilitarized Zone): So sind sie aus dem Internet erreichbar, aber per Firewall-Regel vom übrigen Verkehr im LAN abgeschottet. Die Absicht ist, den Schaden möglichst auf den Server zu begrenzen, falls er mal kompromittiert wird.
Applikations-Ping
Anstatt nur die IP-Verbindung zu einem Server zu prüfen (Schicht 3 im OSI-Modell), lässt sich auch der Server-Dienst mit einfachen Kommandos prüfen – das entspricht Pings auf Applikationsebene (Schicht 7 des OSI-Modells). Dabei verschickt ein Kommando echte Anfragen für einen Service, beispielsweise HTTP oder SMTP. Weil sich die Befehle über Skripte automatisieren lassen, lässt sich fortlaufend prüfen, ob etwa ein Webserver läuft, ohne in einem Browser wiederholt die F5-Taste zu drücken oder den Reload-Button zu klicken.
Die meisten Layer-7-Dienste setzen auf TCP oder UDP auf. Entsprechend verwenden auch die Tools TCP oder UDP. Weil UDP verbindungslos arbeitet, kann für den Test schon ein UDP-Paket genügen. Für TCP ist der übliche Drei-Wege-Handshake „SYN, SYN-ACK, ACK“ erforderlich.
Für den Test von Webservern ist das Tool
httping gebräuchlich. Es sendet im Sekundentakt HTTP-Requests an den Zielserver. Ohne weitere Optionen fragt es nur den Header des Wurzelverzeichnisses „/“ ab (HEAD).
Der Befehl ist in diversen Linux-Repositories enthalten, beispielsweise Ubuntu. Oft sind die dort enthaltenen Versionen veraltet, weshalb wir empfehlen, die aktuelle Fassung der Software manuell zu installieren (zurzeit ist das Version 2.6):
sudo apt-get install libncursesw5-dev libssl-dev libfftw3-dev gettext
git clone https://github.com/flok99/httping.git
cd httping/
make
sudo install
Mac-User finden httping über die optionalen Paketmanager MacPorts und brew. Windows-Versionen kann man von der Seite des Entwicklers beziehen.
Im Beispiel „Webserver-Test“ ist zu sehen, wie httping den Webserver heise.de prüft. In der Ausgabe liefert es zum Beispiel die Latenz und den aktuellen Statuscode des Servers (im besten Fall ist das „200 OK“). Pro Zeile baut das Tool eine vollständige TCP-Verbindung gefolgt von einem HTTP-HEAD-Request auf. Jede Antwort belegt, dass die Internetverbindung sowie der Webserver grundsätzlich funktionieren.
Webserver-Test: Mit httping testen Sie die Erreichbarkeit eines Webservers. Unter anderem lässt sich damit die Signallaufzeit ermitteln und der aktuelle Status des Webservers auslesen.
Um TLS-gesicherte Webseiten anzupingen, stellen Sie der Zieladresse https:// voran, beispielsweise
httping https://heise.de. Mit den Optionen
-s -Y lässt sich der HTTP-Status-Code farbig unterlegen.
Das Tool ist für gängige HTTP-Optionen ausgelegt. Es eignet sich auch für HTTP- und HTTPS-Verkehr über einen Proxy und kann die HTTP-Authentication prüfen.
HTTPS-Test: Mit dem optionalen Befehl https lassen sich Webserver auch TLS-gesichert ansprechen. Gut zu erkennen ist, dass der Verbindungsaufbau mehrere Schichten einbezieht, sodass weit mehr Traffic fließt als bei einem Ping-Test.
Bei einer TLS-Verbindung zu einem Webserver (siehe HTTPS-Test) gehen ganze 25 Pakete über das Internet. Zuerst läuft ein vollständiger TCP-Handshake ab (Phase 1, in Wireshark grau markiert), dann die TLS-Aushandlung (Phase 2). Dann wird der HTTP-Request gesendet (Phase 3). Zum Schluss baut das Tool die TCP-Sitzung ordnungsgemäß ab (Phase 4). Dennoch dauert ein Durchlauf bei gängigen Zielen in Deutschland nicht länger als 100 ms.
DNS-Server-Prüfungen
Mit dem in Python geschriebenen Tool
dnsping lässt sich die Erreichbarkeit und Grundfunktion von DNS-Servern per DNS-Anfrage prüfen (Query). In der Grundeinstellung befragt dnsping den ersten konfigurierten Resolver nach einem A-Record des angegebenen Hosts. In der Ausgabe führt das Tool die Latenzen auf. Für die Abfragen verwendet es DNS-gemäß UDP, sodass für Hin- und Rückweg je ein Paket genügt.
Dnsping ist Teil der „DNS Diagnostics and Performance Measurement Tools“, kurz DNSDiag. Für Windows und macOS sind Binaries auf GitHub erhältlich. So installieren Sie es auf Linux:
Für einen einfachen DNS-Ping an Ihren DNS-Resolver reicht die Angabe eines Hosts – etwa so:
./dnsping.py heise.de. Zusätzlich können Sie sich die DNS-Antwort ausgeben lassen
-v, den anzufragenden DNS-Resource-Record festlegen
-t <type> (standardmäßig A), den DNS-Server angeben
-s <server> oder das Internet-Protokoll bestimmen
-6/-4.
Das DNS-Protokoll kann alternativ TCP nutzen. Das ist bei Antworten erforderlich, die für UDP zu groß sind. Um eine TCP-Anfrage zu senden, setzt man die Option
-T. Kommt die erwartete DNS-Antwort an, heißt das, dass Firewall und DNS-Resolver DNS-TCP-Pakete durchlassen, also korrekt konfiguriert sind.
Verwenden Sie in Ihrem Netzwerk einen DNS-Resolver, so verifizieren Sie mit diesem Tool dessen Verfügbarkeit und ermitteln die (grobe) Latenz. Im Heimbereich stellt jeder Router einen solchen Resolver bereit. So prüfen Sie, ob er funktioniert:
./dnsping.py -s 192.168.xxx.1 ct.de
Der Parameter
-s 192.168.xxx.1 legt die IP-Adresse des Routers fest. Bei den verbreiteten Fritzboxen ist das normalerweise 192.168.178.1, bei Speedports 192.168.2.1.
Nach dem gleichen Muster lassen sich öffentliche DNS-Resolver wie Googles Public-DNS (2001:4860:4860::8888 bzw. 8.8.8.8) oder OpenDNS testen (2620:0:ccc::2 bzw. 208.67.222.222). Anhand der Antworten lässt sich die Geschwindigkeit der DNS-Server vergleichen. Schnelle DNS-Server sind vorzuziehen, weil je umfangreicher Web-Seiten sind, desto mehr DNS-Anfragen geschickt werden müssen. Und je eher die DNS-Antwort da ist, desto eher kann ein Browser die jeweilige IP-Adresse aufrufen.
Auch aus dem Internet erreichbare autoritative DNS-Server lassen sich per dnsping testen. Geben Sie als Ziel die öffentliche IP-Adresse des Servers an und fragen Sie ihn nach einer der Domains, die er selbst verwaltet. Beispiel: Für ebay.de ist der DNS Server „a1.verisigndns.com“ zuständig.
Ihr eigener autoritativer DNS-Server sollte aus Sicherheitsgründen nicht auf Anfragen für sonstige Domains wie „heise.de“ antworten, da er dann als öffentlicher DNS-Resolver missbraucht werden kann. Für die Prüfung der DNSSEC-Validierung von Resolvern gibt es im gleichen Toolkit das Kommando
dnseval. Weitere Details zu Tools aus der DNSDiag-Suite liefert die Webseite des Entwicklers (siehe ct.de/y8pp).
Mail-Server-Prüfungen
Um die Funktion eines SMTP-Servers fortlaufend zu prüfen, kann man das Kommando
smtpping verwenden. Das Kommando ist via GitHub für Windows, macOS und Linux erhältlich und verschickt wie ein Mail-Client komplette E-Mails, liefert aber zusätzliche Statusinformationen.
SMTP in Wireshark: Die Meldungen des smtpping-Tools sind rot dargestellt, die Antworten des SMTP-Servers in Blau. Das Testprogramm hat eine Mail mit dem Betreff „SMTP Ping“ eingereicht“.
Wenn Sie dieses Tool in ein Skript einbauen, sollten Sie keine kurzen Test-Intervalle festlegen, weil SMTP-Server das wie eine SPAM-Welle auffassen können – im Weiteren blockieren SMTP-Server die Mail-Annahme von derart aufgefallenen IP-Adressen (Gray- oder Blacklist). Ein Beispiel für einen SMTP-Test sieht so aus:
Der Parameter
-c <count> legt die Anzahl der Prüfungen pro Programmstart fest. Im obigen Beispiel sind es vier Durchläufe. Darauf folgen die Absenderadresse
-S <adresse> und die Empfängeradresse. Wird kein SMTP-Server per
@<server> angegeben, schickt das Tool die Mail an die Adresse, die im MX-Record der jeweiligen Empfänger-Domain eingetragen ist.
Damit ein SMTP-Test funktioniert, muss der testende Rechner eine statische öffentliche IP-Adresse verwenden. Mails, die von dynamischen öffentlichen IP-Adressen eingereicht werden, verarbeiten SMTP-Server normalerweise nicht. Das ist eine seit Langem übliche Vorkehrung gegen den SPAM-Versand von Malware-befallenen privaten Rechnern.
Falls der Test-Rechner über eine dynamische öffentliche IP-Adresse mit dem Internet verbunden ist, kann man ersatzweise SMTP-Relays als Vermittler verwenden. Dafür trägt man am Ende der Befehlszeile ein @-Zeichen gefolgt von der IP-Adresse des Relays ein (z. B. @198.51.100.10).
Mittels smtpping senden Sie eine komplette E-Mail an einen SMTP-Server. So lässt sich nicht nur die Verfügbarkeit prüfen, sondern auch die Geschwindigkeit messen. Bei der Anzahl der Testdurchläufe ist Vorsicht geboten.
Smtpping führt in seiner Ausgabe auch Antwortzeiten des SMTP-Servers für jede der SMTP-Kommunikationsphasen auf. Sie sind in sechs Abschnitte unterteilt (connect, helo, mailfrom … ). Eine ungewöhnlich lange Verarbeitungsdauer einer Phase kann ein Hinweis auf einen Fehler sein.
Traceroute-Spezialitäten
Manche Security-Admins sperren den Ping-Verkehr zu öffentlichen Servern, die in ihrer DMZ stehen. Näher besehen bringt diese Sperrung bei einfachen Firewalls keine Security-Vorteile, denn der Server lässt sich von außen dennoch leicht identifizieren.
Das geht per Layer-4-Traceroute (engl. Layer Four Traceroute, LFT). Dafür genügt es, ein Päckchen an einen spezifischen TCP- oder UDP-Port eines Servers zu schicken. Dabei handelt es sich tatsächlich um gängige TCP-SYN-Pakete, und schlichte Firewalls lassen sie daher passieren. So kann man einen TCP-Aufbau mit einem Webserver simulieren, indem man ihm ein Päckchen an Port 80 schickt – das sieht aus wie der Beginn einer Browsing-Session.
Das hat Folgen für die Sicherheit der Infrastruktur hinter dem Internet-Router: Wenn dahinter auf dem firmeninternen Pfad zum Webserver Router stehen, dann lassen sie sich anhand von Paketen identifizieren, deren Hop-Limit beim Empfang 1 beträgt. Sie müssen dann das Hop-Limit dekrementieren und im Normalfall dem Absender des Pakets mit „ICMP Time Exceeded“ antworten. Einfache, Port-basierte Firewalls erkennen in einem zurück zur Quelle wandernden ICMP-Päckchen keine Gefahr und lassen es passieren. So tröpfeln Informationen über den firmeninternen Routing-Pfad innerhalb der DMZ nach draußen.
Layer-4-Traceroute: Der Befehl verschickt pro Hop-Limit-Inkrement je drei TCP-SYN-Pakete an Port 443 der Zieladresse, hier www.heise.de.
Um solche speziellen Traceroutes zu starten, sind auf Linux Root-Rechte erforderlich. Mit der Option
-T schaltet man TCP ein,
-U steht für UDP. Einen Webserver spricht man auf Port 80 oder Port 443 per TCP an
-p <port>, einen DNS-Server auf Port 53 mit UDP. So testen Sie den HTTPS-Service von heise.de via IPv6:
sudo traceroute -6 -T -p 443 www.heise.de
Sie möchten den Routing-Pfad zu einem SMTP-Server ermitteln? Schicken Sie einen Layer-4-Traceroute auf den TCP-Port 25 des Servers und lassen Sie sich überraschen, welche Unterschiede im Vergleich zu einem herkömmlichen Traceroute auftauchen.
DNS und Man-in-the-Middle
Eine Besonderheit im Zusammenhang mit Traceroute stellt der DNS-Dienst dar. Wenn DNS-Anfragen und -Antworten wie üblich per UDP übertragen werden, findet kein Layer-4-Handshake statt. So lässt sich eine DNS-Anfrage in einem einzigen UDP-Paket stellen.
Entsprechend kann ein Router, eine Firewall oder ein Intrusion-Prevention-System nicht nur das UDP-Protokoll mit Zielport 53, sondern auch die DNS-Anfrage lesen (wird im Klartext übermittelt) und unliebsame Anfragen blockieren, wenn es der Diktatur gefällt. DNS-Antworten können zudem gezielt gefälscht werden, um etwa auf staatliche Warn-Seiten umzuleiten.
Solche Manipulationen kann man mittels speziellen Traceroutes aufdecken: Man verschickt DNS-Anfragen und schaut per Hop-Limit-Inkrement, wie sie behandelt werden. Neben dem Routing-Pfad zum DNS-Resolver lassen sich auch manche Man-in-the-Middle-Angriffe beziehungsweise DNS-Spoofing-Attacken aufdecken.
Manipulationen erkennt man daran, dass die DNS-Antwort nicht vom eigentlichen DNS-Resolver kommt, sondern von einem normalerweise transparenten Infrastruktur-Element, das auf dem Pfad vor dem Resolver sitzt.
Derartiges DNS-Spoofing kann aber auch gewünscht sein. So bieten moderne Firewalls und DNS-Appliances ein Feature namens „DNS Sinkholing“ an, bei welchem DNS-Anfragen an Malware-Domains gezielt mit einer Dummy-IP-Adresse beantwortet werden, um den Benutzer zu schützen.
Für solche speziellen Analysen enthält die Suite DNSDiag das Tool
dnstraceroute; auf Linux und Windows sind für die Ausführung Root-Rechte erforderlich. Testen Sie zuerst die Auflösung von gängigen Domains mit Ihrem üblichen DNS-Resolver:
sudo ./dnstraceroute.py heise.de
Wie bei dnsping kann man den zu befragenden DNS-Server mit der Option
-s <server> festlegen. Mit der Option
-t <type> wählen Sie aus, welchen Resource Record der DNS-Server liefern soll (A = IPv4-Adresse, AAAA = IPv6-Adresse, MX = Domain des Mail-Servers).
Grundlegende Firewall-Empfehlungen
Aus Security-Sicht ist eine globale Ping-Sperre im internen Netz unnötig bis schädlich. Der Nutzen des Ping-Befehls ist für Administratoren, die die Verfügbarkeit von Diensten gewährleisten sollen, sehr hoch. Zugriffe aus dem Internet in eine DMZ sind normalerweise erwünscht – aber es sollten nur Zugriffe auf die tatsächlich erforderlichen Ports erlaubt sein. Einem Layer-7-Ping steht ohnehin nichts im Wege und auch Layer-4-Traceroutes werden Antworten liefern, sofern Sie keine weiteren Vorkehrungen vornehmen.
Eine moderne Firewall kann einen TCP-Traceroute auf Port 443 von einem üblichen HTTPS-Verbindungsaufbau unterscheiden. Das ist die Grundlage, um das Ausspionieren von internen Routing-Pfaden zu unterbinden.
Daher dürfte die Security einer Firma nicht maßgeblich leiden, wenn ICMP-Pings von außen in die DMZ erlaubt sind. Es liegt auf der Hand: Wenn Ihr Webserver auf gängige HTTP- und HTTPS-Anfragen aus dem Internet antwortet, ist er ja ohnehin bekannt und ein ICMP-Ping verrät Angreifern nichts Neues. Das Gegenteil ist jedoch der Fall, wenn Ihr Server nicht über Standard-Ports erreichbar ist, sondern über spezielle, die nur bestimmte Nutzer kennen. Nur dann sollte man ICMP-Pings verbieten, weil sich dann ein verborgener Server mittels automatischer Abfragen schneller identifizieren lässt.
Zugriffe vom Internet in das LAN sind ohnehin tabu, egal ob für ICMP-Pings oder sonstigen Verkehr. Aber das haben Ihre Firewall-Administratoren hoffentlich schon immer so konfiguriert.
Neben klassischen Port-basierten Firewalls bieten „Next-Generation Firewalls“ zumindest für die Behandlung von Layer-4-Traceroutes sehr detaillierte Einstellungen. Beispielsweise erkennen sie sie unabhängig vom verwendeten Protokoll. Damit kann man sie einfach unterbinden und HTTPS weiterhin zulassen. Ein regulärer Web-Browser wird so Ihren Webserver wie gewohnt per TCP-SYN auf Port 443 erreichen. Ein Layer-4-Traceroute, der einen TYP-SYN auf Port 443 nur vortäuscht, scheitert hingegen. So bleiben interne Routing-Pfade von außen nicht einsehbar.
Unterschiede zwischen IPv6 und IPv4: Alle in diesem Artikel beschriebenen Tools können Sie sowohl für IPv6 als auch für IPv4 verwenden. Bei den damit erzeugten IP-Paketen gibt es aber Unterschiede.
Für die Anwendung der Tools spielt das zwar keine Rolle, sollten Sie jedoch spezifische Filter für tcpdump, Wireshark oder ähnliche Tools bauen, müssen Sie genau zwischen dem Standard-Internet-Protokoll (IPv6) und dem veralteten IPv4 unterscheiden: Während ein IPv6-Ping die ICMPv6-Typen 128 (echo request) und 129 (echo reply) verwendet, nutzt man bei IPv4 die ICMPv4-Typen 8 (echo request) und 0 (echo reply).
Auch unterscheiden sich die Time-Exceeded-Pakete, die Traceroute verwendet. Bei ICMPv6 sind diese vom Typ 3 Code 0, bei ICMPv4 handelt es sich um Typ 11 Code 0.
Außerdem wird das Hop-Limit nur in IPv6-Headern verwendet. In IPv4-Headern steht hingegen „Time to Live“ oder kurz „TTL“. Es ist auch gut, dass man sich bei IPv6 vom TTL-Begriff getrennt hat, denn er bezeichnet keine Zeiteinheit.
TCP- und UDP-Pakete sind hingegen bei IPv6 und IPv4 gleich. Beide verwenden grundsätzlich die Felder Source- und Destination-Port. Auch auf Applikationsebene gibt es keine Unterschiede. Ein HTTP-Request, der per IPv6 übertragen wird, sieht exakt so aus wie bei IPv4.
Haben Sie mal Netzwerkmitschnitte untersucht, ohne zu wissen, was genau Sie suchen? Mit Wireshark wird das leicht zu einer Odyssee: Das Analysewerkzeug filtert zwar fabelhaft, reagiert bei großen Datenmengen aber schnell zäh.
Was bei solchen Problemstellungen hilft ist: tshark! Ein Tool, mit welchem Sie auch große Packet Captures einfach anhand gängiger Kriterien durchforsten können.
Diesen Artikel habe ich initial für die c’t geschrieben, wo er im Heft 14/2019 erschienen ist. Als Autor habe ich dankenswerterweise die Erlaubnis, ihn hier auf meinem Blog ebenso zu veröffentlichen. Eine Übersicht der von mir geschriebenen c’t Artikel gibt es hier.
tshark ist ein Kommandozeilentool, das zu Wireshark gehört und dieselben Protokoll-Dissektoren mitbringt. So kann man Netzwerkmitschnitte (auch Traces oder Captures genannt) ebenso detailliert filtern wie mit Wireshark. Anders als dieses GUI-Werkzeug lässt sich tshark aber mit weiteren Shell-Tools verknüpfen, was ermöglicht, seine Ausgabe weiterzuverarbeiten. Das erleichtert beispielsweise, Verhaltensauffälligkeiten von Clients oder sporadisch auftretenden Fehlern auf die Spur zu kommen. Security-Beauftragte können auch prüfen, ob etwa eine Firewall anfällig für bestimmte Attacken ist.
Die Konzepte lassen sich leicht auch privat für allerlei Analysen nutzen, etwa um zu ermitteln, mit welchen Zielen im Internet das neue Smart-TV spricht. Mit den Ergebnissen speist man dann beispielsweise Filterlisten von Pi-hole & Co.
Am Anfang einer Analyse empfiehlt es sich, die in einem Trace steckenden Informationen auf das Wesentliche zu reduzieren: Man filtert nur die Inhalte bestimmter Paketfelder heraus und schreibt diese in eine neue Datei. Wie bei Wireshark lassen sich Informationen auch mittels der Display-Filter isolieren, denn tshark gibt sie zeilenweise im Terminal aus. Die Ausgabe sortiert man mit den Kommandos “sort” und “uniq”.
Voraussetzungen
Auf Linux bekommt man tshark als einzelnes Element per Paketverwaltung (Beispiel für Debian:
sudo apt-get install tshark). Windows- und macOS-Nutzer installieren tshark zusammen mit Wireshark vom Installations-Image des Herstellers.
Windows bringt zwar “sort” mit, aber “uniq” fehlt. Wenn Sie nicht ohnehin schon das Cygwin-Paket oder Microsofts Linux-Subsystem für Windows nutzen, können Sie sich deren Installation sparen: “uniq” steckt in der nicht mal 1 MByte kleinen Tool-Sammlung UnxUtils, die sich im Handumdrehen installieren lässt. Für ein natives Windows-Tool und gegen Microsofts Linux-Subsystem spricht übrigens auch, dass manche Backup-Programme derartige Installationen nicht sichern können.
Die UnxUtils wurden zwar letztmalig im Jahr 2003 aktualisiert. Zumindest uniq funktioniert aber auf Windows bis einschließlich Version 10. Laden und entpacken Sie das Archiv in den Ordner C:\Programme. Benennen Sie in diesem Verzeichnis die Datei sort.exe zu sort2.exe um, was Verwechslungen mit dem Windows-eigenen Befehl vermeidet. tshark liegt auf Windows typischerweise im Ordner C:\Programme\Wireshark. Auf macOS finden Sie tshark im Ordner /Applications/MacPorts/Wireshark.app/Contents/MacOS/tshark, auf Linux in /usr/bin.
Damit Sie auf Windows tshark und uniq ohne komplette Pfadangabe verwenden können, fügen Sie die zugehörigen Verzeichnisse den Windows-Umgebungsvariablen hinzu. Geben Sie im Startmenü die ersten paar Buchstaben von „Umgebungsvariablen für dieses Konto…“ ein und klicken Sie auf den Eintrag in der Trefferliste. Doppelklicken Sie im Bereich „Benutzervariablen“ auf das Feld „Path“ und fügen Sie die beiden Pfade nacheinander über die Buttons „Neu“ und „Durchsuchen“ hinzu (siehe Screenshot). Wenn Sie nun ein neues CMD-Fenster öffnen, sollten Sie tshark ohne Pfadangabe starten können.
Tastaturschoner: Die Kommandos von Wireshark und den UnxUtils lassen sich ohne vorangestellten Pfad aufrufen, wenn man diesen den Umgebungsvariablen hinzufügt.
Auf dem Mac genügt es, der Variablen PATH ein Unterverzeichnis des Wireshark-Ordners hinzuzufügen. Öffnen Sie dazu die Datei ~/.bash_profile mit einem Editor wie nano und ergänzen Sie diese Zeilen:
Unter Linux sind keine Pfaderweiterungen erforderlich.
tshark-Grundlagen
tshark steuert man mit einer Handvoll Kommandozeilenoptionen. Wir stellen kurz die wichtigsten vor und zeigen anschließend, wie man sie zu kompletten Befehlen zusammenfasst und mit weiteren Befehlen verkettet.
Wie Wireshark oder tcpdump kann tshark den ein- und ausgehenden Netzwerkverkehr Ihres PCs mitschneiden. Mit der Option
-i wählen Sie das Interface, dessen Verkehr Sie aufzeichnen wollen und mit der Option
-w Dateiname.pcap legen Sie die Ausgabedatei fest.
Fertige Aufzeichnungen kann man dem Programm mit der Option
-r Dateiname.pcap übergeben. Ohne weitere Parameter würde tshark aber nur den Inhalt des Tracefiles im Fenster herunterrattern. Die von Wireshark bekannten Display-Filter setzt man mittels der Option
-Y Filterausdruck ein. Beispielsweise filtert
-Y http.request alle HTTP-Anfragen heraus. Verschachtelte Filteraufgaben kann man in Hochkommata eingeschlossen übergeben. Für jedes gefilterte Paket gibt tshark einige Statusinformationen aus: Die laufende Nummer im Trace, den Zeitstempel, Source- und Destination-IP, Portnummer und Info. Der Clou: Mit der Option
-T fields -e Feldname extrahiert tshark Inhalte bestimmter Felder.
Um einige Anwendungen durchzuspielen, haben wir eine rund 55 MByte große Beispieldatei eines Smart-TV von LG vorbereitet, die sich gut für Übungen eignet. Sie finden sie hier.
Zunächst geht es darum, die von einem Smart-TV angesprochenen (unverschlüsselten) HTTP-Server zu finden. Dafür filtert man am einfachsten das Feld http.host heraus:
-T fields -e http.host. tshark gibt damit jeden Treffer in einer separaten Zeile entsprechend der Reihenfolge im Tracefile aus. Um mehrere Felder zu filtern, setzt man die Option
-e Feldname mehrmals hintereinander.
Um weitere Display-Filter oder Feldnamen anzuwenden, testen Sie sie zunächst in Wireshark am selben Tracefile. Syntaxfehler stellt die Software rot hinterlegt dar. Wenn der Filterausdruck korrekt ist, wechselt die Farbe auf Grün.
Im Wireshark-Beispiel (folgender Screenshot) ist zu sehen, dass wir die UPnP-basierte Multicast-Kommunikation ausblenden:
http.host and not ip.dst == 239.0.0.0/8. Das empfiehlt sich, weil einige Geräte während der Aufzeichnung viele UPnP-Nachrichten verschickt haben. Diese tun aber nichts zur Sache und stören bloß. Außerdem ist zu sehen, wie ein Klick auf das zu untersuchende Feld (Mitte) Wireshark dazu bringt, den genauen Feldnamen anzuzeigen (unten). In diesem Fall blendet Wireshark http.host ein, also die Variable für den Namen des angesprochenen HTTP-Servers.
Übungsrunde: Um die Syntax von Display-Filtern zu lernen, gibt man sie probeweise in Wireshark ein (oben). In diesem Beispiel werden alle HTTP-Requests angezeigt, ausgenommen die über UPnP.
tshark-Ausgaben können je nach Verkehrsart und Filter kurz und übersichtlich sein. Oft werden das aber lange Listen, beispielsweise von angesteuerten Domains, und nicht selten kommen im Trace manche Domains immer wieder vor. Dann empfiehlt es sich, die tshark-Ausgabe mit einigen Unix-Befehlen zu sortieren. So erkennt man Zusammenhänge oder Häufigkeitsverteilungen.
Der Befehl
sortsortiert die Liste alphabetisch. Mehrfacheinträge stehen danach untereinander.
uniq -cfasst Mehrfacheinträge zusammen, also etwa Ziele, die das Smart-TV wiederholt angesprochen hat. Dabei stellt das -c für Count die Anzahl der Aufrufe an den Zeilenanfang. Jeder Eintrag belegt somit nur noch eine Zeile. Das danach folgende
sort /Rgibt die Liste abnehmend nach Häufigkeit aus, also als Rangliste.
Der gesamte Vorgang lässt sich leicht automatisieren, indem man die Befehle mittels Pipes (|) verkettet. Das sieht komplett unter Windows dann so aus:
Auf Linux und macOS setzt man anstatt des letzten Sort-Befehls
sort -g -r ein. Die Analyse eines von Philips gefertigten Smart-TV brachte hervor, dass das Gerät viele Webserver mittels HTTP-Requests kontaktiert. Neben Erwartbarem wie Netflix-Servern sind aber auch etliche unbekannte Ziele darunter, etwa zeasn.tv und smartclip.net – das Smart-TV ist offensichtlich ein Plappermäulchen.
HTTPS analysieren
Auch HTTPS-verschlüsselte Verbindungen lassen sich untersuchen. Das geht sogar mit vertretbarem Aufwand, denn beim HTTPS-Verkehr sind nur die Nutzdaten verschlüsselt, nicht aber die beim Verbindungsaufbau übertragenen Paket-Header.
Das ist nützlich, denn viele Server-Betreiber bieten über eine einzige IPv4-Adresse mehrere Domains an. Die gewünschte Domain steht im Header des HTTP-Requests im Feld „Server Name Indication“. Anhand dieser SNI liefert der Zielserver dem Browser das zur angefragten Domain passende TLS-Zertifikat und dann die angefragte Webseite aus. Außerdem nutzen auch Load-Balancer die SNI, um in komplexen Server-Umgebungen Anfragen vorzusortieren und weiterzuleiten.
Auch verschlüsselte HTTPS-Verbindungen liefern nützliche Meta-Daten, denn erst die auf den Header folgenden Nutzdaten sind chiffriert: Hier ist das HTTP-Header-Feld „Server Name Indication“ blau unterlegt, mit dem Browser mitteilen, welche Domain sie ansteuern wollen.
Um HTTPS-Server aus einem Trace zu isolieren, nehmen Sie als Display-Filter tls.handshake.extensions_server_name. Die Option fürs interessierende Feld lautet entsprechend
-T fields -e tls.handshake.extensions_server_name und der gesamte Windows-Befehl inklusive sort- und uniq-Pipe setzt sich so zusammen:
Heraus kommt eine ähnliche Liste wie bei der Filterung der unverschlüsselten Webserver. So kommt man den teils unerwünschten Verbindungen eines Smart-TV auf die Schliche.
Direkte DNS-Anfragen
Neben den HTTP(S)-Zielen gibt es weitere lohnenswerte Kandidaten für die Verkehrsanalyse, allen voran die Source- und Destination-IP-Adressen, also “ipv6.src” und “ipv6.dst” für das IPv6-Protokoll sowie “ip.src” und “ip.dst” für das veraltete IPv4. Aufschlussreicher sind aber schon DNS-Queries “dns.qry.name”, die unverschlüsselte Anfragen aller Clients sichtbar machen, unabhängig davon, ob ein Client später HTTPS-, SMTP- oder sonstige Verbindungen aufbaut.
So fiel in einem unserer Traces auf, dass das Smart-TV nicht nur den per DHCP im LAN konfigurierten DNS-Server befragt, sondern auch direkt mit Googles DNS-Resolver 8.8.8.8 plaudert. Das sollte nicht sein. Der Smart-TV-Hersteller ist aber vermutlich unschuldig: Anhand des Felds
dns.flags.response == 0 kann man davon ausgehen, dass die Google-Anfragen von der auf dem Smart-TV installierten Netflix-App kommen und nicht vom TV-Betriebssystem.
Wireshark beschleunigen
Eine der nützlichsten tshark-Anwendungen ist Datenreduktion, um die Analyse mit Wireshark zu beschleunigen. Wireshark kaut nämlich an großen Dateien lange herum, bis es etwas anzeigt, weil das Programm nach jeder Änderung des Display-Filters die komplette Datei neu einliest. Um alle aktuell ausgewählten Pakete einer 600 MByte großen Capture-Datei darzustellen, benötigt selbst ein moderner Rechner mit i7-Dualcore-Prozessor und 16 GByte RAM satte 40 Sekunden – bei jeder Änderung der Filterzeile.
Schon beim Mitschneiden einen reduzierenden Capture-Filter zu verwenden, ist aber kontraproduktiv: Bei Fehleranalysen wissen Sie zu Beginn oft nicht, wonach Sie suchen. Daher lautet die Regel: so viel mitschneiden, wie gerade vertretbar ist.
Um dennoch flüssig mit Wireshark arbeiten zu können, überlegen Sie zunächst, wo anzusetzen ist. Ein guter Startpunkt kann die DNS-Kommunikation sein. Extrahieren Sie also aus dem großen Mitschnitt alle DNS-Pakete in eine neue Datei mit dem Display-Filter
udp.port eq 53 or tcp.port eq 53. Der Ausdruck dns wäre zwar viel einfacher, aber er erfasst nur DNS-Verkehr. So würden Sie bei etwaigem TCP-DNS-Verkehr den Verbindungsaufbau verpassen.
Verwenden Sie nun tshark zum Einlesen der ursprünglichen Datei zusammen mit dem Filter, um eine verkleinerte Variante zu erzeugen:
Längere Mitschnitte segmentiert man geschickterweise, zum Beispiel in mehrere Dateien von je 100 MByte Größe. Denn wenn Sie den Verkehr von sehr schnellen Schnittstellen bei hohem Durchsatz mitschneiden, fallen in kürzester Zeit enorm große Dateien an. Mit tshark und etwas Know-how kann man dann Verdächtiges oder Wesentliches leicht extrahieren und Wireshark als Portiönchen zuführen.
Das erledigt, zusammen mit einer Filterung, einfacherweise ein Shell-Skript, im Beispiel unten als Windows-Batch-Datei. Sie legt die gefilterten Segmente in ein Unterverzeichnis und fasst sie dort mit dem ebenfalls zu Wireshark gehörenden Tool
mergecap zusammen:
for %a in (*.pcapng) do tshark -r %a -Y "udp.port eq 53 or tcp.port eq 53" -w subdir\%a
cd subdir
mergecap -w single-file.pcapng *.pcapng
Firmen-Admins nutzen tshark-Analysen auch zur Qualitätskontrolle: Wer beispielsweise einen öffentlichen autoritativen DNS-Server betreibt, kann die von Clients verwendeten DNS-Flags auslesen. So lassen sich Missetäter identifizieren, die fälschlicherweise rekursive DNS-Anfragen senden:
dns.flags.recdesired.
Qualitätskontrolle bei IPv6
Wenn Sie Server betreiben, die auf IPv6 antworten, bietet es sich an, ICMPv6-Fehlercodes zu analysieren. Die kommen von Backbone-Routern und Firewalls, wenn sie IPv6-Antwortpakete Ihres Servers nicht zustellen können. Mögliche Ursachen sind fehlende Routen, Routing-Loops oder auch blockierende Firewall-Policies. Um Fehler innerhalb Ihres eigenen Netzes auszuschließen, hilft der Blick auf die Details. Dabei sind folgende zwei Felder relevant:
-e icmpv6.type -e icmpv6.code.
Wenn darin der Fehler „Typ 1 Code 0“ steckt, bedeutet das „no route to destination“. Router senden ihn, wenn sie ein Paket mangels korrekter Route nicht zustellen können. Wenn Ihr Server diesen Fehler beim Versuch erhält, auf eine Anfrage aus dem Internet zu antworten, ist die Source-IPv6-Adresse vielleicht gefälscht oder das Routing des entfernten Netzes vermurkst.
„Typ 1 Code 3“ beziehungsweise „address unreachable“ bedeutet, dass der letzte Router des Übertragungspfads die Ziel-IPv6-Adresse (Layer 3) nicht zur MAC-Adresse (Layer 2) auflösen konnte. Das kann an fehlkonfigurierten IPv6-Stacks von Clients oder versehentlichem Blocken der IPv6-Neighbor-Solicitations liegen – diese sind für die Auflösung erforderlich. In beiden Fällen kann der Client nicht per IPv6 kommunizieren – verwunderlich, dass es noch keinem auffiel.
„Typ 3 Code 0“ beziehungsweise „hop limit exceeded in transit“ ist der Klassiker unter den ICMPv6-Fehlern. Er deutet auf einen Routing-Loop hin: Zwei Router referenzieren sich gegenseitig, womöglich gehören sie zu Ihrem Netzwerk. Ob das der Fall ist, finden Sie mit dem Befehl
traceroute heraus.
Dass solche Fehler alltäglich sind, demonstriert eine Liste von vier Servern des NTP-Pools. Binnen 24 Stunden liefen Tausende von ICMPv6-Fehlermeldungen auf, die mit dem folgenden Skript extrahiert wurden:
Erstaunlicherweise traten gleich sieben Fehlertypen auf. Da liegt noch einiges im Argen bei der IPv6-Implementierung mancher Netzbetreiber.
Security-Analysen mit tshark
Die Datenaufbereitung mit tshark hilft auch bei der Analyse von Security-Problemen. So hat der Autor damit untersucht, ob Load-Balancer von F5 Networks gegen die Logjam-Attacke anfällig sind. Logjam nutzt aus, dass ältere TLS-Implementierungen bei der Diffie-Hellman-Schlüsselvereinbarung öffentliche Schlüssel (Public Keys) nicht nur einmal, sondern mehrfach verwenden. Das können Angreifer nicht nur nutzen, um verschlüsselte Inhalte mitzulesen, sondern auch um sie zu verfälschen.
Veraltete TLS-Implementierung: Manche Geräte nutzen beim Schlüsselaustausch gemäß Diffie-Hellman einen Public Key mehr als nur einmal. Angreifer können das nutzen, um verschlüsselte Daten mitzulesen und zu modifizieren.
Startpunkt für die Analysen ist Wireshark. Im Mitschnitt suchen Sie zunächst ein Paket mit dem Handshake-Type „Server Key Exchange“. Im Bildbeispiel ist dieses Element mit (1) markiert. Den Ausdruck als Display-Filter eingesetzt (2), zeigt Wireshark die Pakete mit diesem Inhalt an. Der Bezeichner dieses Felds (3) erscheint nach einem Klick unten (4). Praktisch: Per Rechtsklick und „Apply as Column“ blendet Wireshark dieses Feld als zusätzliche Spalte in der Paketübersicht ein (5). Schon offenbart sich, dass die ersten vier Einträge – also Public Keys – identisch sind.
Damit ist das Problem bewiesen und man braucht tshark eigentlich nicht mehr, aber Trace-Files lassen sich nicht immer in Wireshark öffnen. Manche liegen auf entfernten Rechnern und wenn sie groß sind, lohnt die Übertragung für solche Analysen kaum. Also nutzt man tshark über ssh direkt auf dem fernen Rechner: Public Keys identifizieren Sie über die Optionen
-Y tls.handshake.type == 12 sowie
-T fields -e tls.handshake.ys und sortieren die Ausgabe wieder mit
sort | uniq -c | sort /R.
Letztlich hängt es stark von der Anwendung ab, welche Paketfelder man isolieren will. tshark bietet Ihnen genau diese Möglichkeit und bewahrt Sie davor, im Morast einer riesigen Trace-Datei zu versinken. Mit wenigen Handgriffen untersuchen Sie das Surfverhalten Ihres Sprösslings oder Ihrer IoT-Geräte selbst – mausschonend und ohne Copy-&-Paste, Zettelwirtschaft oder Excel.
Netzwerkverkehr mitschneiden: So gehtsDie verbreiteten Fritzboxen und manche Speedport-Router können direkt Paketmitschnitte anfertigen.
Der Netzwerkverkehr lässt sich je nach Gerät auf unterschiedliche Weise aufzeichnen: Auf dem lokalen PC nimmt man klassisch Wireshark. Das bietet Wireshark direkt nach dem Programmstart an; man muss lediglich die Netzwerkschnittstelle auswählen und den Start-Button klicken.
Den Verkehr von Geräten, auf denen Wireshark nicht läuft, kann die Mitschnitt-Funktion des Routers liefern. Auf den verbreiteten Fritzboxen findet man sie unter der Adresse http://fritz.box/html/capture.html, auf manchen Speedport-Routern unter http://www.speedport.ip/html/capture.html.
Im Firmen-Umfeld gehört Packet-Capturing bei modernen Firewalls wie denen von Palo Alto Networks oder Fortinet zum Pflichtenheft, man startet es über deren Konfigurationsseiten. Um den Durchsatz nicht in die Knie zu zwingen, sollten Sie den Mitschnitt auf die IPv4- und IPv6-Adressen des interessierenden Clients beschränken.
An Firmen-Switchen mit Port-Mirroring, auch SPAN-Port (Switched Port-Analyzer), können Sie den Verkehr ausleiten. Wenn man den Client-Port vorübergehend auf 100 MBit/s drosselt, reicht die Kapazität des Mirror-Ports (1 GBit/s) sicher für beide Richtungen. Aber mit der langsamen Datenrate kann der Fehler verschwinden.
Admins mit größerem Budget greifen deshalb zu einem professionellen Terminal Access-Point (TAP) mitsamt Capture-Card. Erst der schreibt sämtliche Pakete jederzeit korrekt mit und liefert so genaue und zuverlässige Traces.
Unabhängig vom Aufzeichnungsgerät werden die Mitschnittdateien üblicherweise in den Formaten PCAP oder PCAPNG gespeichert, die Wireshark, tshark und Konsorten verstehen.
Wenn es im Netzwerk knirscht, versuchen Admins den Fehler in Analyse-Tools wie Wireshark anhand von Paketmitschnitten einzukreisen. Jedoch hat der Herr viel mehr Netzwerkprotokolle gegeben, als sich ein Admin-Hirn in allen Details merken kann. Eine Referenzdatei, die zahlreiche korrekte Protokollabläufe enthält, gibt Orientierung.
Diesen Artikel habe ich initial für die c’t geschrieben, wo er im Heft 24/2020 erschienen ist. Als Autor habe ich dankenswerterweise die Erlaubnis, ihn hier auf meinem Blog ebenso zu veröffentlichen. Eine Übersicht der von mir geschriebenen c’t Artikel gibt es hier.
Wer den Netzwerkverkehr auf Kommunikationsfehler abklopfen muss, braucht bei der Analyse von Paketmitschnitten (Traces) reichlich Geduld. Abgelaufene Zertifikate, Inkompatibilitäten aufgrund verschiedener Versionen, fehlerhafte Implementierungen, abgelaufene Timer – der Fehler steckt oft im Detail.
Natürlich kann man einen Trace im Analysewerkzeug Wireshark öffnen und die Aufzeichnung Paket für Paket und Feld für Feld mit den Spezifikationen vergleichen. Ein Fehler springt aber eher ins Auge, wenn man einen funktionierenden Protokollablauf zum Vergleich heranzieht.
Manche Netzwerk-Admins sammeln daher Traces funktionierender Übertragungen, um sie später als Referenz zu verwenden. Auch der Autor dieses Beitrags hat wichtige Traces über Jahre hinweg gesammelt. Anstatt aber vor jeder Analyse die zugehörige Referenzdatei im händisch angelegten Archiv zu suchen, hat er die wichtigen Mitschnitte in ein einziges PCAP-File gesteckt. Das kann man wie üblich mit einem Doppelklick in Wireshark öffnen und dann die mächtige Filtermaschine des Programms nutzen, um einen gesuchten Protokollablauf darzustellen.
In diesem Beitrag geht es um eine rund 9 MByte große Referenzdatei. Sie enthält aktuell über 60 Traces von Protokollen, die auf das Übertragungsmedium Ethernet aufsetzen; Sie finden sie über ct.de/yjkz.
Die meisten Beispiele sind sowohl für das moderne IPv6 als auch für das veraltete IPv4 ausgeführt. Unter anderem befinden sich in der Referenzdatei sowohl Abläufe grundlegender Protokolle wie DNS, HTTP oder ICMP als auch von Exoten wie Ciscos Unidirectional Link Detection (UDLD) oder vom langsam aussterbenden WHOIS. Die komplette Liste haben wir in einer Tabelle aufgeführt, die ebenfalls unter ct.de/yjkz zum Download bereitsteht.
In Wireshark kann man mit flexiblen Display-Filtern allen Verkehr ausblenden, der gerade nicht interessiert, und so ausschließlich die zu analysierende Kommunikation verfolgen. Bei vielen Protokollen hat man die Wahl zwischen zwei Filterarten: Setzt man zum Beispiel
http oder
dns ins Feld „Display-Filter“ ein, dann zeigt Wireshark nur die Pakete, die zum jeweiligen Applikationsprotokoll gehören.
Wenn man stattdessen auf den Zielport filtert, zeigt Wireshark zusätzlich den Transport Layer Overhead, der beim Verbindungsaufbau abläuft, inklusive Acknowledgements und etwaiger Retransmissions. Um also eine komplette Websession zu betrachten, gibt man
tcp.port eq 80 ein.
Überblick
Die Kommunikation von Hosts mit dem Domain Name System (DNS) gehört zu den grundlegenden Anwendungen. Praktisch jedes internetfähige Programm benötigt zur Verbindungsaufnahme die Auflösung von Domainnamen zu A- oder AAAA-Records mit ihren IP-Adressen, sodass solche Pakete in fast jedem Trace zu finden sind. Der Großteil der weltweiten DNS-Anfragen an die DNS-Resolver läuft unverschlüsselt ab, was auch die Referenzdatei widerspiegelt; verschlüsselnde Protokolle wie DNS-over-HTTPS und DNS-over-TLS fassen aber langsam Fuß und werden daher in einem kommenden Update der Referenzdatei berücksichtigt.
Um den DNS-Verkehr isoliert zu betrachten, gibt man im Display-Filter
dns ein. Mit dem Filter
tcp.port eq 53 or udp.port eq 53 sehen Sie die gesamte Kommunikation zur Namensauflösung, also auch etwaigen TCP-Overhead.
DNS-Probleme können vielfältig sein. Daher sind in der Referenzdatei allerlei DNS-Beispiele aufgeführt, angefangen von Paketen, die seltene Resource Records (RR) enthalten, bis hin zu kompletten Zone Transfers.
Außerdem finden Sie darin Besonderheiten wie Hostnamen, die Sonderzeichen enthalten (internationalized domain names, IDN), und Anfragen zu A- oder AAAA-Records mit bis zu 64 IPv4- oder IPv6-Adressen pro Host. Nicht zu vergessen DNSKEYs und RRSIGs der kryptografischen DNS-Absicherung DNSSEC sowie die zugehörigen Flags in den Antworten. Für Domain-Admins interessant: Dynamische DNS-Updates (nicht zu verwechseln mit DynDNS eines Heimrouters).
Bei genauem Hinsehen fallen neben klassischen UDP-Paketen auch IP-Fragmente sowie TCP-Sessions auf. Diese treten immer dann auf, wenn eine DNS-Antwort nicht mehr in ein UDP-Paket passt. Herkömmliche DNS-Antworten dürfen nicht länger als 512 Bytes sein, um mittels UDP übertragen werden zu können. Mit der Erweiterung EDNS(0) signalisiert ein Server, dass er mehr Nutzdaten verschickt (> 512 <= 1232 Bytes). Sollte die EDNS(0)-Übertragung scheitern oder die Obergrenze überschreiten, kann der Client den Server über das aufwendigere und langsamere TCP befragen.
DNS-Anfragen laufen nicht nur über den UDP-Port 53 ab: Bei dieser DNSSEC-Validierung ist die Antwort auf die Frage (1) nach dem DNSKEY zu groß für ein UDP-Datagramm und daher sendet der Resolver: „Message is truncated“ (2). Die DNS-Response enthält also keine Nutzdaten (3). Der DNS-Client fragt daher noch einmal per TCP nach (4).
Was wäre das Internet ohne HTTP? Klar, dass das Trace-File auch ein paar HTTP-Sessions enthält. Kleiner Wireshark-Tipp: Klicken Sie mit der rechten Maustaste auf ein HTTP-Paket und dann im Kontextmenü auf „Follow/HTTP Stream“. Daraufhin öffnet sich ein Fenster, das nur den Inhalt des HTTP-Headers und des Bodys anzeigt; etwaige komprimierte Inhalte werden automatisch dekomprimiert.
Wer HTTP-Verkehr im Unternehmensumfeld analysiert, muss mit Proxys rechnen. Eine häufige Frage ist daher: Wie kann man, abgesehen von der IP-Adresse des Proxys, auf reinen HTTP- oder Proxy-vermittelten Verkehr rückschließen? Ein Beispiel dafür liefert der Host mit der IP-Adresse 192.168.110.10 (Display-Filter
ip.addr == 192.168.110.10). Dieser hat eine Webseite sowohl direkt als auch per Proxy aufgerufen. Wenn er nur
GET / sendet, kommuniziert er mit dem Webserver direkt. Schickt er hingegen
GET http://<hostname>/, nutzt er den Proxy.
Doch der Webverkehr hat sich schon seit einiger Zeit überwiegend zu TLS-verschlüsseltem HTTP verlagert, also HTTPS. Im Trace sind mehrere TLS-1.2- und -1.3-Sessions zu sehen.
Möchten Sie wissen, welche Hostnamen ein Client aufgerufen hat? Schauen Sie sich den DNS Query, den HTTP Host oder die Server Name Indication (SNI) an, hier zusammengefasst in nur einer Spalte (2).
Dabei ist zwar der Großteil der Kommunikation verschlüsselt, aber immerhin kann man leicht erkennen, welche Hostnamen ein Client aufruft (Server Name Indication, SNI). Mit dem Filter
tls.handshake.extensions_server_name lassen sich alle Pakete isolieren, die ein SNI-Feld enthalten (siehe Screenshot oben). Sie möchten wissen, welche Server-Zertifikate im Trace stecken? Setzen Sie im Display-Filter
tls.handshake.type == 11 ein.
Die Referenzdatei eignet sich auch zum Testen von Display-Filtern (1). Im obigen Screenshot sind gleich mehrere Beispiele für den Einsatz von logischen Operatoren wie and und or sowie Klammern mit mehreren Werten aufgeführt
in { x y z }. Sie lassen sich auch in selbsterstellten Spalten, den „Custom Columns“ verwenden.
Die Spalte unter (2) wird per
dns.qry.name or http.host or tls.handshake.extensions_server_name erzeugt. So führt eine einzige Spalte die DNS-Pakete der angefragten Namen auf, dazu den per HTTP-Session angesprochenen Host und bei HTTPS-Verbindungen auch die Server Name Extension – sehr praktisch für einen schnellen Überblick über das Surfverhalten.
Zum Schluss sei unter den grundlegenden Protokollen das Internet Control Message Protocol (ICMP) genannt, es kommt beim täglich millionenfach genutzten Ping zum Einsatz. Damit versendet man Pakete vom Typ “echo-request” und erhält vom angepingten Host Antworten vom Typ “echo-reply”. Übliche Ping-Befehle zeigen nicht wirklich Überraschendes, aber durchaus der Traceroute-Befehl, der ICMP in Kombination mit inkrementierten Hop-Limits verwendet (bei IPv4 „TTL“), um Routern auf der Strecke zu einem Ziel Lebenszeichen zu entlocken.
Während der Windows-Befehl
tracert die engen ICMP-Rahmenbedingungen weitgehend umsetzt, lassen sich mit den
traceroute-Implementierungen von Unix-Betriebssystemen sogar beliebige TCP- oder UDP-Ports ansprechen und auch Netzwerkpfade hinter Firewalls identifizieren. In der Referenzdatei steckt ein solches Beispiel für den SMTP-Port TCP-25. Finden Sie es? Tipp: Die betreffende Traceroute-Session lief auf IPv6.
Routing-Protokolle
Das Rückgrat großer Netzwerke und des Internets bilden Routing-Protokolle, mit denen sich Backbone-Router gegenseitig ins Bild setzen, über welche Strecken sie bestimmte andere Netzwerke erreichen. In internen Netzen sind das Routing Information Protocol (RIP) beziehungsweise das Routing Information Protocol next generation für IPv6 (RIPng) gebräuchlich. Damit meldet jeder Router alle ihm bekannten Netzwerke periodisch an eine Multicast-Adresse und teilt sie so allen anderen Routern im privaten Netz mit.
Für komplexere Netze hat sich Open Shortest Path First (OSPF) durchgesetzt. Alle beteiligten Router senden periodisch ein Hello-Paket; Informationen über Router und angeschlossene Layer-3-Netze fließen nur bei Änderungen. Mit seinen zig verschiedenen Link State Advertisements (LSA) zählt das Protokoll zu den komplexen. Wie gut, dass Sie im PCAP diverse solcher LSA-Typen finden und erforschen können.
OSPF ist ein selbstständiges Protokoll, das wie TCP auf der IP-Schicht aufsetzt. Die Protokollnummer lautet 89 (1). In der obigen Abbildung ist auch der Authentication Header (AH) der Protokollnummer 51 (2) zu sehen, denn beim betreffenden Paket handelt es sich um OSPFv3 für IPv6 mit eingebauter Authentifizierung. Der Großteil des Pakets besteht aus Netzwerkinformationen im Klartext (3).
Internet-Router kommunizieren miteinander über das Border Gateway Protocol (BGP), das den TCP-Port 179 nutzt und manuell zwischen zwei Routern eingerichtet wird (BGP-Nachbarschaft, engl. Neighbors). Anschließend können sie Informationen über erreichbare IPv4- und IPv6-Netze austauschen. Ob eine BGP-Session über IPv4 oder IPv6 aufgebaut wurde, spielt keine Rolle.
Zur gegenseitigen Authentifizierung haben sich einfache BGP-Passwörter in Form von Pre-Shared Keys etabliert; damit wird eine MD5-Prüfsumme über jedes BGP-Päckchen gebildet. Wer diese Prüfsumme am Ende des BGP-Pakets vermutet, wird jedoch nicht fündig, denn sie wird als TCP-Option übertragen und steckt daher vorn im TCP-Header.
Um in der Referenzdatei ausschließlich BGP-Nachrichten darzustellen, genügt es,
bgp als Display-Filter zu verwenden. Möchten Sie den kompletten TCP-Overhead sehen, verwenden Sie
tcp.port eq 179.
IPv6-Crashkurs
Der Internet-Verkehr wird verschiedenen Statistiken zufolge mittlerweile zu mehr als 30 Prozent über IPv6 abgewickelt, für Deutschland meldete Google Ende Oktober 2020 schon 50 Prozent IPv6-Anteil (siehe ct.de/yjkz). In Firmenumgebungen ist der Anteil weit geringer, denn viele Unternehmen betreiben ihre Infrastruktur noch weitgehend nur mit IPv4. Moderne Betriebssysteme nutzen IPv6 aber zumindest im LAN (Layer 2, Link-lokal), sodass IPv6-Pakete auch in vermeintlich reinen IPv4-Umgebungen übertragen werden. Manch ein Admin argwöhnt dann ein Fehlverhalten im Netz.
Die Referenzdatei kann auch hier Licht ins Dunkel bringen. Anwendungsprotokolle wie DNS, HTTPS oder SSH nehmen mit beiden IP-Protokollen vorlieb, bevorzugen aber IPv6. Um sich zu vergewissern, kann man beispielsweise nach
ipv6 and http filtern und so etwa hausinterne IPv6-Kommunikation mit Druckern sehen (z. B. AirPrint), die sich Link-lokale IPv6-Adressen per Autokonfiguration erwürfelt haben.
Wer sich eingehend mit IPv6 beschäftigt, wird schnell auf eine Fülle von ICMPv6-Nachrichten stoßen. Diesem Thema widmet sich die Referenzdatei ganz am Anfang: Setzen Sie im Display Filter
ipv6 ein. Die daraufhin eingeblendeten Kommunikationsabläufe kann man als kleinen IPv6-Crashkurs nutzen. Es geht los mit Paketnummer 32.
Zunächst ist der Ablauf der automatischen Adressvergabe per Stateless Address Autoconfiguration zu sehen (SLAAC). Ein frisch gebootetes Knoppix-Linux versorgt sich mit zwei IPv6-Adressen: einer Link-lokalen, die mit
fe80:: beginnt und nur im lokalen Netz gilt, sowie einer Global Unicast Adresse (GUA), die weltweit gilt und eindeutig ist. Der Linux-Rechner ist über einen Speedport-Router an einem Telekom-Anschluss mit Dual-Stack-Konfiguration angeschlossen, kann darüber also sowohl per IPv4 als auch per IPv6 mit Internet-Hosts kommunizieren. Den Adressbereich (IPv6-Präfix) für seine GUA erhält er über den Router vom Provider, also von der Telekom.
Dabei laufen folgende Schritte ab:
Der PC sucht mittels Router Solicitation nach einem Router im LAN (Paket 39). Der Router schickt ein Router Advertisement (Paket 43) mit dem vom Provider zugewiesenen /64-Präfix. Der zugehörige Display-Filter lautet
icmpv6.type in { 133 134 }.
Der Client erzeugt unter Verwendung seiner MAC-Adresse zwei IPv6-Adressen für sich selbst, die Link-lokale und die globale Adresse, abgeleitet aus dem Präfix. Bevor er sie nutzt, fragt er per Duplicate Address Detection (DAD) im Netzwerk nach, ob sie in Verwendung sind. Technisch gesehen handelt es sich um eine Neighbor Solicitation, gesendet von der Null-Adresse (unspecified) “::”. Der Display-Filter lautet:
icmpv6.type eq 135 && ipv6.src eq ::.
Nun fehlt dem Client noch ein DNS-Server (Resolver) zur Namensauflösung. Solche IP-Adressen kann ein Client wahlweise per Router Advertisement beziehen (z. B. Paket 21190) oder per DHCPv6 (z. B. Pakete 44 und 45). Aber Achtung: Es handelt sich um „stateless DHCPv6“, also nur um die Bekanntmachung des Resolvers, nicht um die Vergabe von IPv6-Adressen.
Die Link-Layer Address Resolution ist das IPv6-Gegenstück zum Address Resolution Protocol von IPv4 (ARP): Ein Endgerät möchte zu einer IP-Adresse die zugehörige MAC-Adresse auf der Ethernet-Schicht herausfinden. In der IPv6-Spezifikation gehört diese Funktion zu ICMPv6 und heißt Neighbor Discovery. Ein anfragender Client hängt die letzten 24 Bit der gesuchten Unicast- oder Anycast-Adresse an das Multicast-IPv6-Präfix ff02::1:ff00:0/104 an und schickt sie als Neighbor Solicitation ab. Die gesuchte Gegenstelle antwortet mit einem Neighbor Advertisement. Filter:
icmpv6.type in { 135 136 }.
Die Multicast Listener Discovery (MLD) sollte eigentlich das IPv6-Gegenstück zum Internet Group Management Protocol (IGMP) auf IPv4 sein. Filter:
icmpv6.type in { 130 131 132 143 }. Es gibt aber kaum Layer-2-Switche, die so etwas wie „MLD-Snooping“ verwenden. Das ist unüblich, weil fehleranfällig. Daher sind MLD-Pakete in der Praxis bedeutungslos und man kann sie ignorieren.
Spätestens jetzt ist klar: ICMPv6-Pakete können sehr unterschiedliche Funktion haben. Etwas unkomfortabel erscheint daher, dass Wireshark in der Grundkonfiguration alle ICMPv6-Pakete gleich einfärbt (siehe linkes Fenster im Screenshot oben).
Die Wireshark-Färberei kann man aber auch konfigurieren. Das zugehörige Fenster mit diversen manuellen Regeln ist im obigen Screenshot auf der rechten Seite zu finden. In der Mitte des Screenshots sehen Sie das Einfärbeergebnis dieser Regeln: MLD-Pakete sind absichtlich kaum sichtbar (hellgrüne Schrift auf weißem Grund), Duplicate Address Detection ist grün unterlegt, Router Solicitation/Advertisement lila und die Neighbor Discovery türkis. Übliche Pings (Pakete 83 und 86) sind unauffällig pink.
Hai-Färberei: Wer die Funktion der unterschiedlichen ICMPv6-Pakete optisch herausheben will, kann in Wireshark die Coloring Rules nach eigenem Gusto anpassen. Links sind ICMPv6-Pakete gemäß einer üblichen Wireshark-Regel eingefärbt, rechts mit angepassten Regeln.
Unverschlüsselt
Früher oder später kann es jeden Netzwerkadmin treffen: das Entsetzen darüber, dass eigene Netzwerkgeräte ungewollt unverschlüsselt kommunizieren. Beispielsweise treiben manche FTP-Clients auf PCs ihr Unwesen. Obwohl Serverbetreiber im Internet, beispielsweise für Webauftritte, die Wartungszugänge längst per TLS abgesichert haben, kommt es bei falschen Client-Einstellungen trotzdem zu Plaintext-Übertragungen – inklusive des Passworts. Autsch.
Wohl dem, der beispielsweise FileZilla einsetzt. Wenn möglich, nutzt das Programm FTP über TLS. Aber mancherorts sind noch veraltete FTP-Programme im Einsatz und auch der Windows Explorer von Windows 7 verschlüsselt seine FTP-Kommunikation nicht. Wie das aussieht, finden Sie mit dem Display Filter
ftp or ftp-data heraus.
Auch SMTP und IMAP können TLS-abgesichert kommunizieren, aber ist das bei Ihren Servern der Fall? Manche Admins wähnen ihr Netz hinter der NAT ihres Routers in Sicherheit und betreiben interne SMTP- und IMAP-Server aus Bequemlichkeit unverschlüsselt – ein gefundenes Fressen für Emotet und andere Botnetze.
Bei den heute üblichen VoIP-Telefonaten ist die Lage vertrackt: Unter anderem kann man zwar SIP over TLS und sRTP zum Verschlüsseln von Steuer- und Nutzdaten verwenden, aber in Deutschland sind sie wenig verbreitet. Derzeit kann man nur VoIP-Konten der Telekom, EasyBell und Dus.net mit diesen beiden Protokollen absichern. Einige Router eignen sich bereits dafür, darunter Fritzboxen ab FritzOS 7.20 (siehe ct.de/yjkz).
Viele VoIP-Anbieter setzen die unverschlüsselten Protokolle SIP und RTP ein. Wenn Sie sich überzeugen wollen, wie einfach es ist, VoIP-Telefonate mitzuhören: Klicken Sie in Wireshark auf „Telephony/VoIP Calls“, wählen Sie einen der drei erkannten Anrufe aus und klicken Sie anschließend auf „Play Streams“.
Ausblick
„Ich weiß, dass ich nichts weiß“: Auch wenn diese Referenzdatei zahlreiche Protokolle enthält, kann sie nicht die Anforderungen aller Admins der Welt erfüllen. Sie lässt sich aber erweitern. In späteren Updates könnten die für Datacenter relevanten Protokolle MPLS, VXLAN oder ERSPAN hinzukommen, auch Klassiker wie POP3, LDAP oder NFS. Neuentwicklungen wie QUIC oder DNS-over-TLS sind ebenfalls spannende Kandidaten.
Dennoch sind die Anwendungsbereiche schon jetzt vielfältig: Man kann die Datei zum Vergleich mit einem lokalen Fehlerbild nutzen, zum Experimentieren mit Wireshark-Filtern, zum Testen von Netzwerk-Tools oder für Schulungszwecke. Möge sie auch Ihnen weiterhelfen.
Das moderne Internetprotokoll IPv6 gilt als so komplex und umständlich, dass manche Administratoren beharrlich beim vertrauten, aber veralteten IPv4 bleiben. Zehn Praxisbeispiele belegen, warum viele Netzwerkanwendungen besser und kostengünstiger auf IPv6 laufen und wie Admins davon profitieren.
Diesen Artikel habe ich initial für die c’t geschrieben, wo er im Heft 07/2022 erschienen ist. Als Autor habe ich dankenswerterweise die Erlaubnis, ihn hier auf meinem Blog ebenso zu veröffentlichen. Eine Übersicht der von mir geschriebenen c’t Artikel gibt es hier.
Profi-Admins und viele Netzwerk-Interessierte wissen längst, weshalb IPv4 unzulänglich ist: Dessen Adressraum ist gemessen am weltweiten Bedarf viel zu klein und Netzwerke auf IPv4-Basis laufen nur mit der Krücke Network Address Translation (NAT) weiter – diese bildet teils riesige Netze mit privaten IPv4-Adressen auf wenige oder gar nur eine öffentliche IPv4-Adresse ab. Weiter unten finden Sie mehr Beispiele für Netzwerkprobleme, die allein der IPv4-NAT geschuldet sind.
Aber jeder Admin weiß auch: IPv6 gewinnt zwar weltweit an Zulauf, doch kaum eine Firma wird mit IPv6 auch nur einen Cent mehr einnehmen; es gibt ja keine Geschäftsmodelle, die exklusiv auf IPv6 gründen. Warum also sollte man den Aufwand auf sich nehmen und etablierte IPv4-Methoden und -Werkzeuge einmotten?
Die Antwort zeigt sich auf dem Überstundenzettel des Admins: IPv4 verursacht bei vielen gängigen Anwendungen einen so großen Konzeptions- und Pflegeaufwand, dass sich eine Umstellung auf IPv6 mittelfristig bezahlt macht, weil sich die Netzwerkerweiterung und -pflege spürbar vereinfacht. Auch lassen sich manche Probleme, die IPv4 stellt, nur mit IPv6 lösen. Wenn Sie erst mal IPv6 eingeführt haben, können Sie Adressbrokern eine lange Nase drehen. Denn deren Geschäftsmodell setzt darauf, sich von IPv6-scheuen Unternehmen ihren kleinen Rest noch freier IPv4-Adressen vergolden zu lassen.
Heimnetz-Admins haben hingegen andere Sorgen mit der Umstellung von IPv4 auf IPv6. Unter anderem fehlt den verbreiteten Fritzbox-Routern eine IPv6-Implementierung der VPN-Technik. Da bessert der Hersteller aber nach.
Aller Anfang ist auch für den Firmen-Admin schwer und die erste Hürde stellt sich schon mit der Länge der IPv6-Adressen. “Die sind mir viel zu lang, die kann ich mir nicht merken.” Diesen Satz dürfte jeder Netzwerker oder IT-Admin schon mal gehört haben.
Natürlich sind IPv6-Adressen weit länger als IPv4-Adressen. IPv4-Adressen bestehen aus 4 Byte, die zu vier Blöcken mit Werten von 0 bis 255 unterteilt sind (32 Bit). IPv6-Adressen bestehen aus 16 Byte, die zu je acht Blöcken aus vier Hexadezimalstellen von 0 bis F unterteilt sind (128 Bit).
Doch gerade die Länge ist ein Gewinn, denn damit lassen sich die Adressen besser strukturieren. Das bringt in der Praxis vor allem bei komplexen Netzen in Unternehmen und Institutionen eine Fülle von Vorteilen. Man erkennt nur nicht alle auf den ersten Blick.
Vorteil 1: Zu merkende Präfixe
Viele mittelständische bis große Unternehmen haben im Laufe der Jahre mehrere öffentliche IPv4-Adressbereiche in Betrieb genommen. Zusätzlich verwendet jede Firma im internen Netz mindestens einen der üblichen privaten IPv4-Adressblöcke (10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16). Das kann erforderlich sein, um Filialen zu koppeln oder das Netz in Subnetze aufzuteilen, sodass zum Beispiel Versand, Buchhaltung, Forschung, Produktion, Geschäftsleitung und Administration in verschiedene Security-Zonen aufgeteilt sind.
Bildet der Admin solche Strukturen mit IPv4 ab, hantiert er zwangsläufig mit den verschiedenen Präfixen der drei privaten Adressblöcke. Da sie aus obigen Gründen oft noch weiter unterteilt sind, kommt man leicht auf 3 bis 6 Blöcke, mit denen man im Alltag jonglieren muss.
Nicht so bei IPv6: Geschäftskunden erhalten in der Regel einen festen /48-Block und große Netzwerke bekommen leicht auch einen /32-Bereich. In beiden Fällen beträgt die Anzahl der zu merkenden Präfixe: eins! Und das Präfix ist schnell gelernt, weil es ja nur die ersten zwei Hextets umfasst, beispielsweise 2001:db8::/32.
Je nach Größe des Adressblocks schließt sich dann für die Subnetze der Adressraum des dritten oder vierten Hexadezimalblocks an (z. B. 16 Bit). In der Abbildung “IPv4 vs IPv6 Adressvorteile” (oben) wird dieser Unterschied offensichtlich: Bei IPv4 muss man die privaten und öffentlichen Allokationen vor Augen haben, während es mit IPv6 nur eine Zuweisung ist.
Vorteil 2 und 3: Site-to-Site-VPN
Viele Firmengruppen und Unternehmen unterhalten untereinander VPN-Verbindungen (Site-to-Site). Aufgrund des knappen IPv4-Adressraums sind bei allen Firmen private IPv4-Adressen unverzichtbar. Da es aber nur drei unterschiedliche Adressräume für private Netze gibt, ist die Wahrscheinlichkeit hoch, dass zwei Firmen intern denselben Bereich verwenden, beispielsweise 192.168.1.0/24. Dann sind Adresskollisionen und damit Admin-Kopfschmerzen unausweichlich.
Aus diesem Dilemma führen verschiedene Wege: Eine der beiden Firmen könnte ihr Subnetz in einen anderen Bereich verlegen. Doch der Aufwand ist viel zu hoch, fehlerträchtig und je nach verwendeten Diensten vielleicht gar nicht im laufenden Betrieb möglich – es ist jedenfalls für jeden Admin, der mehr als 20, 30 Netzwerkgeräte betreut, eine haarsträubende Vorstellung. Und wenn beide Firmen alle drei privaten IPv4-Adressblöcke nutzen, funktioniert der Weg gar nicht (10/8, 192.168/16 und 172.16/12).
Stattdessen konfiguriert man separate Adressen, die im jeweils anderen Netzwerk nicht vorkommen und richtet sie im VPN-Router mittels internen NATs als Vermittler ein – so sind Adresskollisionen ausgeschlossen, aber auf Kosten der Übersicht. Die Pflege und Fehlersuche ist in solchen Netzen deutlich aufwendiger.
Oft sind sogar ein Source- und ein Destination-NAT erforderlich, damit nicht nur die Hin-, sondern auch die Rück-Route klappt, ohne zu große Netzbereiche auf einer der Seiten belegen zu müssen.
Als Beispiel: Firma A teilt ihren internen Geräten IP-Adressen aus den Bereichen 192.168.0.0/24 und 192.168.10.0/24 zu. Die Partnerfirma B, zu der A ein VPN aufsetzen will, verwendet diese beiden Bereiche ebenso.
Der Client mit der IP-Adresse 192.168.0.5 möchte auf Server 192.168.10.10 von Firma B zugreifen. Da Firma A diesen Adressbereich aber bereits anderweitig verwendet, richtet man ein statisches Destination-NAT aus einem reservierten Block als Vermittler ein: 192.168.110.10 vermittelt dann den eingehenden VPN-Verkehr zum Server von Firma B. Diese kann die IP-Adresse des Firma-A-Clients nicht zurückrouten, weil diese bereits bei Firma B anderweitig in Einsatz ist; sie verwendet intern ebenfalls den Adressbereich 192.168.0.0/24. Also behilft sich Firma B mit einem Source-NAT. Somit sind für eine Client-Server-Verbindung vier Subnetze im Spiel.
Es leuchtet unmittelbar ein, dass solche Umwege aufwendig zu konfigurieren und der Übersicht abträglich sind. Das Troubleshooting von Client-Server-Verbindungen wird schnell zum Albtraum, denn in den Logs stehen auf beiden Seiten diverse IPv4-Adressen, die der Admin gedanklich korrekt zuordnen muss (und besser gleich auf einer Skizze notiert), obwohl für das VPN nur eine IP-Session im Spiel ist.
Mit jedem weiteren Site-to-Site-VPN potenziert sich der Aufwand, weil weitere NAT-Regeln hinzukommen; der IPv4-Adressdschungel wird immer undurchdringlicher. Dann muss man schon zum Aufsetzen der NATs mehr Probleme lösen als zur Konfiguration des VPN. Dabei sind zwei NAT-Regeln nur ein Beispiel. Je nach Infrastruktur können für eine einzige Site-to-Site-Verbindung mehr NATs erforderlich sein. Und Admins, die VPN-Verbindungen zu mehreren Partnern mit identischen IPv4-Subnetzen aufbauen wollen, können gleich auch Haarfärbemittel bestellen.
Der Umstieg auf IPv6 ist sicher auch aufwendig – aber einen Tod muss man sterben. Und wenn man sich einmal für IPv6 entschieden hat, wird Site-to-Site-VPN plötzlich zum Kinderspiel: Dank eindeutiger Adressbereiche auf beiden Seiten sind Adresskollisionen von vornherein ausgeschlossen und gordische NAT-Knoten daher nicht erforderlich. Die Konfiguration und das Troubleshooting solcher VPNs sind weit einfacher. Technisch gesehen muss nur das jeweils andere IPv6-Präfix im eigenen Netz geroutet werden – Ende-zu-Ende-IP-Verbindungen par excellence.
Vorteil 4: Stets genügend Platz in der DMZ
Viele Netzwerke sind organisch gewachsen und die ursprünglichen Konzepte zur Aufteilung des Adressraums genügen den aktuellen Anforderungen nicht mehr, denn auf einmal braucht die Firma mehr Server, als sich im dafür gedachten IPv4-Segment adressieren lassen.
Beispiel: Die Webserver-DMZ nutzt den Bereich 192.168.17.0/28, womit sich mitsamt dem Default-Gateway 14 Server adressieren lassen: 192.168.17.1 – 192.168.17.14. Sollen nun weitere Server hinzukommen, fehlt es an Adressen. Eine Neuaufteilung der Subnetze zur Vergrößerung des DMZ-Adressbereichs ist in großen Netzwerken kaum möglich.
Aber Not macht erfinderisch und risikobereit: Manche Admins legen im gleichen Layer-2-Segment ein zweites IP-Netz an, beispielsweise 192.168.91.64/28. Darin bekommt die Firmen-Firewall eine zweite IP-Adresse, damit sie für das zweite Netz als Default-Gateway arbeiten kann (192.168.91.65). So lassen sich weitere 13 Server adressieren. Das funktioniert zwar, erhöht aber die Komplexität, weshalb man solche Szenarien lieber meidet.
Mit IPv6 kommt man um solche Verknotungen auf absehbare Zeit leicht herum, weil die Adressräume weit größer sind: Mit jedem /64er-Subnetz lassen sich bis zu 2^64 Geräte adressieren. Ausgeschrieben: 18.446.744.073.709.551.616. Der Layer-2-Switch, der so viele MAC-Adressen verwalten kann, muss erst noch gebaut werden. Für MAC-Adressen sind bisher nur Tabellen mit 8192 bis 65.536 Einträgen üblich, und zwar für alle VLANs zusammengenommen.
Vorteil 5: Routing-Tabellen überblicken
Admins, die mit IPv4 aufgewachsen sind, haben verinnerlicht, mit Adressen zu knausern. Oder anders gesagt: kein Netz größer zu machen als unbedingt nötig. Deshalb bestehen unter anderem DMZ-Subnetze aus unterschiedlichen Teilnetzen wie /27, /28 oder /29er, während Gäste-WLANs oft auf /23- oder /22-Blöcke ausgedehnt sind – sehr zum Leidwesen des Netzadmins, der Routing-Tabellen nicht mal eben mit einem grep-Kommando durchforsten kann.
Stattdessen muss er die Subnetzmaske durchblicken. Hat der Admin in der Routing-Tabelle drei Netze, kann er nicht einfach per grep 192.168.23. herausfiltern, welche der Routen denn stimmt. Er muss alle drei anschauen und verstehen. Und wenn die Routing-Tabelle aus mehreren Hundert Einträgen besteht, hilft Drübergucken auch nicht mehr, sondern nur noch spezielle Lookup-Tools, wie sie Router oder Firewalls bieten.
Das ist umständlich. Anders bei IPv6: Die ersten vier Hextets einer IPv6-Adresse bezeichnen immer und eindeutig die Netz-ID. Die Zugehörigkeit von Node-IDs zu einem Netz ist daher unmittelbar ersichtlich, egal, ob in Routing-Tabellen oder Firewall-Logs.
Vorteil 6: Ende-zu-Ende-Verbindungen
Bereits bei der Spezifikation vor fast 30 Jahren werteten Fachleute die NAT als “short-term solution” und favorisierten ein künftiges Internet-Protokoll mit größerem Adressraum. Denn wenn eine NAT im Spiel ist, können IPv4-Geräte keine Ende-zu-Ende-Verbindungen aufbauen. Deshalb lassen sich Server-Logs nicht umgehend einer Client-Session zuordnen. Der NAT-Router muss den Zustand (state) in der NAT-Tabelle pflegen und unbenutzte Sessions tilgen, andernfalls können irgendwann keine neuen Sessions aufgebaut werden.
Kurzum: Die NAT hat zwar eine Zeit lang geholfen, das Internet-Wachstum aufrechtzuerhalten, aber daran festzuhalten heißt auch, mehr Geld für heutzutage rare IPv4-Adressen ausgeben. Bei eingehenden Verbindungen zu einem Server entfernt sie die öffentliche IPv4-Adresse aus dem Header des Client-Pakets, setzt die private IP-Adresse des Servers ein, notiert sich das und gibt das Paket schließlich zum Server weiter. Das belastet den Router und bremst den Verkehr.
Diesen kosten- und energieträchtigen Rechenaufwand kann man Routern durch den Wechsel auf IPv6 ersparen. Dank weltweit eindeutiger Adressierung aller Endgeräte braucht IPv6 keine NAT – ein Router muss die Pakete nur noch routen. So war ursprünglich auch das IPv4-Internet gedacht.
Wer sich um die Security Sorgen macht, da alle IPv6-Clients adressierbar sind: addressable ≠ accessible! Eine Firewall, die unverlangt eingehende Verbindungen verwirft, stellt sicher, dass interne Geräte der Firma eben nicht von außen erreichbar sind. Anstelle eines einfachen Routers mit seiner durchsatzbegrenzenden NAT kommt eine echte Firewall zum Einsatz. Schon die allermeisten einfachen Router für den Heimbereich sind IPv6-seitig genau so ausgelegt und schützen das Netz ab Werk, also ohne jegliche Benutzerinteraktion. Beispielsweise machen die verbreiteten die Fritzboxen genau das.
Vorteil 7: Kein Split-DNS
Damit externe Clients auf Server mit privaten IPv4-Adressen zugreifen können, die hinter einer NAT stehen, befragen sie zunächst das Domain Name System (DNS) nach der öffentlichen IP-Adresse der angesteuerten Domain. Im öffentlichen DNS stehen keine privaten IPv4-Adressen, sodass dort der angefragte Domainname auf die öffentliche IPv4-Adresse des Routers gemappt ist.
Interne Clients sollen aber möglichst nicht den Weg über die NAT gehen, um den Router zu entlasten. Damit sie den kurzen internen Weg beschreiten, richtet man im Netz einen internen DNS-Server ein, der den Clients die private IPv4-Adresse des Servers liefert, den sie dann direkt kontaktieren. So gibt es aber je nach Position eines Clients unterschiedliche DNS-Server mit unterschiedlichen Antworten auf dieselbe DNS-Anfrage – das ist die klassische und zurecht ungeliebte Split-DNS-Konfiguration mit zwei (oder sogar mehr) Views.
IPv6 benötigt keine NAT, sodass für alle Server die öffentliche IPv6-Adresse direkt auf ihren Netzwerkkarten konfiguriert ist. Deshalb erfolgen IPv6-Zugriffe von Clients auf Server im selben Netz sowieso direkt, weil die Wege zu den Servern in der internen Route stehen. Das erspart das Split-DNS – eine Fehlerquelle weniger.
Vorteil 8: Viele Server auf gleichen Ports
Privatkunden und auch viele Kleinunternehmen erhalten in der Regel Internetanschlüsse mit nur einer öffentlichen IPv4-Adresse– wenn überhaupt, Kabel-Internet mit DS-Lite und Glasfaserzugänge mit CG-NAT lassen grüßen. Mit einer IPv4-Adresse kann man pro TCP/UDP-Port normalerweise nur einen Server betreiben, also zum Beispiel nur einen HTTPS-Server auf 443/TCP oder nur einen SMTP-Server auf 25/TCP.
Wenn auf demselben Anschluss auch IPv6 geschaltet ist, kann man dahinter mehrere Server auf denselben Ports betreiben. Entwickler können so mehrere Server unter verschiedenen IPv6-Adressen für verschiedene Zwecke laufen lassen, zum Beispiel für die Produktion und den Testbetrieb, oder Haupt- und Backup-Server für SMTP- und IMAP-Mail.
Vorteil 9: Infos im Suffix abbilden
Enterprise-Router haben wie andere IPv6-Hosts auch für jedes Interface mindestens zwei IPv6-Adressen, eine Link-lokale und eine globale. Die Suffixe – der Host-Teil, auch IID, hintere 64 Bit – der Adressen generiert ein Router automatisch, wenn man ihn lässt; er leitet sie von der MAC-Adresse des jeweiligen LAN-Interfaces ab (modifiziertes EUI-64-Verfahren für Interface Identifiers in RFC 4291). Diese automatisch generierten Suffixe sind aber schwer zu merken, was zum Beispiel die Fehlersuche erschwert. Womöglich ist das eine der Ursachen, dass sich Admins für IPv6 so schwer erwärmen.
Die Übersicht lässt sich leicht verbessern, indem man im Suffix Gebäude-, Stockwerk-, Abteilungsstrukturen oder gar den Router-Typ manuell abbildet und zwar so, dass Sie sich die Zuordnungen leicht memorieren können. Da man für Server-Host-IDs nur wenige Stellen benötigt, können Sie drei der vier Host-ID Bereiche wegkürzen. Angenommen, das Serverpräfix lautet 2001:db8:f5:1234::/64, dann vergibt man in diesem Subnetz für die Server beispielsweise 2001:db8:f5:1234::a1, 2001:db8:f5:1234::a2, und so weiter. Um die Hosts zu unterscheiden, genügt also ein Blick auf das letzte Hextet der Host-ID.
Auch ist nützlich, dasselbe Suffix in der Link-lokalen Adresse zu verwenden. Wenn Sie die wesentlichen Merkmale in den letzten 32 Bit des Suffix kodieren, können Sie diesen Bereich bei den Routing-Protokollen OSPFv3 und BGP zusätzlich als Router-ID nutzen.
Vorteil 10: Hierarchischer Adressplan
Von den Vorteilen eines hierarchischen IPv6-Adressplans haben wir hier noch gar nicht gesprochen. Beispielsweise gibt es die Möglichkeit, an den Nibble-Boundaries (4-Bit-Blöcke zur Subnetierung) eines /32er-Präfixes die /48er-Sites zu nummerieren. Oder innerhalb eines /48-Blocks die /64er-Subnetze anhand der Organisationseinheiten oder Securityzonen zu ordnen. Das ist ein anderes Thema, dem auch schon ganze Bücher gewidmet sind.
Zur Liste der Vorteile muss man fairerweise noch sagen, dass nicht alle bei jeder Anwendung greifen. Im privaten Heimnetz sind DNS-Views (siehe Vorteil 7) meistens unwichtig, zumal schon die Anzahl an verschiedenen Subnetzen (5) niedrig ist. In großen, weltweit aufgestellten Unternehmen ist wiederum das einfache Routing (2) über VPNs nicht mehr skalierbar beziehungsweise politisch oder organisatorisch schwer umzusetzen.
Dennoch: Die Vorteile des IPv6-Adressraums sind weit größer als die reine Anzahl adressierbarer Endgeräte.
Erste Schritte
Letztlich bleibt der Widerwille gegen hexadezimale IPv6-Adressen ein nicht haltbares Vorurteil. Lassen Sie sich also nicht davon irritieren. Unsere Empfehlung lautet: Starten Sie mit IPv6. Es muss ja nicht gleich das gesamte Firmennetz sein. Ein kleines Labor, das Gäste-WLAN oder eine DMZ genügen, um Erfahrungen zu sammeln. So gewöhnen sich Admins leicht an IPv6-Adressen in Routing-Tabellen, Firewall-Regelwerken und Applikations-Logs. Das verkleinert die Hürde, falls IPv6 morgen zwingend erforderlich wird.
Und wenn Sie sich entschieden haben, IPv4 aufs Reservegleis zu schieben: Planen Sie Ihre IPv6-Infrastruktur am besten von Grund auf neu, ohne Bezugnahme auf Ihre IPv4-Struktur. Viele Netze sind im Laufe der Jahre organisch gewachsen und aus heutiger Sicht nicht mehr optimal strukturiert. Nutzen Sie den Umstieg, um das Dickicht zu lichten.
Die Abbildung Ihrer Prozesse auf IPv6 dürfte in den allermeisten Fällen reibungslos klappen, weil inzwischen der Großteil der Anwendungen auf IPv6 läuft. Kalkulieren Sie Mehraufwand ein, um individuelle Lösungen wie Skripte für IPv6 zu ertüchtigen.
Achten Sie beim Parallelbetrieb von IPv6 und IPv4 darauf, dass alle Sicherheitsrichtlinien umgesetzt sind. Ein beliebter Fehler: Man schränkt zwar den SSH-Login auf der externen Firewall für IPv4 per Access List auf bestimmte IPv4-Quelladressen ein, vergisst aber, den Zugriff für IPv6 zu beschränken, sodass der SSH-Server per IPv6 aus dem gesamten Internet erreichbar ist.
Zu beachten ist auch, dass Server, die über ein VPN per IPv6 angesprochen werden und in einer DMZ stehen, einem Sicherheitsrisiko ausgesetzt sind. Bricht der Tunnel zusammen, funktioniert die VPN-Route nicht mehr und der Verkehr geht ersatzweise über die Default Route zum Ziel. Dabei laufen Anwendungen, die nicht von sich aus verschlüsseln, blank übers Internet (z. B. IP-Telefonie oder Mail-Verkehr). Dagegen helfen bei großen Firewalls spezielle Regeln.
Exkurs: Die Nachteile der NAT
Im letzten Jahrtausend gab es tatsächlich eine Phase, als jeder Host im IPv4-basierten Internet seine eigene öffentliche Adresse hatte. Als das Wachstum alle Erwartungen übertraf, zauberten findige Entwickler die Network Address Translation (NAT) aus dem Ärmel und brachten so mittels privaten, öffentlich nicht gerouteten Adressen ein Mehrfaches an Netzwerkgeräten ins Internet, als mit den 4,3 Milliarden IPv4-Adressen möglich ist. Das ist nun der Status: NAT hat sich fürs IPv4-Internet unverzichtbar gemacht.
Doch damit sie zwischen Geräten mit privaten IPv4-Adressen im Netzwerk und Zielen im öffentlichen Internet vermitteln kann, ändert die NAT die Ziel- und Quelladressen von ein- und ausgehenden Datenpaketen, notiert sich für jede einzelne Sitzung die Bezüge und reicht die Pakete dann erst zu ihren Zielen weiter. Daraus entstehen Nachteile, die man teils wiederum mit Behelfen mehr schlecht als recht kompensiert.
Hosts in verschiedenen Netzen, die hinter NATs stehen, können nicht direkt miteinander kommunizieren, da die NATs unaufgefordert eingehende Verbindungen verwerfen. Damit sie wenigstens mittelbar kommunizieren können, braucht man Hilfsprotokolle wie STUN, TURN, ICE oder UPnP. Manche sind umständlich zu konfigurieren und sie funktionieren nicht immer. Beispielsweise gibt es Router, die für ihre interne VoIP-TK-Anlage alle VoIP-Sessions (SIP und RTP) für sich beanspruchen, sodass man dahinter keine eigene VoIP-TK-Anlage betreiben kann.
NAT-Tabellen können nicht beliebig groß sein. Meistens fassen sie nur einige Tausend Einträge, denn Router müssen mit ihrem meist knappen RAM-Angebot haushalten. Deshalb löschen sie inaktive NAT-Einträge bei Platznot. Um Einträge so lange aktuell zu halten, wie die jeweilige IP-Sitzung dauert, müssen Netzwerkgeräte etwa im Minutentakt Pakete zu ihrem Ziel senden, die dem Router signalisieren: “Dieser NAT-Eintrag wird noch benötigt”. Das tun nicht alle Anwendungen. Beispielsweise senden Messaging- oder Notification-Anwendungen Daten nur unregelmäßig, sodass ihr NAT-Eintrag verschwindet. Daher sind manche solcher Clients nicht durchgängig erreichbar oder müssen ihre Verbindung immer wieder neu aufbauen.
Umgekehrt gilt: Wenn die Netzwerkgeräte viele Sitzungen dauerhaft aufgebaut haben, kann die NAT-Tabelle überlaufen, mit der Folge, dass manche Sitzungen unerwartet abbrechen (z. B. VPN-Tunnel).
Zu dem Thema haben Fachleute schon ganze Bücher geschrieben, es gibt sogar ein IETF-Dokument, das ausschließlich den Problemen gewidmet ist, das die NAT verursacht (RFC 3027). Unterm Strich gilt: Die NAT ist okay, solange man auf IPv4 angewiesen ist. Doch die Behauptung, “NAT ist ein Security-Feature” hat nie gestimmt. Wenn möglich, sollte man also auf IPv6 umsteigen, weil sich damit viele Detailprobleme gar nicht erst stellen.
