Brett's Blog

Testing ISAKMP Part 4: Using Scapy

Sun, 22 Feb 2026 10:59:00 -0500

In Part 2, I showed how to test ISAKMP with a pre-built hex string and netcat. In Part 3, we dove deep into the byte-by-byte construction of ISAKMP packets. Now let’s use Scapy to automate this with Python.

Why Scapy?

Netcat with hex strings works for one-off tests, but Scapy lets you build packets programmatically, parse responses automatically, and script tests across multiple targets. It understands ISAKMP structure and handles length fields and checksums for you.

Prerequisites

Python 3.8+ installed
Basic Python knowledge
Understanding of ISAKMP concepts (see Part 1)
Target ISAKMP/IKE peer to test
Root/sudo access (required for raw socket operations)

Installation

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# Install Poetry (if not already installed)
curl -sSL https://install.python-poetry.org | python3 -

# Install Scapy via Poetry
cd /path/to/your/project
poetry init
poetry add scapy

# Or install globally
pip install scapy

# Verify installation
python3 -c "from scapy.all import *; print(conf.version)"

Important: Scapy requires raw socket access, which needs root/sudo privileges. When using Poetry with sudo, you must install dependencies as root: sudo poetry install

Basic ISAKMP Packet with Scapy

The Simple Approach

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


#!/usr/bin/env python3
from scapy.all import *

# Target configuration
target_ip = "192.168.1.1"
target_port = 500

# Build basic ISAKMP packet
# Create IP and UDP layers
ip = IP(dst=target_ip)
udp = UDP(sport=500, dport=target_port)

# Create ISAKMP header (Identity Protection, Main Mode)
isakmp = ISAKMP(
 init_cookie=RandString(8), # Random 8-byte initiator cookie
 resp_cookie=b'\x00' * 8, # Responder cookie (zeros for initial packet)
 exch_type=2, # Identity Protection (Main Mode)
)

# Create SA payload with a simple transform
sa = ISAKMP_payload_SA(
 prop=ISAKMP_payload_Proposal(
 proto=1, # ISAKMP
 trans=ISAKMP_payload_Transform(
 transform_id=1 # KEY_IKE
 )
 )
)

# Assemble the complete packet
packet = ip / udp / isakmp / sa

# Send and receive
response = sr1(packet, timeout=5, verbose=1)

if response:
 response.show()
else:
 print("No response received")

Building a Complete Phase 1 Packet

Transform Set Configuration

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33


# Define transform set parameters
# Using modern cryptographic standards

# Encryption algorithms (RFC 3602, RFC 2409)
ENCR_AES_CBC = 7
ENCR_3DES_CBC = 5

# Hash algorithms (RFC 2409)
HASH_SHA256 = 4
HASH_SHA1 = 2

# Diffie-Hellman groups (RFC 2409, RFC 3526)
DH_GROUP_14 = 14 # 2048-bit MODP
DH_GROUP_5 = 5 # 1536-bit MODP
DH_GROUP_2 = 2 # 1024-bit MODP

# Authentication methods (RFC 2409)
AUTH_PSK = 1 # Pre-Shared Key
AUTH_RSA_SIG = 3 # RSA Signatures

# Life duration type (RFC 2409)
LIFE_TYPE_SECONDS = 1
LIFE_TYPE_KILOBYTES = 2

# Define a modern transform set
transform_set = {
 'encryption': ENCR_AES_CBC,
 'key_length': 256, # AES-256
 'hash': HASH_SHA256,
 'dh_group': DH_GROUP_14,
 'auth_method': AUTH_PSK,
 'lifetime': 86400 # 24 hours in seconds
}

Constructing the Packet

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67


from scapy.all import *

def build_isakmp_packet(target_ip, transform_set):
 """
 Build a complete ISAKMP Phase 1 Main Mode packet with specified transform set.

 Args:
 target_ip: Target IP address
 transform_set: Dictionary with encryption, hash, dh_group, auth_method, lifetime

 Returns:
 Complete Scapy packet ready to send
 """
 # IP and UDP layers
 ip = IP(dst=target_ip)
 udp = UDP(sport=500, dport=500)

 # ISAKMP header
 isakmp = ISAKMP(
 init_cookie=RandString(8),
 resp_cookie=b'\x00' * 8,
 exch_type=2, # Identity Protection (Main Mode)
 )

 # Build transform attributes as list of (type, value) tuples
 # Type numbers: 1=Encryption, 2=Hash, 3=Auth, 4=Group, 11=LifeType, 12=LifeDuration, 14=KeyLength
 transforms = [
 (1, transform_set['encryption']), # Encryption algorithm
 (2, transform_set['hash']), # Hash algorithm
 (4, transform_set['dh_group']), # DH Group
 (3, transform_set['auth_method']), # Authentication method
 (11, 1), # Life Type: seconds
 (12, transform_set['lifetime']) # Life Duration
 ]

 # Add key length if specified
 if transform_set.get('key_length', 0) > 0:
 transforms.insert(1, (14, transform_set['key_length']))

 # Build Transform payload
 transform = ISAKMP_payload_Transform(
 transform_id=1, # KEY_IKE
 transforms=transforms
 )

 # Build Proposal payload
 proposal = ISAKMP_payload_Proposal(
 proposal=1,
 proto=1, # ISAKMP
 trans=transform
 )

 # Build SA payload
 sa = ISAKMP_payload_SA(
 doi=1, # IPsec DOI (lowercase field name)
 situation=1, # Identity Only
 prop=proposal
 )

 # Assemble complete packet
 packet = ip / udp / isakmp / sa

 return packet

# Example usage
target = "192.168.1.1"
packet = build_isakmp_packet(target, transform_set)

Note: Scapy’s ISAKMP implementation uses a list of (type, value) tuples for transform attributes, not individual attribute objects. This is simpler and matches how the protocol actually works.

Sending and Analyzing Responses

Send the Packet

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41


def send_isakmp_packet(packet, timeout=5):
 """
 Send ISAKMP packet and capture response.

 Args:
 packet: Scapy packet to send
 timeout: Response timeout in seconds

 Returns:
 Response packet or None
 """
 print(f"[*] Sending ISAKMP packet to {packet[IP].dst}:500")
 print(f"[*] Initiator Cookie: {packet[ISAKMP].init_cookie.hex()}")

 # Send packet and wait for response
 response = sr1(packet, timeout=timeout, verbose=0)

 if response:
 print(f"[+] Response received from {response[IP].src}")
 return response
 else:
 print("[-] No response received (timeout)")
 return None

# Send the packet
response = send_isakmp_packet(packet)

if response and response.haslayer(ISAKMP):
 # Extract basic info
 print(f"\n[*] Response Details:")
 print(f" Responder Cookie: {response[ISAKMP].resp_cookie.hex()}")
 print(f" Exchange Type: {response[ISAKMP].exch_type}")
 print(f" Next Payload: {response[ISAKMP].next_payload}")

 # Check if SA payload is present
 if response.haslayer(ISAKMP_payload_SA):
 print(f"[+] SA payload received - transform set accepted!")
 else:
 print(f"[-] No SA payload - transform set rejected")
 # Note: Some devices send NOTIFY payloads on rejection
 # Check for ISAKMP_payload_Notification for detailed error info

Understanding the Response

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59


def parse_isakmp_response(response):
 """
 Parse ISAKMP response and extract transform set details.

 Args:
 response: Scapy packet containing ISAKMP response

 Returns:
 Dictionary with parsed response details
 """
 if not response or not response.haslayer(ISAKMP):
 return None

 result = {
 'responder_cookie': response[ISAKMP].resp_cookie.hex(),
 'exchange_type': response[ISAKMP].exch_type,
 'accepted': False,
 'transform_set': {}
 }

 # Check for SA payload (indicates acceptance)
 if response.haslayer(ISAKMP_payload_SA):
 result['accepted'] = True

 # Extract transform attributes if present
 if response.haslayer(ISAKMP_payload_Transform):
 transform = response[ISAKMP_payload_Transform]

 # Parse attributes
 if hasattr(transform, 'attributes'):
 for attr in transform.attributes:
 attr_type = attr.attribute_type
 attr_val = attr.attribute_value

 # Map attribute types to names
 if attr_type in [0x8001, 0x0001]:
 result['transform_set']['encryption'] = attr_val
 elif attr_type in [0x800e, 0x000e]:
 result['transform_set']['key_length'] = attr_val
 elif attr_type in [0x8002, 0x0002]:
 result['transform_set']['hash'] = attr_val
 elif attr_type in [0x8004, 0x0004]:
 result['transform_set']['dh_group'] = attr_val
 elif attr_type in [0x8003, 0x0003]:
 result['transform_set']['auth_method'] = attr_val

 return result

# Example usage
if response:
 parsed = parse_isakmp_response(response)

 if parsed and parsed['accepted']:
 print("\n[+] Transform set ACCEPTED by peer")
 print(f" Encryption: {parsed['transform_set'].get('encryption', 'N/A')}")
 print(f" Hash: {parsed['transform_set'].get('hash', 'N/A')}")
 print(f" DH Group: {parsed['transform_set'].get('dh_group', 'N/A')}")
 else:
 print("\n[-] Transform set REJECTED or no response")

Advanced Usage

Testing Multiple Transform Sets

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73


def test_transform_sets(target_ip, transform_sets, timeout=5):
 """
 Test multiple transform sets against a target.

 Args:
 target_ip: Target IP address
 transform_sets: List of transform set dictionaries
 timeout: Response timeout in seconds

 Returns:
 List of results with acceptance status
 """
 results = []

 for i, ts in enumerate(transform_sets, 1):
 print(f"\n[*] Testing transform set {i}/{len(transform_sets)}")
 print(f" Encryption: {ts['encryption']}, Hash: {ts['hash']}, DH: {ts['dh_group']}")

 # Build and send packet
 packet = build_isakmp_packet(target_ip, ts)
 response = sr1(packet, timeout=timeout, verbose=0)

 # Parse response
 parsed = parse_isakmp_response(response)

 result = {
 'transform_set': ts,
 'accepted': parsed['accepted'] if parsed else False,
 'response': parsed
 }
 results.append(result)

 if result['accepted']:
 print(f" [+] ACCEPTED")
 else:
 print(f" [-] REJECTED or no response")

 # Small delay between tests
 time.sleep(1)

 return results

# Define multiple transform sets to test
test_sets = [
 # Modern strong crypto
 {
 'encryption': 7, # AES-CBC
 'key_length': 256,
 'hash': 4, # SHA-256
 'dh_group': 14, # 2048-bit
 'auth_method': 1,
 'lifetime': 86400
 },
 # Moderate crypto
 {
 'encryption': 7, # AES-CBC
 'key_length': 128,
 'hash': 4, # SHA-256
 'dh_group': 14, # 2048-bit
 'auth_method': 1,
 'lifetime': 86400
 }
]

# Run tests
results = test_transform_sets("192.168.1.1", test_sets)

# Summary
print("\n" + "="*50)
print("SUMMARY")
print("="*50)
accepted = [r for r in results if r['accepted']]
print(f"Accepted: {len(accepted)}/{len(results)} transform sets")

Aggressive Mode vs Main Mode

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77


def build_aggressive_mode_packet(target_ip, transform_set, identity="test@example.com"):
 """
 Build ISAKMP Aggressive Mode packet.

 Aggressive Mode sends more information in the first packet (including identity)
 but completes the exchange faster (3 packets vs 6 in Main Mode).

 Args:
 target_ip: Target IP address
 transform_set: Transform set dictionary
 identity: Identity string for ID payload

 Returns:
 Complete Scapy packet
 """
 # IP and UDP layers
 ip = IP(dst=target_ip)
 udp = UDP(sport=500, dport=500)

 # ISAKMP header for Aggressive Mode
 isakmp = ISAKMP(
 init_cookie=RandString(8),
 resp_cookie=b'\x00' * 8,
 next_payload=1, # SA payload
 exch_type=4, # Aggressive Mode (vs 2 for Main Mode)
 flags=0
 )

 # Build SA payload (same as Main Mode)
 # ... (use build_isakmp_packet logic for SA/Proposal/Transform)

 # Add Key Exchange payload (sent in first packet in Aggressive Mode)
 ke = ISAKMP_payload_KE(
 next_payload=5, # ID payload follows
 ke=RandString(128) # DH public value (size depends on DH group)
 )

 # Add Identification payload (sent in first packet in Aggressive Mode)
 id_payload = ISAKMP_payload_ID(
 next_payload=0,
 IDtype=3, # ID_USER_FQDN
 IdentData=identity.encode()
 )

 # Assemble: ISAKMP / SA / KE / ID
 # Note: In Main Mode, KE and ID come in later packets
 packet = ip / udp / isakmp / sa / ke / id_payload

 return packet

# Compare the two modes:

# Main Mode (6 packets total, more secure)
# Packet 1: HDR, SA
# Packet 2: HDR, SA
# Packet 3: HDR, KE, Nonce
# Packet 4: HDR, KE, Nonce
# Packet 5: HDR*, ID, HASH
# Packet 6: HDR*, ID, HASH

main_mode_packet = build_isakmp_packet("192.168.1.1", transform_set)
print(f"Main Mode packet size: {len(main_mode_packet)} bytes")
print(f"Main Mode exchange type: {main_mode_packet[ISAKMP].exch_type}")

# Aggressive Mode (3 packets total, faster but exposes identity)
# Packet 1: HDR, SA, KE, Nonce, ID
# Packet 2: HDR, SA, KE, Nonce, ID, HASH
# Packet 3: HDR*, HASH

aggressive_packet = build_aggressive_mode_packet("192.168.1.1", transform_set)
print(f"Aggressive Mode packet size: {len(aggressive_packet)} bytes")
print(f"Aggressive Mode exchange type: {aggressive_packet[ISAKMP].exch_type}")

# Security consideration:
# Main Mode encrypts identity, Aggressive Mode sends it in CLEARTEXT
# This is a critical security vulnerability - attackers can harvest identities
# Use Main Mode unless you have a specific requirement for Aggressive Mode

NAT-T Detection

1
2


# TODO: Add NAT-T vendor ID
# TODO: Test for NAT-T support

Creating a Reusable Script

I’ve created a complete script that combines all these techniques. The full code is in the nn_examples repository.

The repository includes additional transform sets (including legacy crypto) for real-world compatibility testing.

Quick Start

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# Clone the repository
git clone https://github.com/lykinsbd/nn_examples.git
cd nn_examples/isakmp_testing

# Install dependencies with Poetry (both user and root)
poetry install
sudo poetry install

# Test a single target
sudo poetry run python isakmp_tester.py 192.168.1.1

# Test multiple transform sets
sudo poetry run python isakmp_tester.py 192.168.1.1 --test-multiple

# Use Aggressive Mode
sudo poetry run python isakmp_tester.py 192.168.1.1 --aggressive

Why sudo poetry install? Scapy requires raw socket access (root privileges). Since sudo runs in a separate environment, dependencies must be installed both as your user and as root.

Example Output

1
2
3
4
5
6
7


[*] Testing 192.168.1.1
 Mode: Main Mode
 Encryption: 7
 Hash: 4
 DH Group: 14
[+] ACCEPTED - Transform set accepted by peer
 Responder Cookie: a1b2c3d4e5f67890

Self-Contained Testing

The repository also includes isakmp_listener.py - a test responder for testing without a real VPN device:

1
2
3
4
5
6


# Terminal 1: Start the test listener
sudo poetry run python isakmp_listener.py

# Terminal 2: Test against localhost
sudo poetry run python isakmp_tester.py 127.0.0.1
sudo poetry run python isakmp_tester.py 127.0.0.1 --test-multiple

The listener accepts all proposed transform sets and logs packet details. Good for testing the tester script, learning packet structure, and debugging without VPN hardware.

Note: When testing against localhost (127.0.0.1), you may receive ISAKMP responses even without the listener running. This is the kernel’s UDP socket handling, not actual ISAKMP protocol responses. For realistic testing, use a real ISAKMP/VPN device or test between different machines.

Comparison: Scapy vs Netcat vs ike-scan

Feature	Scapy	Netcat	ike-scan
Dynamic construction	✅	❌	✅
Response parsing	✅	❌	✅
Scripting	✅	⚠️	⚠️
Learning tool	✅	✅	❌
Production ready	⚠️	❌	✅
Installation	pip	Built-in	Package manager

Security Considerations

⚠️ Authorization Required: Only test systems you own or have explicit permission to test. ISAKMP probes are logged by VPN concentrators, firewalls, and IDS/IPS systems. Repeated probes trigger security alerts.

Phase 1 Only: This covers IKE Phase 1 (ISAKMP) only. Establishing a full VPN tunnel requires Phase 2 (IPsec Quick Mode) and proper authentication credentials.

Cryptographic Parameters: Use SHA-256 (not SHA-1), AES-256, and DH Group 14+ (2048-bit minimum).

Troubleshooting

Permission Denied

1
2
3
4
5


# Scapy requires root for raw sockets
sudo poetry run python script.py

# Make sure dependencies are installed for root too
sudo poetry install

No Response Received

Check firewall rules (UDP/500)
Verify target IP is correct
Confirm ISAKMP service is running
Check for NAT between you and target
VPN concentrators rate-limit ISAKMP attempts - wait 30-60 seconds between tests

Import Errors

1
2


# Install missing dependencies
pip install scapy cryptography

Next Steps

Explore IKEv2 with Scapy
Build Phase 2 (Quick Mode) packets
Implement full IKE exchange
Add support for certificates (RSA signatures)

Conclusion

Scapy bridges the gap between manual packet construction and specialized tools like ike-scan. While netcat teaches you the raw protocol (Part 2) and manual construction reveals the internals (Part 3), Scapy gives you the power to automate and scale your testing.

For production VPN scanning, use dedicated tools like ike-scan or nmap --script ike-version. For learning and custom testing, Scapy is unmatched.

References

Testing ISAKMP Part 3: Building Packets from Scratch

Sat, 14 Feb 2026 17:16:00 -0500

In Part 2, I provided a ready-to-use ISAKMP packet for testing VPN connectivity. But where did that hex string come from? This post breaks down ISAKMP packet construction byte-by-byte.

Understanding packet structure at the byte level helps you debug protocol issues, customize packets for specific testing scenarios, and understand what tools like ike-scan are doing under the hood.

The Approach

After spending time reading RFC2408 for the basic header in Part 1, I decided to base this complete packet on an actual captured ISAKMP conversation. If you don’t have an ISAKMP capture handy, you can find protocol details and examples at the Wireshark ISAKMP Protocol page.

I still recommend reading RFC2408 to understand ISAKMP message structure, otherwise this sea of hexadecimal will be confusing.

Hand-Crafted Datagram

The primary ingredient needed to make a complete ISAKMP datagram is an attempt to set up the SA (Security Association) including nested inner payloads and an offer of a Transform set.

As discussed previously, the header format for ISAKMP (IKE v1) is defined in RFC2408 Section 3.1.

Initiator and Responder Cookies
- 8 bytes per Cookie
- Initiator Cookie
  - AKA the SPI or Security Parameter Index
  - We’ll make this a value of 1 since it has to be something and we don’t care what it is.
  - Production note: RFC 2408 recommends pseudo-random generation to prevent DoS attacks
  - \x00\x00\x00\x00\x00\x00\x00\x01
- Responder Cookie
  - All zeros because this is an initial communication, and as the Initiator, we don’t know what the responder will send yet.
  - \x00\x00\x00\x00\x00\x00\x00\x00
Next Payload
- 1 byte
- The Next Payload will be of a Security Association type, so per RFC2408 Section 3.1 this is a value of 1.
- \x01
Major Version and Minor Version
- 4 bits each
- Mandatory values of 1 and 0, because we’re using ISAKMP version 1.0
- That would be 0001 and 0000 in binary.
- Together, that would look like 00010000, which equals 10 in Hex.
- \x10
Exchange Type
- 1 byte
- The Exchange Types are laid out in RFC2408 Section 4.4 to Section 4.8.
- From our sample packet capture, I see we want an Identity Protection type (02).
- \x02
Flags
- 1 byte
- We still need no flags, so leaving this at 0.
- \x00
Message ID
- 4 bytes
- Must be zeros per RFC2408 for an initial Phase 1 datagram like we’re simulating.
- \x00\x00\x00\x00
Length
- 4 bytes
- I have doubled back from the bottom to fill in this value, as you are unable to calculate it until you have built all the inner payloads.
- This totals up to 88 bytes or 58 in hex.
- \x00\x00\x00\x58

Generic Payload Header

There is a simple header on each ISAKMP payload as shown below, it is defined in RFC2408 Section 3.2. We’ll need one on our outer SA Payload, and one will be present on any interior/nested payloads as well (such as additional Proposals or Vendor Specific Attributes).

Next Payload
- 1 byte
- This is the last outer payload, so 0.
- We’re not simulating Vendor Specific Attributes or anything like that, just trying to make a minimum viable datagram.
- \x00
RESERVED
- 1 byte
- Unused, set to Zero.
- \x00
Payload Length
- 2 bytes
- I am cheating somewhat, and know this value as I have gone forward to finish the payload, and then calculated backward to get this value.
- It includes the Generic Payload header elements (including the length field we’re calculating now) and the length of the inner SA Payload from below.
- That totals 60 bytes or 3c in hex.
- \x00\x3c

Security Association Payload

SA Payload is defined in RFC2408 Section 3.4 and laid out as shown below.

Domain of Interpretation (DOI)
- 4 bytes
- See RFC2408 Section 2.1 for more information on what the DOI is. For our purposes, this is a value of 1, for an IPSEC DOI (RFC2407).
- \x00\x00\x00\x01
Situation
- Variable length (4 bytes in this case)
- based on the DOI For IPSEC DOI, per RFC2407 section 4.2, this will be 4 bytes.
- Our sample capture indicates to say that this is Identity Only (value of 00000001).
- \x00\x00\x00\x01

Proposal Payload

Inside the SA Payload, there is the payload containing the ISAKMP Proposal on how to go about setting up the Security Association.

Next Payload
- 1 byte
- This will be zero as there is no other Proposal being sent.
- \x00
RESERVED
- 1 byte
- Unused, set to zero.
- \x00
Payload length
- 2 bytes
- Again, I only know this value as I am working backward, and have calculated it out knowing the length of this payload.
- It is 48 bytes long (including the two bytes above, these two bytes, and everything in the payload below), which is 30 in hex.
- \x00\x30
Proposal Number
- 1 byte
- If there is more than one Proposal in the payload, which Proposal is this?
- In our case, this is the first and only Proposal, so set this to 00000001.
- \x01
Protocol ID
- 1 byte
- This took some tracking down, but as defined in RFC2408 Section 3.6, the specific values for these are defined by the DOI in use (IPSec DOI in our case).
- The IDs are defined in RFC2407 Section 4.4.1, and we’re using ISAKMP (value of 1).
- \x01
SPI Size
- 1 byte
- Set to zero for ISAKMP (as the Initiator and Responder cookies will be used for the SPIs).
- \x00
Number of Transforms
- 1 byte
- We’re just sending one Transform, so set it to a value of 1.
- \x01

Transform Payload

And finally, inside of THAT payload are one or more Transforms. (I told you this would get confusing…) For our purposes, I’m just going to offer a single, simple, and fairly common transform set consisting of:

Encryption: AES-128
Hash: SHA
Diffie-Hellman: Group 5
Authentication: Pre-Shared Key
Lifetime 86400 seconds

⚠️ Security Notice: This packet uses legacy cryptographic parameters for maximum compatibility with older devices. For production VPNs, use:

Hash: SHA-256 or SHA-384

Encryption: AES-256-CBC or AES-256-GCM

DH Group: Group 14 (2048-bit) or higher

Consider IKEv2 instead of IKEv1 for modern deployments

It is worth noting that the Transform Attributes are expressed as TLV (Type-Length-Value) or TV (Type-Value). If you’re not familiar with what a TLV is, I recommend becoming familiar with it as it crops up again and again in network protocols. TLVs allow a protocol to be extended in ways beyond the original scope, for example, TLVs are what make a routing protocol like ISIS able to be extended to support Shortest Path Bridging.

The TLV/TV information for our purposes is laid out across all three original IPSEC/ISAKMP/IKE RFCs (RFC2407, RFC2408, and RFC2409 respectively.)

For getting the bulk of actual Types, Values, and whether they are fixed or variable length, you need RFC2409 Appendix A which lists the IKE Attribute Assigned Numbers.
RFC2408 Section 3.3 however, specifies the underlying Data Attribute format.
But to figure out what Domain of Interpretation (DOI) to use we have to consult RFC2407 Section 4.4.2.

It is also important to call out that RFC2408 Section 3.3 indicates that the most significant (leftmost) bit of the Attribute field, will determine if these bits represent a TLV (0) or TV (1).

If it is a TLV (0), then there is a length field sent.
If it is a TV (1), then it is assumed to be two bytes, and no length field is sent.

For example, this means that a TV (1) for an Encryption Algorithm (1) of AES-CBC (7) in Binary would be:

1000 0000 0000 0001 0000 0000 0000 0111

Translated to Hexadecimal, that would come out as:

\x80\x01\x00\x07

We will similarly construct each value below (and we’ll use this value as well).

Transform Set

Next Payload
- 1 byte
- This will be zero as no other Transforms are being sent.
- \x00
RESERVED
- 1 byte
- Unused, set to zero.
- \x00
Payload length
- 2 bytes
- This is a value of 40 bytes that I only know because I finished building the payload and came back to calculate this value.
- 40 in hex is 28.
- \x00\x28
Transform Number
- 1 byte
- This is the only transform we’re sending, and it’s the first, so 1.
- \x01
Transform ID
- 1 byte
- This value is specified by the DOI, so RFC2407 Section 4.4.2 says to simply use 1 for IKE.
- \x01
RESERVED2
- 2 bytes
- Two more bytes of mandatory zeros.
- \x00\x00

Transform IKE Attributes

Encryption Algorithm
- 4 bytes
- As we worked out above, this should be four bytes for a TV (starting with 80).
- Next, comes the encryption algorithm attribute class of 1.
- The attribute class value portion of this TV was a little tricky because AES came out well after RFC2409 was published.
- That information is laid out in RFC3602 (The AES-CBC Cipher Algorithm and Its Use with IPsec) Section 5.1, and indicates that the AES ID is “7”.
- \x80\x01\x00\x07
Key Length
- 4 bytes
- We’re using a Key Length (class attribute of 14, or 0e in hex) of 128 bits (80 in hex), and this is a TV as well, so we get:
- \x80\x0e\x00\x80
Hash Algorithm
- 4 bytes
- We’re using a hash algorithm (class attribute of 2) of SHA (which is also a value of 2), and again we’re getting these values from RFC2409 Appendix A.
- Also, this field is a TV, which means it again starts with \x80 and is 4 bytes, so we have:
- \x80\x02\x00\x02
Diffie-Hellman Group
- 4 bytes
- For the Group Description (class attribute of 4) we’re going to use DH Group 5, which scouring RFC2409 Appendix A again tells us is a value of 5.
- This is again a TV (starts with \x80) and is 4 bytes:
- \x80\x04\x00\x05
Authentication Method
- 4 bytes
- For the Authentication Method (class attribute of 3) we are using a pre-shared key (value of 1):
- \x80\x03\x00\x01
Lifetime
- 4 + variable bytes (8 in this case)
- We’re going to set a lifetime of one day (or 86400 seconds).
- This breaks into two fields.
  - First a TV of Life Type (what are we measuring, seconds or kilobytes) with:
    - A class attribute of 11 (0b in hex) and a value of 1 for seconds.
  - Next is a TLV (which starts with 00 instead of 80) of Life Duration (how many of that unit) with:
    - A class attribute of 12 (0c in hex), a two-byte length field with a value of 4 bytes, and a value of 86400 decimal = 0x15180 hex (written as \x00\x01\x51\x80 in big-endian).
- \x80\x0b\x00\x01\x00\x0c\x00\x04\x00\x01\x51\x80

The Complete Hex String

Now to add all of this into one giant string of hexadecimal:

1

\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x01\x10\x02\x00\x00\x00\x00\x00\x00\x00\x00\x58\x00\x00\x00\x3c\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x00\x30\x01\x01\x00\x01\x00\x00\x00\x28\x01\x01\x00\x00\x80\x01\x00\x07\x80\x0e\x00\x80\x80\x02\x00\x02\x80\x04\x00\x05\x80\x03\x00\x01\x80\x0b\x00\x01\x00\x0c\x00\x04\x00\x01\x51\x80

This 88-byte packet represents a complete ISAKMP Phase 1 Identity Protection exchange initiation with the transform set we defined above.

Conclusion

Building ISAKMP packets byte-by-byte is tedious but educational. It gives you deep insight into how VPN protocols work at the wire level. For practical testing, use the ready-made packet from Part 2 or tools like ike-scan.

Key Takeaways:

ISAKMP packets have nested payload structures (SA → Proposal → Transform)
Each payload has its own header with length fields
Transform attributes use TLV/TV encoding
Length fields must be calculated backward from inner payloads
Understanding this structure helps debug VPN issues

For those interested in automating this process, consider exploring Python with the Scapy library for dynamic packet construction.

Testing ISAKMP Part 2: Pre-Built Packets

Sat, 07 Feb 2026 10:00:00 -0500

In my previous post about using netcat to test ISAKMP, I validated that UDP/500 was open to the destination, and that semi-valid ISAKMP headers were being received by the peer (a Cisco ASAv in this case). However, this validation required me to be knowledgeable in troubleshooting the Cisco ASA platform so that I could easily determine if my pseudo-ISAKMP packets arrived (and also required that I control or have access to the ASA). What if the peer is outside of your control or is a platform you are not at all familiar with? In that case, what I want to do now is send a complete ISAKMP initial communication and receive a reply from the peer. This test serves the dual purpose of removing the need for debugs or logging on the peer and validates the return path (and any stateful/L7 inspection) as well.

Rather than hand-crafting every byte again, I based this packet on an actual captured ISAKMP conversation. If you don’t have a capture handy, you can find ISAKMP protocol details and examples at the Wireshark ISAKMP Protocol page.

Want to understand how this packet was built? Check out Part 3 for a detailed byte-by-byte breakdown of ISAKMP packet construction.

The Test Packet

I’ve constructed a complete 88-byte ISAKMP Phase 1 packet with the following transform set:

Encryption: AES-128-CBC
Hash: SHA-1
DH Group: Group 5 (1536-bit MODP)
Authentication: Pre-Shared Key
Lifetime: 86400 seconds (24 hours)

⚠️ Security Notice: This packet uses legacy cryptographic parameters for maximum compatibility with older devices. For production VPNs, use:

Hash: SHA-256 or SHA-384

Encryption: AES-256-CBC or AES-256-GCM

DH Group: Group 14 (2048-bit) or higher

Consider IKEv2 instead of IKEv1 for modern deployments

Quick Reference

For those who want to skip the detailed explanation and just test connectivity, here’s everything you need:

Complete ISAKMP Test Packet:

1

ISAKMP_PACKET="\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x01\x10\x02\x00\x00\x00\x00\x00\x00\x00\x00\x58\x00\x00\x00\x3c\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x00\x30\x01\x01\x00\x01\x00\x00\x00\x28\x01\x01\x00\x00\x80\x01\x00\x07\x80\x0e\x00\x80\x80\x02\x00\x02\x80\x04\x00\x05\x80\x03\x00\x01\x80\x0b\x00\x01\x00\x0c\x00\x04\x00\x01\x51\x80"

Basic Test:

1

echo -ne "$ISAKMP_PACKET" | nc -u TARGET_IP 500

With Timeout and Response Capture:

1

echo -ne "$ISAKMP_PACKET" | timeout 5 nc -u TARGET_IP 500 | hexdump -C

What This Packet Offers:

Encryption: AES-128-CBC
Hash: SHA-1
DH Group: Group 5 (1536-bit MODP)
Authentication: Pre-Shared Key
Lifetime: 86400 seconds (24 hours)

Testing the Complete Datagram

Now that we have our complete ISAKMP packet, let’s test it with netcat. The beauty of this approach is that we’ll get a proper ISAKMP response back if the peer is functioning correctly, eliminating the need for debug access.

Basic Test

1

echo -ne "$ISAKMP_PACKET" | nc -u 192.168.1.1 500

Enhanced Test with Timeout

For better control and to avoid hanging connections, use netcat with a timeout:

1

echo -ne "$ISAKMP_PACKET" | timeout 5 nc -u 192.168.1.1 500

Capturing the Response

To see the hex response for analysis:

1

echo -ne "$ISAKMP_PACKET" | timeout 5 nc -u 192.168.1.1 500 | hexdump -C

Expected Results

Analyzing the Response

When you receive a response, here’s how to decode it:

Bytes 0-7 (Initiator Cookie):

1

00 00 00 00 00 00 00 01

Should match YOUR initiator cookie - confirms this is a reply to your packet.

Bytes 8-15 (Responder Cookie):

1

a1 b2 c3 d4 e5 f6 07 08

Non-zero random value - the peer’s SPI. Save this for multi-packet exchanges.

Byte 16 (Next Payload):

01 = SA payload (peer accepted and is proposing parameters)
0d = Notification payload (usually an error)

Byte 18 (Exchange Type):

02 = Identity Protection (Main Mode) - normal
05 = Informational - usually error notification

Bytes 24-27 (Length):

1

00 00 00 84

Total packet length (132 bytes). Longer responses typically mean successful negotiation.

Common Notification Payloads:

0e 00 (14) = NO-PROPOSAL-CHOSEN - transform set mismatch
18 00 (24) = AUTHENTICATION-FAILED - PSK/cert issue
0d 00 (13) = INVALID-PAYLOAD-TYPE - malformed packet

Successful Response

If the ISAKMP peer is functioning correctly, you should receive a response that:

Has the same initiator cookie (00 00 00 00 00 00 00 01) in the first 8 bytes
Contains a responder cookie (non-zero values in bytes 9-16)
Shows exchange type 02 (Identity Protection) in byte 18
Has a reasonable length (typically 100+ bytes for a full SA response)

Example successful response header:

1
2


00000000 00 00 00 00 00 00 00 01 a1 b2 c3 d4 e5 f6 07 08 |................|
00000010 01 10 02 00 00 00 00 00 00 00 00 84 |............|

Error Responses

Different error conditions will produce different responses:

No Matching Transform Sets:

You’ll get a response with a Notification payload
The notification will indicate “NO-PROPOSAL-CHOSEN” (error 14)

Authentication Issues:

May receive “AUTHENTICATION-FAILED” notification
Or connection may be silently dropped

Firewall/NAT Issues:

No response at all (timeout)
Or ICMP unreachable messages

Troubleshooting Tips

No Response

Check basic connectivity first with a simple UDP test
Verify the target IP is actually running ISAKMP/IKE
Check for NAT/firewall blocking UDP/500
Try different source ports - some firewalls are picky
Wait between attempts - rate limiting may block rapid tests (30-60 seconds)

Malformed Packet Errors

Double-check the hex string - any typos will break the packet
Verify packet length matches the length field in the header
Test with Wireshark to validate packet structure

Transform Set Mismatches

Try different encryption algorithms (3DES, AES-256)
Adjust DH groups (Group 2, Group 14)
Change hash algorithms (MD5, SHA-256)

NAT Considerations

NAT Detection: If testing through NAT, be aware:

Source port randomization may break return traffic
Some firewalls require NAT-T (UDP 4500) for NATed ISAKMP
ESP (protocol 50) will be blocked by NAT without NAT-T

Testing through NAT:

1
2


# Bind to specific source port
echo -ne "$ISAKMP_PACKET" | nc -u -p 500 TARGET_IP 500

NAT-T Detection: Modern VPN gateways may respond on UDP 4500 instead of 500 if NAT is detected.

Aggressive Mode vs Main Mode

This packet uses Main Mode (Identity Protection). If you get no response, the peer might only support Aggressive Mode:

Change Exchange Type from \x02 to \x04 (byte 18)
Note: Aggressive Mode is deprecated due to security weaknesses

IKEv2 Confusion

If you get INVALID_MAJOR_VERSION notification:

Target only supports IKEv2 (RFC 7296)
This technique only works for IKEv1
Use ike-scan tool for IKEv2 testing

Validating Your Packet

Before testing against production systems, validate your packet structure:

1
2
3


# Capture your test packet
echo -ne "$ISAKMP_PACKET" | nc -u 127.0.0.1 500 &
sudo tcpdump -i lo -w test.pcap udp port 500

Open in Wireshark and verify:

ISAKMP protocol is correctly decoded (not “Malformed Packet”)
All payload lengths match actual payload sizes
Transform attributes are properly formatted
No “Expert Info” warnings about malformed fields

Alternative Tools

While this manual method teaches protocol internals, consider these tools for production use:

ike-scan:

1

ike-scan -M TARGET_IP

Supports IKEv1 and IKEv2
Tests multiple transform sets automatically
Better for production troubleshooting

nmap:

1

nmap -sU -p 500 --script ike-version TARGET_IP

Detects IKE version support
Identifies vendor implementations

When to use manual method:

Learning protocol internals
Highly restricted environments (no tools available)
Testing specific edge cases
Forensic analysis of VPN behavior

Conclusion

By using a pre-crafted complete ISAKMP datagram, we’ve eliminated the dependency on having debug access to the peer device. This approach validates outbound connectivity (UDP/500 reachability), peer responsiveness, and return path functionality - all without needing access to the remote device.

For a detailed breakdown of how this packet was constructed, see Part 3. For automated testing with Python and Scapy, check out Part 4.

References

Next Steps:

Want to understand how this packet was built? Read Part 3
Explore automating this with Python and the Scapy library
Check out ike-scan for more advanced VPN testing scenarios

Parsing Network Device Output Part 3: CiscoConfParse

Mon, 19 Jan 2026 10:55:00 -0500

In the first post in this series, I talked briefly about utilizing Regular Expressions (Regex) to parse network device output. Next, I delved into the difference between status and configuration when it comes to network device output, and why you might use one tool vs another depending on which type of output you are working with.

As a brief refresher, network device output (from a traditional CLI session) can generally come in two forms:

Status
- An output that presents some attribute or information about the current state of the device or its performance.
- Example commands for gathering status include:
  - show version
  - show interfaces
- Example commands for modifying status include:
  - clear counters
  - reload
Configuration
- An output that presents the desired/requested operating condition of the device.
- Example commands for gathering configuration include:
  - show running-config
  - show startup-config

In this post, we’ll look at one of the open-source parsing libraries that exist for network device configuration: CiscoConfParse.

Why Not Just Use Regex?

CiscoConfParse, as well as Hierarchical Configuration (heir_config) which we’ll cover in the next post, provide much more power than simply using Regex to match and extract a pattern from a line of status or configuration. These parsing libraries provide a framework to understand and manipulate “Cisco style” configuration (with indented blocks representing related items), or even “Juniper style” curly brace ({}) delineated configuration.

If you think about the previous Regex example, how would we utilize Regex to easily parse the following configuration output, specifically looking to answer this question:

What interfaces have security-level 0 configured on them?

!
interface GigabitEthernet0/0
description OUTSIDE-VLAN300-10.10.10.0/24
nameif OUTSIDE
security-level 0
ip address 10.10.10.50 255.255.255.0
!
interface GigabitEthernet0/1
no nameif
no security-level
no ip address
!
interface GigabitEthernet0/1.400
description INSIDE-VLAN400-10.10.40.0/24
vlan 400
nameif INSIDE
security-level 100
ip address 10.10.40.1 255.255.255.0
!
interface Management0/0
management-only
nameif MGMT
security-level 0
ip address 10.10.60.2 255.255.255.0

For example, you can certainly search for the string “security-level 0”, however how do you then tie it back to the interface above it? Remember that when we’re evaluating a string with Regex, we can work on a multi-line string. We would have to set up capturing groups for the interface and nameif, and then only match if there was also our target string. And while, of course, this is doable, it quickly becomes cumbersome to do for every item you wish to match. Also consider, what if you want to output the entire interface configuration for any interface that matches “security-level 0”? There is a better and simpler way to handle this.

Enter CiscoConfParse

CiscoConfParse solves this problem, and more, by breaking the configuration into parent/child chunks and allowing you to search and find based on the contents of either. For an in-depth walk-through and examples I highly recommend the CiscoConfParse documentation; below we’ll simply demonstrate a quick use case.

For our test environment, we’re utilizing the same firewall pair and management station from the previous post:

In this series of posts, we’ll just use the simple network shown here. There is a Management Station with Python 3.8 installed, and two Cisco ASAv firewalls (ASAv1 and ASAv2) in a tiered setup.

Code samples and requirements.txt for this post can be found on my Github.

Below is an example script, based on the previous examples in this series, where we log into these ASAs, gather the output of show run interface, and print out the interface(s) with security-level 0 configured.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66


#!/usr/bin/env python3

"""
Example code for Network-Notes.com entry on Parsing Network Device Output
"""

import getpass
import sys


from ciscoconfparse import CiscoConfParse
from netmiko import ConnectHandler


"""
Test parsing network device configuration
"""

# Gather the needed credentials
net_device_username = input("Username: ")
net_device_password = getpass.getpass()
# Set enable/secret = password for now
net_device_secret = net_device_password

# Setup a dict with our ASAvs in it, in real world this could be read
# from a CSV or the CLI or any other source
firewalls = {
 "ASAv1": {"ip": "10.10.10.50", "platform": "cisco_asa"},
 "ASAv2": {"ip": "10.10.60.2", "platform": "cisco_asa"},
}

# Setup an empty dict for our results:
results = {}

# Instantiate netmiko connection objects and gather the output of
# `show run interface` on these two firewalls
for fw_name, fw_data in firewalls.items():
 print(f"Connecting to {fw_name}...")
 fw_connection = ConnectHandler(
 ip=fw_data["ip"],
 device_type=fw_data["platform"],
 username=net_device_username,
 password=net_device_password,
 secret=net_device_secret,
 )
 results[fw_name] = fw_connection.send_command(
 command_string="show run interface"
 )

# Parse our results:
print("Parsing Results...")
outside_interfaces = {}
for fw_name, config in results.items():
 interface_config = CiscoConfParse(config=config.splitlines())
 outside_interfaces[fw_name] = interface_config.find_objects_w_child(
 parentspec=r"^interface", childspec="security-level 0"
 )

# Print our results
for fw_name, interface_list in outside_interfaces.items():
 print(f"==== ==== [ {fw_name} \"Outside\" interfaces ] ==== ====\n")
 for interface in interface_list:
 print(f" ==== [ {interface.text} ] ==== \n")
 for line in interface.ioscfg:
 print(f"{line}")
 print("\n")

It will produce the following output when executed:

Username: cisco
Password:
Connecting to ASAv1â€¦
Connecting to ASAv2â€¦
Parsing Resultsâ€¦
==== ==== [ ASAv1 "Outside" interfaces ] ==== ====
==== [ interface GigabitEthernet0/0 ] ====
interface GigabitEthernet0/0
description OUTSIDE-VLAN300-10.10.10.0/24
nameif OUTSIDE
security-level 0
ip address 10.10.10.50 255.255.255.0
ospf authentication-key
ospf message-digest-key 1 md5
ospf authentication message-digest
==== ==== [ ASAv2 "Outside" interfaces ] ==== ====
==== [ interface Management0/0 ] ====
interface Management0/0
management-only
nameif MGMT
security-level 0
ip address 10.10.60.2 255.255.255.0

As you can see, we easily found the interfaces we needed, and have the entire configuration. Now let’s break apart what happened a little bit more.

Parent/Child Relationships

CiscoConfParse understands the hierarchical nature of Cisco-style configuration. In our example:

Parent: interface GigabitEthernet0/0
Children: All indented lines under that interface (description, nameif, security-level, etc.)

The key method in our script is:

1
2
3


interface_config.find_objects_w_child(
 parentspec=r"^interface", childspec="security-level 0"
)

This searches for:

parentspec: Lines matching regex ^interface (lines starting with “interface”)
childspec: That have a child line containing “security-level 0”

The result is a list of IOSCfgLine objects representing matching parent interfaces.

Key CiscoConfParse Methods

find_objects() - Find lines matching a regex pattern
find_objects_w_child() - Find parents with specific children
find_objects_wo_child() - Find parents without specific children
find_children() - Find all children of a parent

Each object provides:

.text - The configuration line text
.ioscfg - Complete configuration block (parent + children)
.children - List of child objects

Why This Matters

Compare this to the regex approach from Part 1. To find interfaces with security-level 0 using regex, you’d need complex multi-line patterns and capturing groups. CiscoConfParse makes it intuitive by understanding configuration structure.

This is particularly powerful for:

Security audits (find interfaces with specific settings)
Configuration validation (ensure required settings exist)
Bulk changes (identify what needs updating)

What’s Next

In the next post, we’ll explore Hierarchical Configuration (hier_config), which builds on these concepts to provide configuration comparison and remediation capabilities.

Conclusion

CiscoConfParse transforms configuration parsing from complex regex gymnastics into readable, maintainable code. By understanding parent/child relationships in network configurations, it makes complex parsing tasks simple and intuitive.

Migrating from WordPress to Hugo on Cloudflare Pages

Tue, 11 Jul 2023 13:42:23 -0400

After years of running WordPress on a self-hosted DigitalOcean droplet, I decided it was time for a change. The site was slow, required constant maintenance, and felt like overkill for a simple blog. Here’s how I migrated to Hugo and Cloudflare Pages.

The Old Setup

My previous infrastructure:

Hosting: DigitalOcean droplet ($12/month)
CMS: Self-hosted WordPress with MySQL
CDN: Cloudflare (free tier) in front
Maintenance: Regular updates, security patches, backups
Performance: Decent, but database queries added latency

The droplet ran Ubuntu with Apache, PHP, MySQL, and all the typical WordPress stack. It worked, but it felt heavy for what was essentially a collection of markdown-style posts.

Why Hugo?

I wanted something:

Fast: Static sites are blazing fast
Simple: No database, no PHP, just HTML/CSS/JS
Portable: Content in markdown, easy to version control
Free: Cloudflare Pages offers free hosting
Secure: No CMS to hack, no database to compromise

Hugo checked all these boxes. It’s a static site generator written in Go that’s incredibly fast and has a great ecosystem of themes.

The Migration Process

1. Export WordPress Content

I used the built-in WordPress export tool to generate an XML file with all posts, then converted them to markdown format. Several tools exist for this conversion, including wordpress-to-hugo-exporter and various online converters. Manual cleanup was necessary afterward to fix formatting inconsistencies.

2. Choose a Theme

I selected the Terminal theme for its clean, minimal design. The retro terminal aesthetic fits well with technical content and provides excellent readability.

3. Set Up Hugo Locally

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


# Install Hugo
brew install hugo

# Create new site
hugo new site network-notes.com
cd network-notes.com

# Add theme
git submodule add https://github.com/panr/hugo-theme-terminal.git themes/terminal

# Configure
cp themes/terminal/exampleSite/config.toml .
# Edit config.toml with my settings

4. Migrate Content

I moved all the converted markdown files into content/posts/ organized by year:

1
2
3
4
5


content/
└── posts/
 ├── 2015/
 ├── 2016/
 └── 2020/

Each post needed some cleanup - fixing image paths, updating internal links, and adjusting frontmatter.

5. Set Up Cloudflare Pages

Cloudflare Pages is incredibly simple:

Push Hugo site to GitHub
Connect GitHub repo to Cloudflare Pages
Configure build settings:
- Build command: hugo
- Build output directory: public
- Environment variable: HUGO_VERSION=0.120.0

That’s it. Every push to main triggers a new build and deployment.

6. Configure DNS

Updated my Cloudflare DNS to point to Pages:

1

network-notes.com → CNAME → network-notes-com.pages.dev (proxied)

I also set up a preview branch:

1

blog2.network-notes.com → CNAME → preview.network-notes-com.pages.dev (proxied)

This lets me review posts before publishing to production.

7. Decommission DigitalOcean

Once everything was working, I:

Backed up the WordPress database (just in case)
Took a final snapshot of the droplet
Destroyed the droplet
Saved $12/month

The Results

Performance: Page load times dropped from ~800ms to ~200ms. Static HTML is fast.

Maintenance: Zero. No more WordPress updates, no more security patches, no more database backups.

Cost: $0/month for hosting (Cloudflare Pages free tier is generous)

Workflow: Write in markdown, commit to git, automatic deployment. Much better than the WordPress editor.

Reliability: Cloudflare’s global CDN means the site is fast everywhere and has excellent uptime.

Infrastructure as Code

I manage all my DNS and Cloudflare configuration with Terraform. The network-notes.com configuration includes:

DNS records
Page rules for caching
SSL/TLS settings
Preview branch setup

Everything is version controlled and reproducible, making it easy to recreate or modify the infrastructure.

Lessons Learned

Markdown is powerful: Once you get used to writing in markdown, it’s hard to go back to WYSIWYG editors.

Static sites aren’t limiting: For a blog, you don’t need dynamic content. Comments can be handled by external services if needed.

Git-based workflows are great: Having your entire site in version control is liberating. Rollbacks are trivial, history is preserved, and collaboration is easy.

Cloudflare Pages is excellent: The free tier is generous, builds are fast, and the preview deployments are incredibly useful.

Absolutely, if you’re running a simple blog or documentation site. The migration took a weekend, but the ongoing benefits are worth it:

No more server maintenance
Faster site
Better workflow
Lower costs
More secure

If you need dynamic features (user accounts, complex forms, e-commerce), WordPress or another CMS might still make sense. But for content-focused sites, static site generators like Hugo are hard to beat.

Resources

The blog is now faster, cheaper, and easier to maintain. Sometimes simpler really is better.

Parsing Network Device Output Part 2: Status or Configuration?

Sat, 21 Mar 2020 20:01:00 -0500

A Brief Interlude

In my first post in this series, I dove into utilizing Regular Expressions (Regex) to parse network device output. Before I continue with some of the other parsing options, I thought it would be worthwhile to post a short blog laying out some definitions that I’ll be relying on. Specifically, I’ll be using them for delineation among the different parsing options and their use cases.

At the heart of this problem, is that when interacting with traditional network devices there aren’t many programmatic options, such as a REST API, to return structured data. Sure, you could use SNMP for some things, but not for everything. In addition, working with SNMP can be its type of nightmare, believe me, I’ve fought that fight many times in the past. This is changing as the industry matures, Cisco even has an entire certification track around utilizing their APIs now, however even today most Network Engineers’ first foray into automation uses SSH to query a device for information. This brings us to output.

What is Output?

For our purposes, “Output” will be defined as any response that a network device returns when given a command via its Command Line Interface (CLI). This could be accomplished by many means; depending on the network device in question the CLI could be reached via Telnet, SSH, or even HTTPS. No matter the access method, the network device is still returning the same data, our output.

Execute show version on a Cisco-like device, and it will return some form of the status of the version as that device understands it. It will be structured, loosely, for human consumption with perhaps headings/titles or indentation/punctuation for legibility. It will not generally be structured in a way that would easily allow a computer program to understand and interact with it.

Just as you can issue show version and get output, you can similarly on most network devices execute a command akin to show running-config and get output. This would return some form of data about the configuration that was currently in use on that network device. Again, it will have some form of structure, usually either delineated by indentation or curly braces ({}), but mostly it will be in a form that is not easily understood or manipulated by a computer program that you are writing.

I make the specific call out that it may not easily be understood by a program that you are writing because of course the network device itself can take that configuration and turn it into actionable information. However, that does us no good, as most vendors aren’t open sourcing their internal operating systems’ parsing logic.

Status vs. Configuration

In the two examples above, we received output from a network device after we issued a command via the CLI. One gave us some sort of status about the device, and the other gave us information about its configuration. Broadly speaking, all CLI commands on a network device fall into these two categories. You are either gathering or changing the status of the device with commands such as show version, show flash, or clear counters. Or you are gathering or changing the configuration of the device with commands such as show running-config, or config t;interface e1/0;no shutdown.

It is vital to keep in mind which type of information you’re looking for or what changes you are trying to make, and whether it involves the device’s status or configuration. This will heavily influence how you parse/interact with the output that the device has given you. Some parsing methods or libraries are made specifically for turning configuration into something easy to manipulate/change in Python (CiscoConfParse, Heir Config), and some are more generic and can parse both status and configuration (Regex, TextFSM, Genie).

In the next post, I’ll dive into CiscoConfParse first, and we’ll see how it can make the act of understanding and manipulating traditional unstructured network device configuration much simpler.

Parsing Network Device Output Part 1: Regex

Wed, 04 Mar 2020 20:17:00 -0500

In the Beginning

Often when making their first steps into Network Automation, people may have an idea of what they want to do, but not exactly how to get there. For example, an engineer may want to simplify a single time-intensive task “Gather the SW version, serial numbers, and uptime from all of my Cisco ASAs.” However, upon getting the information, they’re unsure what to do with it or how to parse it and use it for something else. I’ve seen this question come up a few different times, and thought a series of blog posts was in order. Each of the posts (including this one) outline some sample parsing options. However, it is worth noting that Regex is not better or worse than using a parsing library, for example, they may just have different use cases.

First, in this post, I will outline the basics of gathering our information and parsing it directly with our own Regular Expressions (Regex).
Next, I will demonstrate parsing this information with the popular CiscoConfParse and HeirConfig libraries.
Third, I will demonstrate simple parsing with Google’s TextFSM and the awesome library of templates provided by Network To Code, ntc-templates.
Finally, I will demonstrate simple parsing with Cisco’s Genie/PyATS libraries.

Note that I am going to skip over a lot of the minutia of what Netmiko is, and how to use it to gather network device information, as there are many wonderful resources out there already on this. We’re going to focus primarily on what to do with the output once you have it.

Example Network

In this series of posts, we’ll just use the simple network shown here. There is a Management Station with Python 3.8 installed, and two Cisco ASAv firewalls (ASAv1 and ASAv2) in a tiered setup.

Code samples and “requirements.txt” for this post can be found on my Github.

Environment Preparation

For this entire series of posts, I will be working the examples in a python virtual environment setup with the following dependencies installed. Note that we’re installing iPython, which is a much better alternative to the built in Python interactive shell. I highly recommend checking it out by executing ipython in this virtual environment. iPython allows us to do some more interactive introspection on objects and method/object doc_strings in real time, which we’ll use in later posts.

iPython
Netmiko
CiscoConfParse
HeirConfig
NTC Templates
Genie/PyATS

First, I create a virtual environment with whatever name you wish, and then activate that environment:

1
2


python3.8 -m venv nn_examples
cd nn_examples;source bin/activate

Next, I install the dependencies as discussed above:

1

pip install ciscoconfparse genie hier-config ipython netmiko ntc_templates pyats

Gathering our Output

We need to instantiate a connection to our ASAs, and then execute the command “show version | inc So|Serial| up” against them to gather the needed output. Simple enough with Netmiko as shown below (or on Github):

raw_gather.py

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62


# !/usr/bin/env python3

"""
Example code for Network-Notes.com entry on Parsing Network Device Output
"""

import getpass
import re
import sys

from netmiko import ConnectHandler

"""
Test parsing network device configuration
"""

# Gather the needed credentials

net_device_username = input("Username: ")
net_device_password = getpass.getpass()

# Set enable/secret = password for now

net_device_secret = net_device_password

# Setup a dict with our ASAvs in it, in real world this could be read

# from a CSV or the CLI or any other source

firewalls = {
 "ASAv1": {"ip": "10.10.10.50", "platform": "cisco_asa"},
 "ASAv2": {"ip": "10.10.60.2", "platform": "cisco_asa"},
}

# Setup an empty dict for our results

results = {}

# Instantiate netmiko connection objects and gather the output of

# `show version | inc So|Serial| up` on these two firewalls

for fw_name, fw_data in firewalls.items():
 print(f"Connecting to {fw_name}...")
 fw_connection = ConnectHandler(
 ip=fw_data["ip"],
 device_type=fw_data["platform"],
 username=net_device_username,
 password=net_device_password,
 secret=net_device_secret,
 )
 results[fw_name] = fw_connection.send_command(
 command_string="show version | inc So|Serial| up"
 )

# Print our results

for fw_name, result in results.items():
 print(f"{fw_name} information:\n")
 print(result)

sys.exit()

Successfully executed with “python3.8 raw_gather.py”, this will output:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


 Username: cisco
 Password:
 Connecting to ASAv1â€¦
 Connecting to ASAv2â€¦
 ASAv1 information:

 Cisco Adaptive Security Appliance Software Version 9.12(1)2
 ASAv1 up 23 mins 50 secs
 Serial Number: 123456789AB

 ASAv2 information:

 Cisco Adaptive Security Appliance Software Version 9.13(1)2
 ASAv2 up 24 mins 5 secs
 Serial Number: 123456789AC

Now that we have an example of gathering the information, let’s parse it to python variables via Regex.

Parsing with Regex

Much like above, I will not exhaustively cover what Regex (Regular Expressions) are, as there are boundless resources on the internet (and good old O’Reilly books) that do this. Suffice to say for our purposes, that it is a way to match patterns in a string of text and gather output based on that, and that I strongly recommend finding a good test bed like Regex101 to help you along the way. You can get extremely complicated with Regex, and it can also bite you in the behind, just ask Cloudflare… Here is the three Regular Expressions I am using to match relevant output from the ASA with links to Regex101 examples demonstrating them.

Software Version:
- Software Version (\d.\d{1,2}(?:(?\d{1,2}?)?\d{1,2}?)?)\W*$
Uptime:
- up (.*)$
Serial Number:
- Serial Number: (\S*)$

Now here is what the program looks like utilizing the python re Regex module. The only difference is the addition of a section for parsing the output we’ve received, so that is all I’ll list below. The complete file is on Github as parse_with_regex.py:

raw_gather.py

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


# Parse our results

print("Parsing Results...")
parsed_results = {}
for fw_name, result in results.items():
 parsed_results[fw_name] = {}
 parsed_results[fw_name]["version"] = re.search(
 r"Software Version (\d.\d{1,2}(?:\(?\d{1,2}?\)?\d{1,2}?)?)\W*$",
 result,
 re.MULTILINE,
 )
 parsed_results[fw_name]["uptime"] = re.search(
 r"up (.*)$", result, re.MULTILINE
 )
 parsed_results[fw_name]["serial"] = re.search(
 r"Serial Number: (\S*)$", result, re.MULTILINE
 )

# Print our results

for fw_name in results.keys():
 print(f"{fw_name} information:\n")
 print(f"\tVersion: {parsed_results[fw_name]['version'].group(1)}")
 print(f"\tUptime: {parsed_results[fw_name]['uptime'].group(1)}")
 print(f"\tSerial Number: {parsed_results[fw_name]['serial'].group(1)}")

This will give us the results of:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


Username: cisco
 Password:
 Connecting to ASAv1â€¦
 Connecting to ASAv2â€¦
 Parsing Resultsâ€¦
 ASAv1 information:
 Version: 9.12(1)2
 Uptime: 1 hour 25 mins
 Serial Number: 123456789AB
 ASAv2 information:
 Version: 9.13(1)2
 Uptime: 1 hour 25 mins
 Serial Number: 123456789AC

As you can see, this is a much more structured and useful output. We could also similarly output this to a CSV or other data source, now that we have parsed the data into something of more value than a raw string of all the data.

Next Up, Parsing Libraries

In the next post I publish, I will utilize this same environment, but make use of some common configuration parsing libraries (CiscoConfParse and HeirConfig) to show how they could be useful for certain use cases.

Cisco Certification Program Refresh

Mon, 10 Jun 2019 12:30:00 -0500

One of the primary reasons I originally started this blog, was to use it for personal accountability with my Cisco certification progress. As I studied and understood a particular topic, I could write a blog article on that topic to cement it in my mind and share that knowledge with others.

The complete lack of blog posts reflects how well that plan went… I did complete my CCNP Security and was in pursuit of my CCIE Security when my career trajectory shifted. No longer was I solely a Network or Security Architect, an increasing portion of my role was focused on Network Automation and solving problems at a massive scale. I stopped chasing traditional networking certifications and spent many thousands of hours learning Python and Golang to best solve the problems I was faced with at my job.

While that work has been fulfilling and challenging, it doesn’t present itself well to the traditional Networking world mindset of “certification chasing”. Since I stopped actively pursuing Cisco certifications I have had more than one conversation where people have asked things like: “So where’s your CCIE at?” or “Are you going into management now?” As I looked at the Cisco certifications available, there wasn’t one that presented value to me and the work I was doing every day, beyond the basic knowledge acquired in getting my CCNA and CCNP Voice, Security, and Route/Switch in the past. I couldn’t justify the expense (in both money and time away from my family) to chase a CCIE if it didn’t apply to my career.

Well as of today, Cisco is announcing something that changes all of that, and I’m super excited. They are doing a complete, top to bottom, refresh and realignment of the certifications that are offered, and the process to get/keep them.

New and Improved Cisco Certifications

All the discussed changes below go into effect on February 24th, 2020. So you’ve got time to finish your existing studies or gear up for a new certification/track.

First and foremost, and the most personally exciting to me, is that there is a completely new certification track:

The New Certification Tracks from Cisco!

Now Network Automation/Netdevops is to be recognized via DevNet certifications in their track! Including up to a forthcoming DevNet Expert certification targeted at the same level of expertise expected out of CCIE-level folks.

According to DevNet the DevNet Professional level exam/certification is targeted at:

… developers who have at least three to five years of experience designing and implementing applications built on Cisco platforms. Two exams cover designing and developing resilient, robust and secure applications using Cisco APIs and platforms, and managing and deploying applications on Cisco infrastructure.

Cisco DevNet

This is exactly where I find myself sitting today, and I’m super excited to see that Cisco and the folks at DevNet are listening to the community and responding to this need! I will be one of the first people in line next February when these exams go live. And I can 100% see the value in pursuing the DevNet Expert examination in my career path.

Additional Changes

There are some significant changes to the certification paths, even inside the existing network-focused paths.

No more prerequisites for any Cisco certification, if you’re at the Professional or Expert level in your field, go sit that exam.
All certifications are good for 3 years from the last pass date (including Expert level).
There are now additional options, including Continuing Education, for renewing your certifications at all levels.
Associate level (CCNA or DevNet Associate) is one exam.
Professional level (CCNP or DevNet Professional) is two exams:
- A Core skills exam in your track.
- A Concentration exam in a more specific area of focus to your specialization.
Taking additional specialization exams will grant you Cisco Specialist badges/awards.
The tracks available to the Networking path narrow down to Enterprise, Security, Service Provider, Collaboration, and Data Center.
- For example, Route/Switch and Wireless are being collapsed into the Enterprise track.
- Each of these topics now exists as a concentration or specialization exam inside the Enterprise track at the Professional level.
- If you’re mid-CCNP and want to know what the path forward for you looks like:

As discussed above, these changes will go into place on February 24th, 2020. However, exam topics and other information are now live via the links below. And expect MANY blog posts and other information from Cisco in the coming days, weeks, and months.

Happy Certing!

#CiscoChampion 2019

Fri, 04 Jan 2019 08:18:00 -0500

Happy 2019 everyone! Since I was lucky enough to be selected as a Cisco Champion for 2019, I thought it was time to revive my zombie blog!

I’ve got quite a few posts in the hopper and will focus on not being such a perfectionist to posts that I don’t just hit that “Publish” button. Posts will be coming about:

Network Security
Network Programmability
Python
Systems Architecture
And more!

Here’s to an exciting and educational 2019!

Testing ISAKMP Part 1: Basic Connectivity

Fri, 20 May 2016 22:44:00 -0500

The Scenario

In the course of my day-to-day job, I interact with VPNs on many devices (primarily IPSec VPNs on the Cisco ASA). Oftentimes the simplest way to test an IPSec VPN is to fire up vpnc in a VM, change the config file as needed, and validate the connection.

Sometimes though, you need to be more granular with your testing. Perhaps the person controlling the other endpoint/peer is not in charge of the intermediate network, and you need to validate that ISAKMP traffic is allowed through to the peer. Perhaps you want to validate an ACL that should be blocking ISAKMP. Or perhaps you’re just curious to gain a deeper understanding of what is happening at the protocol level. Either way, there’s no easy way to validate that ISAKMP is permitted end to end.

Because ISAKMP utilizes UDP port 500 for transport, you can’t simply Telnet to the port and validate that it is permitted. We’re talking about UDP, not TCP, which means there is no Layer 4 validation of an open socket (the Three-Way-Handshake of TCP). This means that you can’t do something like nc -uvv $host 500 because while netcat can certainly open and utilize UDP sockets, netcat alone can’t tell you if a UDP port is open and listening. To test this below, I attempt to use netcat to check whether my local box is listening on UDP port 500 (which I know it is not):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


$ nc -uvv 127.0.0.1 500
 found 0 associations
 found 1 connections:
 1: flags=82
 outif (null)
 src 127.0.0.1 port 59894
 dst 127.0.0.1 port 500
 rank info not available

Connection to 127.0.0.1 port 500 [udp/isakmp] succeeded!

Succeeded indeed… Although we need to do something more to validate whether UDP/500 is open and listening for ISAKMP datagrams, as mentioned above we can still actually utilize netcat We can use it to open the UDP socket and then pipe in semi-valid ISAKMP data for netcat to pass to our destination. This way, we can at least get some sort of response or validation via either an ISAKMP reply message or debugs/counters on the far side peer.

RFC2048 – Internet Security Association and Key Management Protocol

ISAKMP is defined in RFC2048, which describes in great detail the underlying structure of an ISAKMP UDP datagram. In section 3.1, it lays out the header format which is all we need for testing:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


 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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ! Initiator !
 ! Cookie !
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ! Responder !
 ! Cookie !
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags !
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ! Message ID !
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ! Length !
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Essentially, if you haven’t seen this style of packet diagram, each number across the top represents a bit, and each row represents 32 bits or 4 octets/bytes whichever you prefer. In this case, the ISAKMP header is 7 rows tall, which means that the ISAKMP header is 224 bits (7*32), or more commonly, 28 bytes long.

Now we know how long the data has to be, but what are we going to put into it? The header breaks down into the following chunks:

Initiator and Responder Cookies
- 8 bytes per Cookie
- These are tokens that enable each endpoint to identify Security Associations (RFC2048, Sec 2.4), and to act as a method to assist in securing the communication (RFC2048, Sec 2.5.3).
- Also known as the Security Parameter Index (SPI).
Next Payload
- 1 byte
- Indicates what type of message is following this header.
Major Version and Minor Version
- 4 bits each
- Set to 1 and 0 respectively in RFC2048.
Exchange Type
- 1 byte
- Tells the other system what type of messages and payloads to expect.
Flags
- 1 byte
- Set specific ISAKMP options; only the first three bits are specified in RFC2048 rest are to be zeros.
Message ID
- 4 bytes
- A unique ID is used in Phase 2 negotiations; as we’re simulating a Phase 1 datagram these are set to all zeros.
Length
- 4 bytes
- The combined length of the header and payloads is represented in bytes/octets.

Taking this information, we are now able to determine what fields we need to fill out and with what values to create our testing datagram. Once we are complete, we can simply feed the appropriate arrangement of binary into netcat, and it should be able to simulate the beginning of a valid ISAKMP exchange with the peer.

The only hitch with this plan is the need for binary. For mere humans, visually tracking long strings of binary is not easy; at a glance can you tell if this is 7 or 8 digits 00000001? In addition, writing out each byte would get tedious and increase the likelihood of human error.

Hexadecimal to the Rescue

Luckily we can shortcut this process by representing the binary values with Hexadecimal in \x notation. This allows us to simply represent each byte or octet as a four-character string. For example:

1
2
3
4
5


Binary: 000000000000000100000010000000011
Hexadecimal: \x00\x01\x02\x03

Validation using xxd:
printf '\x01\x02\x03\x04' | xxd -b 0000000: 00000001 00000010 00000011 00000100 ....

Working with that format, and referencing the above breakdown of the header format gives us the following Hexadecimal:

Initiator and Responder Cookies
- 8 bytes per Cookie
- Initiator Cookie
  - We’ll make this a value of 1 since it has to be something and we don’t care what it is.
  - \x00\x00\x00\x00\x00\x00\x00\x01
- Responder Cookie
  - All zeros because this is an initial communication.
  - \x00\x00\x00\x00\x00\x00\x00\x00
Next Payload
- 1 byte
- No Next Payload, so a value of 0.
- \x00
Major Version and Minor Version
- 4 bits each
- Mandatory values of 1 and 0, because we’re using ISAKMP version 1.0
- That would be 0001 and 0000 in binary.
- Together, that would look like 00010000, which equals 10 in Hex.
- \x10
Exchange Type
- 1 byte
- We’re making a fake datagram with no payload, so we’ll try none (0) which appears to be permitted by RFC2048.
- \x00
Flags
- 1 byte
- No specific flags are needed, so we’re also setting this to 0.
- \x00
Message ID
- 4 bytes
- Must be zeros per RFC2048 for an initial Phase 1 datagram like we’re simulating.
- \x00\x00\x00\x00
Length
- 4 bytes
- This will be equal to 28 since we have a header with no payload.
- 28 in Hex is 1C.
- \x1C

Finally, our complete string of Hex for the simulated initial ISAKMP datagram would be:

1

\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x10\x00\x00\x00\x00\x00\x00\x1C

Sending Our Data

Now that we have the complete Hex string for our test datagram, how do we go about sending it? Well as described earlier, we’re going to simply pass it into netcat by printing the string and piping it into netcat. But first, we need to get a destination setup that is listening for ISAKMP traffic. In my case, I’ve spun up a virtual Cisco ASA in my lab to act as our peer, and have it listening for ISAKMP traffic on the INSIDE interface (172.16.16.1).

1
2
3
4
5
6
7
8
9


ASAv-1A/pri/act# show run int G0/4
!
 interface GigabitEthernet0/4
 nameif INSIDE
 security-level 100
 ip address 172.16.16.1 255.255.255.0
 standby 172.16.16.2
ASAv-1A/pri/act# show run crypto ikev1
 crypto ikev1 enable INSIDE

Taking the above Hex string and using printf to send it into netcat gives us the following output (all of the Hex should be on one line, however for readability I have broken it up here):

1
2
3
4


$ printf \x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00
 \x00\x00\x00\x00\x10\x00\x00\x00\x00\x00\x00\x1C | nc -uvv 172.16.16.1 500
Connection to 172.16.16.1 500 port [udp/isakmp] succeeded!
^C

As you can see, netcat says “Connection succeeded” again, and the output on our end is not so different from when we tested to a non-ISAKMP speaking endpoint. However, on the ASA IKEv1 statistics, we can see something very interesting:

1
2


ASAv-1A/pri/act# show crypto ikev1 stats | inc Drop
In Drop Packets: 6 Out Drop Packets: 0

So the ASA saw the packet and marked it as invalid in some way then dropped it (which makes sense because we didn’t send any payload at all).

This validates that the path for UDP/500 is open from my test box to the peer!

Bonus Validations

I’m a curious soul though, so I wanted to dig deeper still. For more detail we can turn on the IKEv1 debugs on the ASA and see as it is receiving and discarding each of the packets:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


ASAv-1A/pri/act# debug crypto ikev1 255
ASAv-1A/pri/act#
May 21 03:25:04 [IKEv1]IKE Receiver: Packet received on 172.16.16.1:500 from 172.16.16.16:39994
May 21 03:25:04 [IKEv1]IKE Receiver: Runt ISAKMP packet discarded on Port 500 from 172.16.16.16:39994
May 21 03:25:04 [IKEv1]IKE Receiver: Packet received on 172.16.16.1:500 from 172.16.16.16:39994
May 21 03:25:04 [IKEv1]IKE Receiver: Runt ISAKMP packet discarded on Port 500 from 172.16.16.16:39994
May 21 03:25:05 [IKEv1]IKE Receiver: Packet received on 172.16.16.1:500 from 172.16.16.16:39994
May 21 03:25:05 [IKEv1]IKE Receiver: Runt ISAKMP packet discarded on Port 500 from 172.16.16.16:39994
May 21 03:25:06 [IKEv1]IKE Receiver: Packet received on 172.16.16.1:500 from 172.16.16.16:39994
May 21 03:25:06 [IKEv1]IKE Receiver: Runt ISAKMP packet discarded on Port 500 from 172.16.16.16:39994
May 21 03:25:07 [IKEv1]IKE Receiver: Packet received on 172.16.16.1:500 from 172.16.16.16:39994
May 21 03:25:07 [IKEv1]IKE Receiver: Runt ISAKMP packet discarded on Port 500 from 172.16.16.16:39994
May 21 03:25:07 [IKEv1]IKE Receiver: Packet received on 172.16.16.1:500 from 172.16.16.16:39994
May 21 03:25:07 [IKEv1]IKE Receiver: Discarding packet, invalid IKE version

And for the coup, I did a packet capture on the ASA for all UDP/500 traffic and decoded it to see if the protocol decoder could interpret the frames as ISAKMP:

1
2
3
4
5
6
7
8


ASAv-1A/pri/act# cap cap1 int INSIDE match udp any any eq 500
ASAv-1A/pri/act# show cap cap1 decode 6 packets captured
 1: 03:34:01.443916 172.16.16.16.35457 > 172.16.16.1.500: udp 1 [ISAKMP header incomplete]
 2: 03:34:01.444007 172.16.16.16.35457 > 172.16.16.1.500: udp 1 [ISAKMP header incomplete]
 3: 03:34:02.444892 172.16.16.16.35457 > 172.16.16.1.500: udp 1 [ISAKMP header incomplete]
 4: 03:34:03.445609 172.16.16.16.35457 > 172.16.16.1.500: udp 1 [ISAKMP header incomplete]
 5: 03:34:04.447059 172.16.16.16.35457 > 172.16.16.1.500: udp 1 [ISAKMP header incomplete]
 6: 03:34:04.450126 172.16.16.16.35457 > 172.16.16.1.500: udp 75 ISAKMP Header Initiator COOKIE: 78 30 30 78 30 30 78 30 Responder COOKIE: 30 78 30 30 78 30 30 78 Next Payload: IKEV2 LEAP PAYLOAD Version: 3.0 Exchange Type: DOI Specific Use Flags: MessageID: 30783031 Length: 2016424056 [ISAKMP payload corrupted or truncated]

And there you have it, a means to quickly and easily validate a UDP/500 path!

Series Update (2026)

This post has been expanded into a comprehensive series:

Part 1 (this post): Basic connectivity testing with minimal ISAKMP headers
Part 2: Testing with pre-built complete packets
Part 3: Building ISAKMP packets from scratch
Part 4: Automating tests with Scapy (coming soon)

300-208 SISAS - What Is Cisco ISE?

Sat, 12 Dec 2015 21:20:00 -0500

In my earlier post about the Cisco 300-208 SISAS (Implementing Cisco Secure Access Solutions) exam, I gave a brief overview of the exam and listed the exam topics as laid out by the Cisco Learning Community. However, I felt that these largely boil down to a few key concepts related to Cisco ISE (Identity Services Engine):

Understand what ISE is.
Understand why you might use ISE in a wired or wireless network.
Understand what ISE does at a protocol level.
Understand how ISE interacts with Network Access Devices and other systems.
Understand how to configure ISE and the Network Access Devices.

This post will deal with Concept 1, Understand what Cisco ISE is.

A Little History

Before you can understand what ISE is, I feel that you need to know where it came from. Cisco’s NAC (Network Access Control) offerings have been fairly scattershot over the years. They even tried unsuccessfully to market a contrary meaning of NAC for several years, attempting to sell their services as Network Admission Control. Thankfully, they’ve given in and joined the rest of us in Network Access Control land.

Cisco ACS (Access Control Server) was the direct predecessor to ISE and still exists today. It provides RADIUS and TACACS services and can integrate with central Identity Stores such as Active Directory or another LDAP-speaking software. This means that you would often find ACS in an enterprise network serving to authenticate VPN and wireless users or control access to network devices. Over time ACS evolved, as most Cisco applications have, from something you installed on top of Windows, to a full-blown Linux-based appliance (as of ACS 5.0 in 2009). The common “appliance” model in use today, means that without a little (non-Cisco approved) tinkering you don’t have access to the Linux guts of Cisco ACS, or ISE for that matter, you’ve simply presented an application.

At the same time that ACS was growing and advancing in capabilities, there was also the burst of BYOD onto the market and a growing market in servers/services to manage and administer user Identity on the network. Cisco saw an opportunity to forklift the capabilities of ACS into a new product that was targeted directly at the “new” Identity Management market, not just traditional “access control”. They took the underlying operating system from ACS, a RHEL/CentOS-based distribution that they call ADE-OS (Application Deployment Engine), and added a few new capabilities and features to the application. This creation is what we know today as Cisco ISE. Essentially, you can think of ISE as ACS version 6.0.

The only thing left out of ISE (until the recent release of Cisco ISE v2.0) was TACACS, as it was intended that you still purchase ACS to control network device administrative access. For the 300-208 SISAS exam today, you can consider TACACS to be out-of-scope for ISE, and to be the sole purview of ACS, although you still have to understand TACACS for the exam.

What Is Identity Management?

A full discussion of what Identity and Identity Management is, could take up many pages and posts (see Wikipedia), however for the 300-208 SISAS exam it can be summed up as this from the Official Cert Guide:

An identity is a representation of who a user or device is. Cisco ISE uses an endpoint’s MAC address to uniquely identify that endpoint. A username is one method of uniquely identifying an end user. Although SSIDs and IP addresses can be used as conditions or attributes in ISE policies, they are not identities.

Woland, Aaron; Redmon, Kevin (2015-04-27). CCNP Security SISAS 300-208 Official Cert Guide (Certification Guide) (Kindle Locations 13023-13026). Cisco Press. Kindle Edition.

An Identity Management system can then be defined as a way to keep track of Identity information for many users or devices, as well as the associated Authorization and Authentication information for those entities. This is precisely what Cisco ISE is and does. It provides all manner of services related to managing who users and devices are, and what network resources they may access. Cisco ISE does not directly stop an entity from accessing a portion of the network (there are sometimes Inline Policy Nodes, but they are not common). The Network Access Devices themselves handle the heavy lifting of granting/denying access by utilizing IEEE 802.1x which I will discuss in a subsequent post. ISE simply provides a centralized location to set policy, gather reporting, and then interact with the NAD via Radius.

In the next post, I will delve into Concept 2, the Whys surrounding Cisco ISE, as well as give a few example use cases.

The Elusive A+ Rating on SSL Labs

Mon, 24 Aug 2015 22:58:00 -0500

I often have to talk people off a cliff because of their website’s (sometimes perceived) vulnerabilities on Qualys’ SSL Labs testing site. They have received an A- score for their site after running the tests, and see a few things in yellow. Suddenly, they begin to believe that every villain on the web is now running amok with their data. The truth of the matter is that if your SSL configuration is rating at an A-, that configuration is usually just fine. Out of curiosity, I recently spent a few hours tweaking and managed to upgrade from an A- to an A+ for this domain. I wanted to share that process so that anyone else can know what it might take to get an A+.

A+ Rating for network-notes.com on Qualys SSL Labs Testing

Caveats and Advice

The things that get you to an A+, are mostly semantic and not always the most obvious and open vulnerabilities. The SSL Labs scoring process, while open and based on common sense/best practices, is simply one entity’s opinion of your SSL configuration. In addition to the somewhat arbitrary nature of any benchmarking site, such as SSL Labs, remember that a configuration that gets an A+ today is one new vulnerability away from an F. Your security posture on any system must be continuously evolving, along with the threats you’re defending against.

These caveats also hold for any configurations listed here. These are not guarantees that your site will be secure, or even recommendations. They merely reflect the Apache and mod_ssl configurations that suited my needs, in my circumstances, at the time of this writing. Please use common sense when establishing an SSL policy for your website.

The tweaks boiled down to either explicitly defining things in my Apache VirtualHost configuration that I assumed didn’t matter, or bending my strict configuration a little bit to meet the requirements of older browsers. For example, I was initially only going to enable TLSv1.2. If you can’t support TLSv1.2, I wasn’t really worried if the site was unavailable to you. However, as I thought about it, I realized that it was a pointless stance to take. Why isolate this site from an unfortunately large, albeit less secure, portion of the web when I don’t have to? I’m not hosting any sensitive information on these servers; I am not asking users to make credit card transactions or give me their Social Security numbers. I eventually walked my SSL configuration backward and enabled TLSv1.0, TLSv1.1, and TLSv1.2 as part of my remediation efforts to get the elusive A+ from SSL Labs.

How to Get an A- Without Really Trying

Below is an example of the Apache VirtualHost configuration I had in place before beginning this process. It was graded at an A- by SSL Labs and is pretty standard. Most of it was pulled directly from the default-ssl.conf file in Apache 2.4.

Starter Apache Config

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


<IfModule mod_ssl.c>
 <VirtualHost *:443>
 ServerName network-notes.com

 # SSL Configuration
 SSLEngine on
 SSLProtocol +TLSv1.1 +TLSv1.2
 SSLCipherSuite HIGH:!aNULL:!MD5
 SSLCertificateFile network-notes.com.pem
 SSLCertificateKeyFile network-notes.com.key
 SSLCertificateChainFile network-notes.com-cabundle

 # Fixes for IE being, well, IE...
 BrowserMatch "MSIE [2-6]" nokeepalive ssl-unclean-shutdown
 \downgrade-1.0 force-response-1.0
 BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown

 # Browser caching for static content
 <filesMatch ".(js|css|png|jpeg|jpg|gif|ico|swf|flv|pdf|zip)$">
 Header set Cache-Control "max-age=1209600, public"
 </filesMatch>

 # Redirect "/" to "/blog/"
 <If "%{REQUEST_URI} == '/'">
 Redirect "/" "/blog/"
 </If>

 </VirtualHost>
</IfModule>

Now, here’s what the good folks at Qualys SSL Labs had to say about that configuration:

“The server does not support Forward Secrecy with the reference browsers. Grade reduced to A-. MORE INFO»”
1. “Forward Secrecy - With some browsers (more info)”
“Incorrect SNI Alerts - <www.network-notes.com>”
In addition, unless a browser was one of the newest versions available, there was also a slew of “Protocol or cipher suite mismatch”.

Working Towards an A

The easiest fix was enabling TLSv1.o as I described earlier. By simply adding +TLSv1 to the SSLProtocol directive, I opened up a much larger range of possible Protocol/Cipher Suite combinations:

1

 SSLProtocol +TLSv1 +TLSv1.1 +TLSv1.2

Unfortunately, this change resulted in no movement whatsoever of my A- rating. At the very least, issue #3 was resolved; the wide majority of browsers could negotiate a connection. The question remains, however, why would Forward Secrecy only work with some browsers? I have configured all of the DHE and ECDHE ciphers needed and was able to confirm this fact because many browser simulations can connect with an ECDHE cipher. Upon further investigation of the output from SSL Labs, I found the following, “Cipher Suites (sorted by strength as the server has no preference)”. The Forward Secrecy enabled ciphers are available to all browsers, but I wondered if SSL Labs was indicating that some might not pick them because they weren’t offered first.

I always assumed cipher suite order was generally arbitrary, but to appease SSL Labs I sorted them by strength. I added @strength to the end of my SSLCipherSuite directive, and also added the SSLHonorCipherOrder directive. The SSLHonorCipherOrder directive was because, if I’m going to sort my cipher suite, your browser better obey.

1
2


 SSLCipherSuite HIGH:!aNULL:!MD5:@STRENGTH
 SSLHonorCipherOrder on

Upon testing again I had… Success! I was upgraded to an A!

From SSL Labs: “Forward Secrecy - Yes (with most browsers) ROBUST (more info)” There is now only one more issue in yellow, so I assumed that fixing the SNI mixup should get me to an A+.

SNI-ed Remarks

The SNI error given was not exactly verbose: “Incorrect SNI Alerts - <www.network-notes.com>”. This was a little puzzling, as I’m not using SNI for this site; there’s only one domain hosted on the server. After Googling for a few minutes, I found myself at a Qualys Community post from August 2014 detailing this issue. Most helpful it gave a quick and dirty test to validate the issue yourself using OpenSSL (openssl), which I tweaked as shown below to look for unrecognized name SSL alerts. You can see in the first example using network-notes.com, that there was no issue. However, when using <www.network-notes.com>, the server was indeed giving back an unrecognized name error:

1
2
3
4
5
6


$ SERVER=network-notes.com; echo -e "HEAD / HTTP/1.0\r\nHost: $SERVER\r\n\r\n" | openssl s_client -servername $SERVER -connect $SERVER:443 -state 2>&1 | grep unrecognized
$

$ SERVER=www.network-notes.com; echo -e "HEAD / HTTP/1.0\r\nHost: $SERVER\r\n\r\n" | openssl s_client -servername $SERVER -connect $SERVER:443 -state 2>&1 | grep unrecognized
SSL3 alert read:warning:unrecognized name
$

This is a perfect example of the minutia you have to wade through in search of an A+. My DNS for this domain is configured with <www.network-notes.com> as a CNAME for network-notes.com, so no one should ever wind up at <www.network-notes.com>. However, since it is a SAN in my SSL certificate, according to Qualys I need to specify it as a ServerAlias in my Apache VirtualHost configuration:

1

 ServerAlias www.network-notes.com

This change cleared up the SNI error on SSL Labs, and in my testing, however, my grade is still (only?) an A. Now it’s time to think this through and re-read the output from SSL Labs.

Headed for an A+

One of the lines indicated that I did not have the HSTS (HTTP Strict Transport Security) enabled. There’s a great summary of HSTS, including sample configurations at Raymii.org, but essentially it is an HTTP header that is returned to your browser on the first visit. This header tells your browser to always use HTTPS for any subsequent visits to your domain. Since I have all traffic redirecting to HTTPS already, I figured this would be a simple addition. After all, at this point, I was grasping at straws and I added the following configuration:

1

 Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"

And finally, lo and behold, the elusive A+!

Quote from the test: “This server supports HTTP Strict Transport Security with long duration. Grade set to A+.”

Final Results

Now that we have the A+, I figured I should go ahead and complete the other task that I was considering as a possibility, configuring OSCP Stapling. This was a simple enough configuration consisting of two additional lines, one defining where the OSCP Stapling cache would be and another turning the feature on. While this change didn’t upgrade my SSL Labs score any further (A++ anyone?), it did green up another field. After all this time working on the configuration was still fairly satisfying.

Below is an example of what my SSL VirtualHosts file looked like after all of these contortions. I hope you all find it useful, and please let me know if you all have any recommendations, corrections, or your own stories of optimizing SSL.

Final Apache Config

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37


<IfModule mod_ssl.c>
 SSLStaplingCache shmcb:/tmp/stapling_cache(128000)
 <VirtualHost *:443>

 ServerName network-notes.com
 ServerAlias www.network-notes.com

 # SSL Configuration
 SSLEngine on
 SSLProtocol +TLSv1 +TLSv1.1 +TLSv1.2
 SSLCipherSuite HIGH:!aNULL:!MD5:@STRENGTH
 SSLHonorCipherOrder on
 SSLCertificateFile network-notes.com.pem
 SSLCertificateKeyFile network-notes.com.key
 SSLCertificateChainFile network-notes.com-cabundle
 SSLUseStapling on

 # HSTS Configuration
 Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"

 # Fixes for IE being, well, IE...
 BrowserMatch "MSIE [2-6]" nokeepalive ssl-unclean-shutdown
 \downgrade-1.0 force-response-1.0
 BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown

 # Browser caching for static content
 <filesMatch ".(js|css|png|jpeg|jpg|gif|ico|swf|flv|pdf|zip)$">
 Header set Cache-Control "max-age=1209600, public"
 </filesMatch>

 # Redirect "/" to "/blog/"
 <If "%{REQUEST_URI} == '/'">
 Redirect "/" "/blog/"
 </If>

 </VirtualHost>
</IfModule>

300-208 SISAS - How to Tackle the Beast

Wed, 19 Aug 2015 23:09:00 -0500

The best way to finish something is to begin it. So I decided I would begin my prep for the 300-208 SISAS (Implementing Cisco Secure Access Solutions) exam, by laying out my personal study plan against the exam topics, found here on the Cisco Learning Community.

The exam topics are broken into five broad categories, and Cisco also gives a general indication of what percentage of the exam is on each topic:

1.0 Identity Management/Secure Access - 33%
2.0 Threat Defense - 10%
3.0 Troubleshooting, Monitoring, and Reporting Tools - 7%
4.0 Threat Defense Architectures - 17%
5.0 Identity Management Architectures - 33%

Each of those broad topics has several sub-categories; 1.0 Identity Management/Secure Access, for example, is broken down into over 60 sub-sections. This depth of expected knowledge can seem quite daunting at first, especially given the vague nature of some of the topics. However, I’ve found that the exam breaks down into 5 key areas, and are all focused primarily on Cisco ISE (Identity Services Engine):

Understand what ISE is.
Understand why you might use ISE in a wired or wireless network.
Understand what ISE does at a protocol level.
Understand how ISE interacts with Network Access Devices and other systems.
Understand how to configure ISE and the Network Access Devices.

This is why my primary focus in these exam preparations is getting hands-on with Cisco ISE. I have been spending at least 10 minutes per night, getting familiar with both the GUI itself and the operations that ISE can do. 10 minutes may not seem like much, but getting any hands-on time with a complex system matters. You have to keep yourself sharp and fresh when preparing for an exam. Especially if, like in my current job, you do not interact with ISE at all on a day-to-day basis.

In the next few posts, I’ll dig further into each of these 5 key areas, as well as discuss how to set up an ISE test lab for yourself and talk through some of the scenarios I’m using for my lab.

CCNP Security - Halfway There

Sat, 15 Aug 2015 21:52:00 -0500

I am halfway towards my CCNP Security and am finally gearing up to finish it. When I completed the 642-618 FIREWALL and 642-648 VPN exams at the beginning of 2014, I was promptly sidetracked by the little things in life. (Such as moving across the country, starting a new job, and finishing my BSIT at WGU.) Knowing that the old CCNP Security exams had cycled out in April of 2014, I used Cisco’s CCNP Security Migration Path tool to validate that I was left with these two exams:

300-207 SITCS (Implementing Cisco Threat Control Solutions)
300-208 SISAS (Implementing Cisco Secure Access Solutions)

I am starting first with the 300-208 SISAS exam as it covers a range of topics, such as 802.1x, Cisco ISE, and Radius, that I am very familiar with. However, from everything I’ve read, it goes into great depth on the minutia of the ISE interface. As I haven’t touched ISE in a production environment in over a year now, I’ve been spending time most evenings in my lab spinning up and down many different scenarios.

My lab for this study is entirely virtual and is a dry run for building my CCIE Security lab. It currently consists of the following, largely coordinated and controlled via GNS3:

ISE 1.2 - VMWare Fusion on my MacBook
ACS 5.6 - VMWare Fusion on my MacBook
CentOS test boxes (x2) - VMWare Fusion on my MacBook
IOU L2 Image (x2) - Rackspace Cloud Server
IOU L3 Image (x6) - Rackspace Cloud Server
ASA 8.4 (x2) - QEMU on a Rackspace Cloud Server

In the weeks to come I’ll be posting more about my exam preparations, including lab scenarios and links. This is mostly for me, but if anyone else gets some use out of it too, even better.

Mon, 01 Jan 0001 00:00:00 +0000

Hello there 👋

My name is Brett Lykins, and my pronouns are He/Him.

I live in Fairfax, Virginia, USA.

Quick facts about me

One of these is a lie, and you should try to guess which one.

🤓 I am a new nerd who loves knowing how things work and how they’re put together
👨🏻‍💻 🎸 I am passionate about technology and music, but after an unsuccessful year at music school I realized I should probably keep technology as a career and music as a hobby
💼 I spent 15 years working in Networking and Security before I began to use Python and Go to make my life easier
✍🏻 🎙 I write and speak about the intersection of these things to help organizations solve IT infrastructure problems

Current projects

These are projects that I am (somewhat) actively working on.

NAAS: Netmiko as A Service is a REST API wrapper for the popular Netmiko Python library for interacting with network devices. Currently modernizing and preparing for v1.0 release.
cisshgo: A small, fast, concurrent SSH server to emulate network equipment (for example, Cisco IOS) for testing purposes.
Leanpub Multi Action: A Github Action I built for interacting with the API of Leanpub in your authoring workflows.

Past projects

These are projects I was actively working on in the past, but I’ve not touched much in recent months (or years 😅).

Stockpiler: A Nornir-based tool for backing up network device configurations.

Tech stack

Languages: Python, Go, Shell/Bash, Groovy
Infrastructure: Docker, Kubernetes, Terraform, AWS, Linux
Network Automation: Infrahub, Nautobot, NetBox, Ansible, Netmiko, Nornir, NAPALM
Protocols: GNMI, Netconf/RESTconf, SNMP
Tools: Git, GitHub Actions, Flask, Redis

Let’s connect

📝 Blog: network-notes.com
💼 LinkedIn: brettlykins
📧 Email: lykinsbd@gmail.com

Drumroll please

The lie was the first one, if you guessed right here is a cookie: 🍪

I am not a new nerd, but a lifelong nerd.

And here are the receipts.

My first computer:

Teaching my son that This is the Way:

About

Mon, 01 Jan 0001 00:00:00 +0000

This page is sourced from my GitHub profile README. View the original on GitHub for the latest updates.

Hello there 👋

My name is Brett Lykins, and my pronouns are He/Him.

I live in Fairfax, Virginia, USA.

Quick facts about me

One of these is a lie, and you should try to guess which one.

🤓 I am a new nerd who loves knowing how things work and how they’re put together
👨🏻‍💻 🎸 I am passionate about technology and music, but after an unsuccessful year at music school I realized I should probably keep technology as a career and music as a hobby
💼 I spent 15 years working in Networking and Security before I began to use Python and Go to make my life easier
✍🏻 🎙 I write and speak about the intersection of these things to help organizations solve IT infrastructure problems

Current projects

These are projects that I am (somewhat) actively working on.

NAAS: Netmiko as A Service is a REST API wrapper for the popular Netmiko Python library for interacting with network devices. Currently modernizing and preparing for v1.0 release.
cisshgo: A small, fast, concurrent SSH server to emulate network equipment (for example, Cisco IOS) for testing purposes.
Leanpub Multi Action: A Github Action I built for interacting with the API of Leanpub in your authoring workflows.

Past projects

These are projects I was actively working on in the past, but I’ve not touched much in recent months (or years 😅).

Stockpiler: A Nornir-based tool for backing up network device configurations.

Tech stack

Let’s connect

📝 Blog: network-notes.com
💼 LinkedIn: brettlykins
📧 Email: lykinsbd@gmail.com

Drumroll please

The lie was the first one, if you guessed right here is a cookie: 🍪

I am not a new nerd, but a lifelong nerd.

And here are the receipts.

My first computer:

Teaching my son that This is the Way: