Proper network subnet selection in site-to-site setup?

DominikHoffmann · Jan 30, 2024, 6:13 PM

I want to set up a situation very similar to this:

I only have Sites A and B.

The Site B internal IP address of the Netgate 1100 LAN interface is 192.168.34.1. Its virtual address as a client to the server at Site A is 192.168.34.1, as well. Is this allowed? It seems it might be a problem.

The client OpenVPN status (on the Netgate 1100 at Site B) shows:

But the server OpenVPN status (on the Netgate 1100 at Site A) shows:

How can the client show being connected, when the server shows no evidence of that?

Bottom line is that I cannot reach the client from the server with this configuration.

viragomann · Jan 30, 2024, 6:04 PM

@DominikHoffmann said in Proper network subnet selection in site-to-site setup?:

The Site B internal IP address of the Netgate 1100 LAN interface is 192.168.34.1. Its virtual address as a client to the server at Site A is 192.168.34.1, as well. Is this allowed?

Yes, but you cannot route these network to each other of course.
You can nat one instead, so that you have to use an alias network to connect to the other site.

Maybe its easier and more reliable to change one subnet.

But the server OpenVPN status (on the Netgate 1100 at Site A) shows:

Not sure, if this has to do with overlapping networks.
At least you should remove the "local / remote networks" from the OpenVPN settings, as long as its overlapping with the other site.

If the client still doesn't appear check the server log for regarding entries.

DominikHoffmann · Jan 30, 2024, 6:06 PM

I have since changed the IPv4 Tunnel Network in VPN → OpenVPN → Client Specific Overrides to 192.168.44.1/24. On the client the status shows:

However, while an https connection to 192.168.44.1 from the server network should bring up the client’s Netgate 1100 GUI, it times out instead. Why?

viragomann · Jan 30, 2024, 6:28 PM

@DominikHoffmann said in Proper network subnet selection in site-to-site setup?:

I have since changed the IPv4 Tunnel Network in VPN → OpenVPN → Client Specific Overrides to 192.168.44.1/24

This IP is reserved for the server. You must not assign it to the client.
You can start with .2 in a /24 tunnel.

What did you set for the tunnel network?
Ensure that you state a network address there.

DominikHoffmann · Jan 31, 2024, 5:59 AM

@viragomann

Let me show you what I did with this screenshot edited to remove all blank configuration lines to save space:

Do you see anything glaringly wrong in this?

viragomann · Feb 2, 2024, 5:47 PM

@DominikHoffmann
For the local and remote networks, you have to state network addresses!

So local: 192.168.11.0/24
...

If it still doesn't work after changing this, set the servers verbosity level to for, connect and check the log after if the CSO is applied properly.

DominikHoffmann · Feb 2, 2024, 5:47 PM

@viragomann: Looking through the log file now.

Also, I noticed this from the client-specific overrides:

However, I cannot find a corresponding setting in the server configuration. How am I to interpret the underlined statement?

DominikHoffmann · Feb 2, 2024, 5:56 PM

@viragomann: Here is the server-side log:

 12:48:38 … xxx.xxx.xxx.xxx:26534 Re-using SSL/TLS context
 12:48:38 … xxx.xxx.xxx.xxx:26534 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
 12:48:38 … xxx.xxx.xxx.xxx:26534 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
 12:48:38 … xxx.xxx.xxx.xxx:26534 Control Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1250 tun_max_mtu:0 headroom:126 payload:1600 tailroom:126 ET:0 ]
 12:48:38 … xxx.xxx.xxx.xxx:26534 Data Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1500 tun_max_mtu:1600 headroom:136 payload:1768 tailroom:562 ET:0 ]
 12:48:40 … Connection Attempt MULTI: multi_create_instance called
 12:48:40 … xxx.xxx.xxx.xxx:14436 Re-using SSL/TLS context
 12:48:40 … xxx.xxx.xxx.xxx:14436 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
 12:48:40 … xxx.xxx.xxx.xxx:14436 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
 12:48:40 … xxx.xxx.xxx.xxx:14436 Control Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1250 tun_max_mtu:0 headroom:126 payload:1600 tailroom:126 ET:0 ]
 12:48:40 … xxx.xxx.xxx.xxx:14436 Data Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1500 tun_max_mtu:1600 headroom:136 payload:1768 tailroom:562 ET:0 ]
 12:48:40 … xxx.xxx.xxx.xxx:14436 VERIFY WARNING: depth=0, unable to get certificate CRL: C=US, ST=Indiana, L=Fishers, O=Hoffmann Family, CN=millers
 12:48:40 … xxx.xxx.xxx.xxx:14436 VERIFY WARNING: depth=1, unable to get certificate CRL: CN=pfSense-CA, C=US, ST=Indiana, L=Fishers, O=Hoffmann Family
 12:48:40 … xxx.xxx.xxx.xxx:14436 VERIFY SCRIPT OK: depth=1, CN=pfSense-CA, C=US, ST=Indiana, L=Fishers, O=Hoffmann Family
 12:48:40 … xxx.xxx.xxx.xxx:14436 VERIFY OK: depth=1, CN=pfSense-CA, C=US, ST=Indiana, L=Fishers, O=Hoffmann Family
 12:48:40 … xxx.xxx.xxx.xxx:14436 VERIFY SCRIPT OK: depth=0, C=US, ST=Indiana, L=Fishers, O=Hoffmann Family, CN=millers
 12:48:40 … xxx.xxx.xxx.xxx:14436 VERIFY OK: depth=0, C=US, ST=Indiana, L=Fishers, O=Hoffmann Family, CN=millers
 12:48:40 … xxx.xxx.xxx.xxx:14436 peer info: IV_VER=2.6.8
 12:48:40 … xxx.xxx.xxx.xxx:14436 peer info: IV_PLAT=freebsd
 12:48:40 … xxx.xxx.xxx.xxx:14436 peer info: IV_TCPNL=1
 12:48:40 … xxx.xxx.xxx.xxx:14436 peer info: IV_MTU=1600
 12:48:40 … xxx.xxx.xxx.xxx:14436 peer info: IV_NCP=2
 12:48:40 … xxx.xxx.xxx.xxx:14436 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305
 12:48:40 … xxx.xxx.xxx.xxx:14436 peer info: IV_PROTO=990
 12:48:40 … xxx.xxx.xxx.xxx:14436 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
 12:48:40 … xxx.xxx.xxx.xxx:14436 TLS: tls_multi_process: initial untrusted session promoted to trusted
 12:48:41 … xxx.xxx.xxx.xxx:14436 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bits RSA, signature: RSA-SHA256, peer temporary key: 253 bits X25519
 12:48:41 … xxx.xxx.xxx.xxx:14436 [millers] Peer Connection Initiated with [AF_INET]xxx.xxx.xxx.xxx:14436
 12:48:41 … millers/xxx.xxx.xxx.xxx:14436 MULTI_sva: pool returned IPv4=192.168.4.2, IPv6=(Not enabled)
 12:48:41 … millers/xxx.xxx.xxx.xxx:14436 OPTIONS IMPORT: reading client specific options from: /var/etc/openvpn/server2/csc/millers
 12:48:41 … openvpn server 'ovpns2' user cert CN 'millers' address 'xxx.xxx.xxx.xxx:14436' - connecting
 12:48:42 … MANAGEMENT: Client connected from /var/etc/openvpn/server2/sock
 12:48:42 … MANAGEMENT: CMD 'status 2'
 12:48:42 … MANAGEMENT: Client disconnected
 12:48:42 … millers/xxx.xxx.xxx.xxx:14436 PUSH: Received control message: 'PUSH_REQUEST'
 12:48:42 … OPTIONS IMPORT: reading client specific options from: /tmp/openvpn_cc_43906fc003dbeabd6fa20c4930491b39.tmp
 12:48:42 … MULTI: Learn: 192.168.4.5 -> millers/xxx.xxx.xxx.xxx:14436
 12:48:42 … MULTI: primary virtual IP for millers/xxx.xxx.xxx.xxx:14436: 192.168.4.5
 12:48:42 … MULTI: internal route 192.168.36.1/24 -> millers/xxx.xxx.xxx.xxx:14436
 12:48:42 … MULTI: Learn: 192.168.36.1/24 -> millers/xxx.xxx.xxx.xxx:14436
 12:48:42 … MULTI: internal route 192.168.35.1/24 -> millers/xxx.xxx.xxx.xxx:14436
 12:48:42 … MULTI: Learn: 192.168.35.1/24 -> millers/xxx.xxx.xxx.xxx:14436
 12:48:42 … MULTI: internal route 192.168.34.1/24 -> millers/xxx.xxx.xxx.xxx:14436
 12:48:42 … MULTI: Learn: 192.168.34.1/24 -> millers/xxx.xxx.xxx.xxx:14436
 12:48:42 … Data Channel MTU parms [ mss_fix:1399 max_frag:0 tun_mtu:1500 tun_max_mtu:1600 headroom:136 payload:1768 tailroom:562 ET:0 ]
 12:48:42 … Outgoing dynamic tls-crypt: Cipher 'AES-256-CTR' initialized with 256 bit key
 12:48:42 … Outgoing dynamic tls-crypt: Using 256 bit message hash 'SHA256' for HMAC authentication
 12:48:42 … Incoming dynamic tls-crypt: Cipher 'AES-256-CTR' initialized with 256 bit key
 12:48:42 … Incoming dynamic tls-crypt: Using 256 bit message hash 'SHA256' for HMAC authentication
 12:48:42 … Outgoing Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
 12:48:42 … Incoming Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
 12:48:42 … SENT CONTROL [millers]: 'PUSH_REPLY,route 192.168.11.0 255.255.255.0,dhcp-option DOMAIN hoffmann.homeunix.net,dhcp-option DNS 192.168.4.1,route-gateway 192.168.4.1,topology subnet,ping 10,ping-restart 60,route 192.168.11.0 255.255.255.0,ifconfig 192.168.4.5 255.255.255.0,peer-id 1,cipher AES-128-GCM,protocol-flags cc-exit tls-ekm dyn-tls-crypt,tun-mtu 1500' (status=1)
 12:48:42 … openvpn server 'ovpns2' user cert CN 'millers' address 'xxx.xxx.xxx.xxx:14436' - connected
 12:48:42 … millers/xxx.xxx.xxx.xxx:14436 Bad compression stub (swap) decompression header byte: 96
 12:48:42 … millers/xxx.xxx.xxx.xxx:14436 Bad compression stub (swap) decompression header byte: 96
 12:48:42 … millers/xxx.xxx.xxx.xxx:14436 Bad compression stub (swap) decompression header byte: 96
 12:48:44 … millers/xxx.xxx.xxx.xxx:14436 Data Channel: cipher 'AES-128-GCM', peer-id: 0, compression: 'stub'
 12:48:44 … millers/xxx.xxx.xxx.xxx:14436 Timers: ping 10, ping-restart 120
 12:48:44 … millers/xxx.xxx.xxx.xxx:14436 Protocol options: protocol-flags cc-exit tls-ekm dyn-tls-crypt
 12:48:44 … millers/xxx.xxx.xxx.xxx:14436 Bad compression stub (swap) decompression header byte: 96
 12:48:45 … millers/xxx.xxx.xxx.xxx:14436 Bad compression stub (swap) decompression header byte: 96
 12:48:52 … millers/xxx.xxx.xxx.xxx:14436 Bad compression stub (swap) decompression header byte: 42

Is there anything that sticks out at you?

viragomann · Feb 2, 2024, 6:44 PM

@DominikHoffmann said in Proper network subnet selection in site-to-site setup?:

However, I cannot find a corresponding setting in the server configuration. How am I to interpret the underlined statement?

There should be exactly the same box in the server settings.
And yes, the remote subnets have to be entered there as well.

But again, you have to state network addresses, not certain IPs from the subnets.

Is there anything that sticks out at you?

Yes, these lines show that the CSO is applied and that the routes are set within OpenVPN:

 12:48:41 … millers/xxx.xxx.xxx.xxx:14436 OPTIONS IMPORT: reading client specific options from: /var/etc/openvpn/server2/csc/millers
 12:48:41 … openvpn server 'ovpns2' user cert CN 'millers' address 'xxx.xxx.xxx.xxx:14436' - connecting
 12:48:42 … MANAGEMENT: Client connected from /var/etc/openvpn/server2/sock
 12:48:42 … MANAGEMENT: CMD 'status 2'
 12:48:42 … MANAGEMENT: Client disconnected
 12:48:42 … millers/xxx.xxx.xxx.xxx:14436 PUSH: Received control message: 'PUSH_REQUEST'
 12:48:42 … OPTIONS IMPORT: reading client specific options from: /tmp/openvpn_cc_43906fc003dbeabd6fa20c4930491b39.tmp
 12:48:42 … MULTI: Learn: 192.168.4.5 -> millers/xxx.xxx.xxx.xxx:14436
 12:48:42 … MULTI: primary virtual IP for millers/xxx.xxx.xxx.xxx:14436: 192.168.4.5
 12:48:42 … MULTI: internal route 192.168.36.1/24 -> millers/xxx.xxx.xxx.xxx:14436
 12:48:42 … MULTI: Learn: 192.168.36.1/24 -> millers/xxx.xxx.xxx.xxx:14436
 12:48:42 … MULTI: internal route 192.168.35.1/24 -> millers/xxx.xxx.xxx.xxx:14436
 12:48:42 … MULTI: Learn: 192.168.35.1/24 -> millers/xxx.xxx.xxx.xxx:14436
 12:48:42 … MULTI: internal route 192.168.34.1/24 -> millers/xxx.xxx.xxx.xxx:14436
 12:48:42 … MULTI: Learn: 192.168.34.1/24 -> millers/xxx.xxx.xxx.xxx:14436

DominikHoffmann · Feb 2, 2024, 6:46 PM

@viragomann: What does “CSO” stand for?

viragomann · Feb 2, 2024, 6:48 PM

@DominikHoffmann
Client Specific Override

DominikHoffmann · Feb 2, 2024, 6:55 PM

@viragomann: I don’t see an obvious place for those subnets in the server configuration (tunnel section):

Where do they go, or is a different configuration, altogether?

viragomann · Feb 2, 2024, 7:00 PM

@DominikHoffmann
Presumably your server is in remote access mode. You have to switch into peer-to-peer mode.

DominikHoffmann · Feb 2, 2024, 7:05 PM

@viragomann: It wasn’t in peer-to-peer mode. I am now looking into what that will change.

DominikHoffmann · Feb 15, 2024, 2:28 AM

I have only now been able to do some more troubleshooting.

This was the server-side status shortly after the client had made a connection:

Now, however, even though the client still shows it’s connected, server-side status is this:

Somehow the connection died. I will have to dig through the logs and see, whether I discover something.

This is what it shows for OpenVPN status on the client side:

It looks like the desired virtual address 192.168.4.5 is established, but it cannot be pinged from the server.

This is how the tunnel is configured by the client-specific override:

And the server is configured like this:

… while the client is set up like this:

I have been banging my head against the wall. I’ll have to deep-dive into the logs. Unfortunately, the client is a 10-min drive away (which is not all that far, but doesn’t lend itself to trial-and-error troubleshooting).

DominikHoffmann · Feb 15, 2024, 3:37 AM

Posting logs:

Feb 14 21:52:38	openvpn	91450	MANAGEMENT: Client disconnected
Feb 14 21:53:21	openvpn	91450	Connection Attempt MULTI: multi_create_instance called
Feb 14 21:53:21	openvpn	91450	63.208.139.157:20765 Re-using SSL/TLS context
Feb 14 21:53:21	openvpn	91450	63.208.139.157:20765 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Feb 14 21:53:21	openvpn	91450	63.208.139.157:20765 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Feb 14 21:53:21	openvpn	91450	63.208.139.157:20765 Control Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1250 tun_max_mtu:0 headroom:126 payload:1600 tailroom:126 ET:0 ]
Feb 14 21:53:21	openvpn	91450	63.208.139.157:20765 Data Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1500 tun_max_mtu:1600 headroom:136 payload:1768 tailroom:562 ET:0 ]
Feb 14 21:53:21	openvpn	91450	63.208.139.157:20765 VERIFY WARNING: depth=0, unable to get certificate CRL: C=US, ST=****, L=****, O=****, CN=millers
Feb 14 21:53:21	openvpn	91450	63.208.139.157:20765 VERIFY WARNING: depth=1, unable to get certificate CRL: CN=pfSense-CA, C=US, ST=****, L=****, O=****
Feb 14 21:53:21	openvpn	91450	63.208.139.157:20765 VERIFY SCRIPT OK: depth=1, CN=pfSense-CA, C=US, ST=****, L=****, O=****
Feb 14 21:53:21	openvpn	91450	63.208.139.157:20765 VERIFY OK: depth=1, CN=pfSense-CA, C=US, ST=****, L=****, O=****
Feb 14 21:53:21	openvpn	91450	63.208.139.157:20765 VERIFY SCRIPT OK: depth=0, C=US, ST=****, L=****, O=****, CN=millers
Feb 14 21:53:21	openvpn	91450	63.208.139.157:20765 VERIFY OK: depth=0, C=US, ST=****, L=****, O=****, CN=millers
Feb 14 21:53:21	openvpn	91450	63.208.139.157:20765 peer info: IV_VER=2.6.8
Feb 14 21:53:21	openvpn	91450	63.208.139.157:20765 peer info: IV_PLAT=freebsd
Feb 14 21:53:21	openvpn	91450	63.208.139.157:20765 peer info: IV_TCPNL=1
Feb 14 21:53:21	openvpn	91450	63.208.139.157:20765 peer info: IV_MTU=1600
Feb 14 21:53:21	openvpn	91450	63.208.139.157:20765 peer info: IV_NCP=2
Feb 14 21:53:21	openvpn	91450	63.208.139.157:20765 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305
Feb 14 21:53:21	openvpn	91450	63.208.139.157:20765 peer info: IV_PROTO=990
Feb 14 21:53:21	openvpn	91450	63.208.139.157:20765 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
Feb 14 21:53:21	openvpn	91450	63.208.139.157:20765 TLS: tls_multi_process: initial untrusted session promoted to trusted
Feb 14 21:53:21	openvpn	91450	63.208.139.157:20765 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bits RSA, signature: RSA-SHA256, peer temporary key: 253 bits X25519
Feb 14 21:53:21	openvpn	91450	63.208.139.157:20765 [millers] Peer Connection Initiated with [AF_INET]63.208.139.157:20765
Feb 14 21:53:21	openvpn	91450	millers/63.208.139.157:20765 MULTI_sva: pool returned IPv4=192.168.4.2, IPv6=(Not enabled)
Feb 14 21:53:21	openvpn	91450	millers/63.208.139.157:20765 OPTIONS IMPORT: reading client specific options from: /var/etc/openvpn/server2/csc/millers
Feb 14 21:53:21	openvpn	91450	millers/63.208.139.157:20765 MULTI: Learn: 192.168.4.5 -> millers/63.208.139.157:20765
Feb 14 21:53:21	openvpn	91450	millers/63.208.139.157:20765 MULTI: primary virtual IP for millers/63.208.139.157:20765: 192.168.4.5
Feb 14 21:53:21	openvpn	91450	millers/63.208.139.157:20765 MULTI: internal route 192.168.36.1/24 -> millers/63.208.139.157:20765
Feb 14 21:53:21	openvpn	91450	millers/63.208.139.157:20765 MULTI: Learn: 192.168.36.1/24 -> millers/63.208.139.157:20765
Feb 14 21:53:21	openvpn	91450	millers/63.208.139.157:20765 MULTI: internal route 192.168.35.1/24 -> millers/63.208.139.157:20765
Feb 14 21:53:21	openvpn	91450	millers/63.208.139.157:20765 MULTI: Learn: 192.168.35.1/24 -> millers/63.208.139.157:20765
Feb 14 21:53:21	openvpn	91450	millers/63.208.139.157:20765 MULTI: internal route 192.168.34.1/24 -> millers/63.208.139.157:20765
Feb 14 21:53:21	openvpn	91450	millers/63.208.139.157:20765 MULTI: Learn: 192.168.34.1/24 -> millers/63.208.139.157:20765
Feb 14 21:53:21	openvpn	91450	millers/63.208.139.157:20765 Data Channel MTU parms [ mss_fix:1399 max_frag:0 tun_mtu:1500 tun_max_mtu:1600 headroom:136 payload:1768 tailroom:562 ET:0 ]
Feb 14 21:53:21	openvpn	91450	millers/63.208.139.157:20765 Outgoing dynamic tls-crypt: Cipher 'AES-256-CTR' initialized with 256 bit key
Feb 14 21:53:21	openvpn	91450	millers/63.208.139.157:20765 Outgoing dynamic tls-crypt: Using 256 bit message hash 'SHA256' for HMAC authentication
Feb 14 21:53:21	openvpn	91450	millers/63.208.139.157:20765 Incoming dynamic tls-crypt: Cipher 'AES-256-CTR' initialized with 256 bit key
Feb 14 21:53:21	openvpn	91450	millers/63.208.139.157:20765 Incoming dynamic tls-crypt: Using 256 bit message hash 'SHA256' for HMAC authentication
Feb 14 21:53:21	openvpn	91450	millers/63.208.139.157:20765 Outgoing Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
Feb 14 21:53:21	openvpn	91450	millers/63.208.139.157:20765 Incoming Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
Feb 14 21:53:21	openvpn	91450	millers/63.208.139.157:20765 SENT CONTROL [millers]: 'PUSH_REPLY,route 192.168.11.0 255.255.255.0,route-gateway 192.168.4.1,topology subnet,ping 10,ping-restart 60,route 192.168.1.0 255.255.255.0,ifconfig 192.168.4.5 255.255.255.0,peer-id 1,cipher AES-128-GCM,protocol-flags cc-exit tls-ekm dyn-tls-crypt,tun-mtu 1500' (status=1)
Feb 14 21:53:22	openvpn	91450	millers/63.208.139.157:20765 Data Channel: cipher 'AES-128-GCM', peer-id: 0, compression: 'stub'
Feb 14 21:53:22	openvpn	91450	millers/63.208.139.157:20765 Timers: ping 10, ping-restart 120
Feb 14 21:53:22	openvpn	91450	millers/63.208.139.157:20765 Protocol options: protocol-flags cc-exit tls-ekm dyn-tls-crypt
Feb 14 21:53:31	openvpn	91450	millers/63.208.139.157:20765 Bad compression stub (swap) decompression header byte: 42
Feb 14 21:53:41	openvpn	91450	millers/63.208.139.157:20765 Bad compression stub (swap) decompression header byte: 42
Feb 14 21:53:42	openvpn	91450	MANAGEMENT: Client connected from /var/etc/openvpn/server2/sock
Feb 14 21:53:42	openvpn	91450	MANAGEMENT: CMD 'status 2'
Feb 14 21:53:42	openvpn	91450	MANAGEMENT: CMD 'quit'
Feb 14 21:53:42	openvpn	91450	MANAGEMENT: Client disconnected
Feb 14 21:53:51	openvpn	91450	millers/63.208.139.157:20765 Bad compression stub (swap) decompression header byte: 42
Feb 14 21:54:01	openvpn	91450	millers/63.208.139.157:20765 Bad compression stub (swap) decompression header byte: 42
Feb 14 21:54:11	openvpn	91450	millers/63.208.139.157:20765 Bad compression stub (swap) decompression header byte: 42
Feb 14 21:54:20	openvpn	91450	millers/63.208.139.157:16856 [millers] Inactivity timeout (--ping-restart), restarting
Feb 14 21:54:20	openvpn	91450	millers/63.208.139.157:16856 SIGUSR1[soft,ping-restart] received, client-instance restarting
Feb 14 21:54:21	openvpn	91450	millers/63.208.139.157:20765 Bad compression stub (swap) decompression header byte: 42
Feb 14 21:54:31	openvpn	91450	millers/63.208.139.157:20765 Bad compression stub (swap) decompression header byte: 42
Feb 14 21:54:41	openvpn	91450	millers/63.208.139.157:20765 Bad compression stub (swap) decompression header byte: 42
Feb 14 21:54:46	openvpn	91450	MANAGEMENT: Client connected from /var/etc/openvpn/server2/sock
Feb 14 21:54:46	openvpn	91450	MANAGEMENT: CMD 'status 2'
Feb 14 21:54:46	openvpn	91450	MANAGEMENT: CMD 'quit'
Feb 14 21:54:46	openvpn	91450	MANAGEMENT: Client disconnected
Feb 14 21:54:46	openvpn	49882	TCP connection established with [AF_INET]162.216.149.31:58324
Feb 14 21:54:46	openvpn	49882	162.216.149.31:58324 WARNING: Bad encapsulated packet length from peer (0), which must be > 0 and <= 1800 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]
Feb 14 21:54:46	openvpn	49882	162.216.149.31:58324 Connection reset, restarting [0]
Feb 14 21:54:46	openvpn	49882	TCP connection established with [AF_INET]162.216.149.31:58336
Feb 14 21:54:46	openvpn	49882	162.216.149.31:58336 WARNING: Bad encapsulated packet length from peer (0), which must be > 0 and <= 1800 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]
Feb 14 21:54:46	openvpn	49882	162.216.149.31:58336 Connection reset, restarting [0]
Feb 14 21:54:46	openvpn	49882	TCP connection established with [AF_INET]162.216.149.31:58342
Feb 14 21:54:46	openvpn	49882	162.216.149.31:58342 WARNING: Bad encapsulated packet length from peer (0), which must be > 0 and <= 1800 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]
Feb 14 21:54:46	openvpn	49882	162.216.149.31:58342 Connection reset, restarting [0]
Feb 14 21:54:47	openvpn	49882	TCP connection established with [AF_INET]162.216.149.31:58350
Feb 14 21:54:47	openvpn	49882	162.216.149.31:58350 WARNING: Bad encapsulated packet length from peer (0), which must be > 0 and <= 1800 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]
Feb 14 21:54:47	openvpn	49882	162.216.149.31:58350 Connection reset, restarting [0]
Feb 14 21:54:47	openvpn	49882	TCP connection established with [AF_INET]162.216.149.31:58366
Feb 14 21:54:47	openvpn	49882	162.216.149.31:58366 WARNING: Bad encapsulated packet length from peer (0), which must be > 0 and <= 1800 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]
Feb 14 21:54:47	openvpn	49882	162.216.149.31:58366 Connection reset, restarting [0]
Feb 14 21:54:47	openvpn	49882	TCP connection established with [AF_INET]162.216.149.31:58382
Feb 14 21:54:47	openvpn	49882	162.216.149.31:58382 WARNING: Bad encapsulated packet length from peer (0), which must be > 0 and <= 1800 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]
Feb 14 21:54:47	openvpn	49882	162.216.149.31:58382 Connection reset, restarting [0]
Feb 14 21:54:47	openvpn	49882	TCP connection established with [AF_INET]162.216.149.31:58386
Feb 14 21:54:47	openvpn	49882	162.216.149.31:58386 Connection reset, restarting [0]
Feb 14 21:54:51	openvpn	91450	millers/63.208.139.157:20765 Bad compression stub (swap) decompression header byte: 42
Feb 14 21:55:01	openvpn	91450	millers/63.208.139.157:20765 Bad compression stub (swap) decompression header byte: 42
Feb 14 21:55:11	openvpn	91450	millers/63.208.139.157:20765 Bad compression stub (swap) decompression header byte: 42
Feb 14 21:55:21	openvpn	91450	millers/63.208.139.157:20765 [millers] Inactivity timeout (--ping-restart), restarting
Feb 14 21:55:21	openvpn	91450	millers/63.208.139.157:20765 SIGUSR1[soft,ping-restart] received, client-instance restarting
Feb 14 21:55:50	openvpn	91450	MANAGEMENT: Client connected from /var/etc/openvpn/server2/sock
Feb 14 21:55:50	openvpn	91450	MANAGEMENT: CMD 'status 2'
Feb 14 21:55:50	openvpn	91450	MANAGEMENT: CMD 'quit'
Feb 14 21:55:50	openvpn	91450	MANAGEMENT: Client disconnected

I am doing research on the line

Bad compression stub (swap) decompression header byte: 42

now.

DominikHoffmann · Feb 15, 2024, 5:02 AM

That was the key clue. A Google search for that line led to another discussion in this forum. The last post in that discussion hinted at adjustment of the compression configuration. When I switched my server’s like this:

i.e., set the compression to “Refuse any non-stub compression,” I could see my client’s pfSense appliance at 192.168.4.5.

Voilà!