Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

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

    OpenVPN
    2
    17
    564
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • V
      viragomann @DominikHoffmann
      last edited by

      @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.

      1 Reply Last reply Reply Quote 0
      • D
        DominikHoffmann
        last edited by

        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:

        Screenshot 2024-01-30 at 1.04.09 PM.png

        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?

        V 1 Reply Last reply Reply Quote 0
        • V
          viragomann @DominikHoffmann
          last edited by

          @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.

          D 1 Reply Last reply Reply Quote 0
          • D
            DominikHoffmann @viragomann
            last edited by

            @viragomann

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

            Screenshot 2024-01-31 at 12.48.17 AM.png

            Do you see anything glaringly wrong in this?

            V 1 Reply Last reply Reply Quote 0
            • V
              viragomann @DominikHoffmann
              last edited by

              @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.

              D 2 Replies Last reply Reply Quote 1
              • D
                DominikHoffmann @viragomann
                last edited by

                @viragomann: Looking through the log file now.

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

                Screenshot 2024-02-02 at 12.39.19 PM.png

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

                V 1 Reply Last reply Reply Quote 0
                • D
                  DominikHoffmann @viragomann
                  last edited by

                  @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?

                  1 Reply Last reply Reply Quote 0
                  • V
                    viragomann @DominikHoffmann
                    last edited by

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

                    Screenshot 2024-02-02 at 12.39.19 PM.png

                    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
                    D 2 Replies Last reply Reply Quote 0
                    • D
                      DominikHoffmann @viragomann
                      last edited by

                      @viragomann: What does “CSO” stand for?

                      V 1 Reply Last reply Reply Quote 0
                      • V
                        viragomann @DominikHoffmann
                        last edited by

                        @DominikHoffmann
                        Client Specific Override

                        1 Reply Last reply Reply Quote 0
                        • D
                          DominikHoffmann @viragomann
                          last edited by

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

                          Screenshot 2024-02-02 at 1.48.38 PM.png

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

                          V 1 Reply Last reply Reply Quote 0
                          • V
                            viragomann @DominikHoffmann
                            last edited by

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

                            D 1 Reply Last reply Reply Quote 1
                            • D
                              DominikHoffmann @viragomann
                              last edited by

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

                              1 Reply Last reply Reply Quote 0
                              • D
                                DominikHoffmann
                                last edited by

                                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:

                                Screenshot 2024-02-14 at 4.45.34 PM.png

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

                                Screenshot 2024-02-14 at 9.19.31 PM.png

                                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:

                                Screenshot 2024-02-14 at 4.45.46 PM.png

                                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:

                                Screenshot 2024-02-14 at 4.46.10 PM.png

                                And the server is configured like this:

                                Screenshot 2024-02-14 at 4.47.10 PM.png

                                … while the client is set up like this:

                                Screenshot 2024-02-14 at 4.46.39 PM.png

                                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).

                                1 Reply Last reply Reply Quote 0
                                • D
                                  DominikHoffmann
                                  last edited by

                                  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.

                                  1 Reply Last reply Reply Quote 0
                                  • D
                                    DominikHoffmann
                                    last edited by DominikHoffmann

                                    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:

                                    Screenshot 2024-02-14 at 11.34.21 PM.png

                                    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à!

                                    1 Reply Last reply Reply Quote 0
                                    • First post
                                      Last post
                                    Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.