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

    P2P VPN server can't reach client, but client can reach server

    Scheduled Pinned Locked Moved
    OpenVPN
    4
    53
    4.6k
    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.
    • lifeboyL
      lifeboy
      last edited by lifeboy

      I have 2 pfSense firewalls connected with an OpenVPN link. I can ping the server from the pfSense client, but not vice versa.

      Server local network: 192.168.131.0/24
      Client local network: 192.168.111.0/24
      The connecting subnet is: 192.168.110.0/29 10.0.111.0/24 (changed to something completely different)

      On the Server I have these routes: Routing tables (netstat -rn) - removed the other routes that are not relevant for the same of brevity.

      Internet:
Destination        Gateway            Flags     Netif Expire
default            197.214.119.129    UGS    vtnet1.6
192.168.110.0/29   link#19            U        ovpns5
192.168.110.1      link#11            UHS         lo0
192.168.111.0/24   192.168.110.2      UGS      ovpns5
192.168.121.0/24   10.0.1.2           UGS      ovpns1
192.168.131.0/24   link#1             U        vtnet0
192.168.131.252    link#11            UHS         lo0
192.168.131.254    link#11            UHS         lo0

      I can't ping any devices on the client LAN, not even the LAN port on the pfSense firewall.

      On the client I have these routes:

      Internet:
Destination        Gateway            Flags     Netif Expire
default            156.38.137.241     UGS      vtnet1
127.0.0.1          link#4             UH          lo0
156.38.137.240/29  link#2             U        vtnet1
156.38.137.242     link#4             UHS         lo0
192.168.110.0/29   link#7             U        ovpnc1
192.168.110.2      link#4             UHS         lo0
192.168.111.0/24   link#1             U        vtnet0
192.168.111.254    link#4             UHS         lo0
192.168.131.0/24   192.168.110.1      UGS      ovpnc1
192.168.161.0/24   192.168.110.1      UGS      ovpnc1

      From the client pfSense however I can ping the server pfSense LAN addresses and the devices on the LAN.

      Firewall rules allow outgoing traffic to any destination on the server and the client.

      Clearly I'm missing something, but what?

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

        @lifeboy
        Remember that you have to create a Client Specific Override on the server.

        lifeboyL 1 Reply Last reply Reply Quote 0
        • lifeboyL
          lifeboy @viragomann
          last edited by

          @viragomann There's only one client connected to this specific server, so there's not need for an override.

          I have a couple of other connections just like this and they work fine. This new one doesn't.

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

            @lifeboy said in P2P VPN server can't reach client, but client can reach server:

            There's only one client connected to this specific server, so there's not need for an override.

            If your tunnel network is as wide that there are multiple client connections possible (>/30) you need it though.

            Consider that a /30 is not compatible with DCO.

            lifeboyL 1 Reply Last reply Reply Quote 0
            • lifeboyL
              lifeboy @viragomann
              last edited by

              @viragomann This is the community version, not PRO and it only needs one connection between the two servers. This is why I started with a /24 which I subsequently changed to /29.

              However, is this relevant to the problem that I'm having?

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

                @lifeboy
                In the CSO you state the client sides networks. Without that, OpenVPN cannot route to theses networks.
                Note that the client sides have also be stated in the server settings at "Remote Networks".

                lifeboyL 1 Reply Last reply Reply Quote 0
                • lifeboyL
                  lifeboy @viragomann
                  last edited by lifeboy

                  @viragomann That is not what the documentation says...

                  There's no mention of CSO in this:
                  [https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-s2s-psk.html] https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-s2s-tls.html#openvpn-site-to-site-configuration-example-with-ssl-tls (URL corrected)

                  CSO is for when different clients connecting to the a server have different requirements. Client Specific Overrides

                  lifeboyL V 2 Replies Last reply Reply Quote 0
                  • lifeboyL
                    lifeboy @lifeboy
                    last edited by

                    @lifeboy As additional information, here are the automatic address ranges that have been added to the outbound NAT config.

                    Interface: WAN
                    Sources:
                    127.0.0.0/8
                    ::1/128
                    10.210.10.0/24
                    10.210.20.0/24
                    10.210.30.0/24
                    10.210.40.0/24
                    192.168.131.0/24
                    197.214.118.224/28
                    192.168.161.0/24
                    192.168.151.0/24
                    192.168.142.0/24
                    168.253.202.96/27
                    192.168.150.0/24
                    192.168.111.2/32
                    192.168.132.0/24
                    10.0.1.0/24
                    192.168.133.0/24
                    10.0.111.0/24

                    Not sure why the highligted ip is in this list. It's part of the client (remote) range, not the ones on the server LAN.

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

                      @lifeboy said in P2P VPN server can't reach client, but client can reach server:

                      There's no mention of CSO in this:
                      [https://docs.netgate.com/pfsense/en/latest/recipes/openvpn-s2s-psk.html]

                      When you open this link, did you notice that big red box.

                      We're generally talking about TLS OpenVPN, since shared key is deprecated and should not be used anymore these days.

                      lifeboyL 1 Reply Last reply Reply Quote 0
                      • lifeboyL
                        lifeboy @viragomann
                        last edited by

                        @viragomann Apologies, my bad. I used this for a TLS authenticated tunnel.

                        However, I added the (superfluous imho) CSO now, but it makes no difference at all.

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

                          @lifeboy
                          But as I mentioned above, it's essential for bigger tunnel networks than a /30.

                          The routing table just shows up the networks, which you have entered in the server settings. But it doesn't prove that the CSO is applied properly.
                          You can only find this out by analyzing the OpenVPN log. Maybe enhance the verbosity level to say 4.

                          Edit:
                          Want to add, for an easy s2s setup, you can use a /30 tunnel for sure if DCO is not relevant for this server.

                          lifeboyL 1 Reply Last reply Reply Quote 0
                          • lifeboyL
                            lifeboy @viragomann
                            last edited by lifeboy

                            @viragomann

                            Jan 23 19:21:21	openvpn	33612	JHB_backup/156.38.137.242:1194 MULTI: bad source address from client [::], packet dropped
Jan 23 19:21:21	openvpn	33612	JHB_backup/156.38.137.242:1194 Protocol options: explicit-exit-notify 1, protocol-flags cc-exit tls-ekm dyn-tls-crypt
Jan 23 19:21:21	openvpn	33612	JHB_backup/156.38.137.242:1194 Timers: ping 10, ping-restart 120
Jan 23 19:21:21	openvpn	33612	JHB_backup/156.38.137.242:1194 Data Channel: cipher 'AES-256-GCM', peer-id: 0
Jan 23 19:21:21	openvpn	33612	JHB_backup/156.38.137.242:1194 MULTI: bad source address from client [::], packet dropped
Jan 23 19:21:20	openvpn	33612	JHB_backup/156.38.137.242:1194 SENT CONTROL [JHB_backup]: 'PUSH_REPLY,route 192.168.131.0 255.255.255.0,route 192.168.161.0 255.255.255.0,route 192.168.111.0 255.255.255.0,route-gateway 10.0.111.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.0.111.2 255.255.255.0,peer-id 0,cipher AES-256-GCM,protocol-flags cc-exit tls-ekm dyn-tls-crypt,tun-mtu 1500' (status=1)
Jan 23 19:21:20	openvpn	33612	JHB_backup/156.38.137.242:1194 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Jan 23 19:21:20	openvpn	33612	JHB_backup/156.38.137.242:1194 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Jan 23 19:21:20	openvpn	33612	JHB_backup/156.38.137.242:1194 Incoming dynamic tls-crypt: Using 256 bit message hash 'SHA256' for HMAC authentication
Jan 23 19:21:20	openvpn	33612	JHB_backup/156.38.137.242:1194 Incoming dynamic tls-crypt: Cipher 'AES-256-CTR' initialized with 256 bit key
Jan 23 19:21:20	openvpn	33612	JHB_backup/156.38.137.242:1194 Outgoing dynamic tls-crypt: Using 256 bit message hash 'SHA256' for HMAC authentication
Jan 23 19:21:20	openvpn	33612	JHB_backup/156.38.137.242:1194 Outgoing dynamic tls-crypt: Cipher 'AES-256-CTR' initialized with 256 bit key
Jan 23 19:21:20	openvpn	33612	JHB_backup/156.38.137.242:1194 Data Channel MTU parms [ mss_fix:1400 max_frag:0 tun_mtu:1500 tun_max_mtu:1600 headroom:136 payload:1768 tailroom:562 ET:0 ]
Jan 23 19:21:20	openvpn	33612	JHB_backup/156.38.137.242:1194 MULTI: primary virtual IP for JHB_backup/156.38.137.242:1194: 10.0.111.2
Jan 23 19:21:20	openvpn	33612	JHB_backup/156.38.137.242:1194 MULTI: Learn: 10.0.111.2 -> JHB_backup/156.38.137.242:1194
Jan 23 19:21:20	openvpn	33612	JHB_backup/156.38.137.242:1194 MULTI_sva: pool returned IPv4=10.0.111.2, IPv6=(Not enabled)
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 [JHB_backup] Peer Connection Initiated with [AF_INET]156.38.137.242:1194
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 TLS: tls_multi_process: initial untrusted session promoted to trusted
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 peer info: IV_COMP_STUBv2=1
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 peer info: IV_COMP_STUB=1
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 peer info: IV_LZO_STUB=1
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 peer info: IV_PROTO=990
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:AES-256-CBC
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 peer info: IV_NCP=2
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 peer info: IV_MTU=1600
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 peer info: IV_TCPNL=1
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 peer info: IV_PLAT=freebsd
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 peer info: IV_VER=2.6.8
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 VERIFY OK: depth=0, CN=JHB_backup, C=ZA, L=Cape Town, O=GTS Fastnet Connect
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 VERIFY SCRIPT OK: depth=0, CN=JHB_backup, C=ZA, L=Cape Town, O=GTS Fastnet Connect
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 VERIFY EKU OK
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 ++ Certificate has EKU (str) TLS Web Client Authentication, expects TLS Web Client Authentication
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 Validating certificate extended key usage
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 VERIFY KU OK
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 VERIFY OK: depth=1, CN=fastnet-internal-ca, C=ZA, L=Cape Town, O=GTS Fastnet Connect
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 VERIFY SCRIPT OK: depth=1, CN=fastnet-internal-ca, C=ZA, L=Cape Town, O=GTS Fastnet Connect
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 VERIFY WARNING: depth=1, unable to get certificate CRL: CN=fastnet-internal-ca, C=ZA, L=Cape Town, O=GTS Fastnet Connect
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 VERIFY WARNING: depth=0, unable to get certificate CRL: CN=JHB_backup, C=ZA, L=Cape Town, O=GTS Fastnet Connect
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 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 ]
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 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 ]
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 Re-using SSL/TLS context
Jan 23 19:21:20	openvpn	33612	Connection Attempt MULTI: multi_create_instance called
                            lifeboyL V 2 Replies Last reply Reply Quote 0
                            • lifeboyL
                              lifeboy @lifeboy
                              last edited by

                              @lifeboy The error "MULTI: bad source address from client [::], packet dropped" is probably because I disabled IPV6...

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

                                @lifeboy
                                Nothing to see regarding applying the CSO.
                                However, the log obviously doesn't show the very first clients touch.

                                Note that there are no regarding log entries at default verbosity level.

                                Ensure that the common name in the CSO is matching that one in the user certificate or even the username, depending on the "Username as Common Name" option in the server settings.

                                The error "MULTI: bad source address from client [::], packet dropped" is probably because I disabled IPV6...

                                If you don't want it, don't let it pass to the server and set the server to listen on IPv4 only.

                                lifeboyL 1 Reply Last reply Reply Quote 0
                                • lifeboyL
                                  lifeboy @viragomann
                                  last edited by

                                  @viragomann I had increased the log verbosity to 4, but here is a more complete log of the setting up of the tunnel.

                                  Jan 23 19:21:21	openvpn	33612	JHB_backup/156.38.137.242:1194 MULTI: bad source address from client [::], packet dropped
Jan 23 19:21:21	openvpn	33612	JHB_backup/156.38.137.242:1194 Protocol options: explicit-exit-notify 1, protocol-flags cc-exit tls-ekm dyn-tls-crypt
Jan 23 19:21:21	openvpn	33612	JHB_backup/156.38.137.242:1194 Timers: ping 10, ping-restart 120
Jan 23 19:21:21	openvpn	33612	JHB_backup/156.38.137.242:1194 Data Channel: cipher 'AES-256-GCM', peer-id: 0
Jan 23 19:21:21	openvpn	33612	JHB_backup/156.38.137.242:1194 MULTI: bad source address from client [::], packet dropped
Jan 23 19:21:20	openvpn	33612	JHB_backup/156.38.137.242:1194 SENT CONTROL [JHB_backup]: 'PUSH_REPLY,route 192.168.131.0 255.255.255.0,route 192.168.161.0 255.255.255.0,route 192.168.111.0 255.255.255.0,route-gateway 10.0.111.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.0.111.2 255.255.255.0,peer-id 0,cipher AES-256-GCM,protocol-flags cc-exit tls-ekm dyn-tls-crypt,tun-mtu 1500' (status=1)
Jan 23 19:21:20	openvpn	33612	JHB_backup/156.38.137.242:1194 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Jan 23 19:21:20	openvpn	33612	JHB_backup/156.38.137.242:1194 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Jan 23 19:21:20	openvpn	33612	JHB_backup/156.38.137.242:1194 Incoming dynamic tls-crypt: Using 256 bit message hash 'SHA256' for HMAC authentication
Jan 23 19:21:20	openvpn	33612	JHB_backup/156.38.137.242:1194 Incoming dynamic tls-crypt: Cipher 'AES-256-CTR' initialized with 256 bit key
Jan 23 19:21:20	openvpn	33612	JHB_backup/156.38.137.242:1194 Outgoing dynamic tls-crypt: Using 256 bit message hash 'SHA256' for HMAC authentication
Jan 23 19:21:20	openvpn	33612	JHB_backup/156.38.137.242:1194 Outgoing dynamic tls-crypt: Cipher 'AES-256-CTR' initialized with 256 bit key
Jan 23 19:21:20	openvpn	33612	JHB_backup/156.38.137.242:1194 Data Channel MTU parms [ mss_fix:1400 max_frag:0 tun_mtu:1500 tun_max_mtu:1600 headroom:136 payload:1768 tailroom:562 ET:0 ]
Jan 23 19:21:20	openvpn	33612	JHB_backup/156.38.137.242:1194 MULTI: primary virtual IP for JHB_backup/156.38.137.242:1194: 10.0.111.2
Jan 23 19:21:20	openvpn	33612	JHB_backup/156.38.137.242:1194 MULTI: Learn: 10.0.111.2 -> JHB_backup/156.38.137.242:1194
Jan 23 19:21:20	openvpn	33612	JHB_backup/156.38.137.242:1194 MULTI_sva: pool returned IPv4=10.0.111.2, IPv6=(Not enabled)
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 [JHB_backup] Peer Connection Initiated with [AF_INET]156.38.137.242:1194
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 TLS: tls_multi_process: initial untrusted session promoted to trusted
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 peer info: IV_COMP_STUBv2=1
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 peer info: IV_COMP_STUB=1
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 peer info: IV_LZO_STUB=1
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 peer info: IV_PROTO=990
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:AES-256-CBC
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 peer info: IV_NCP=2
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 peer info: IV_MTU=1600
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 peer info: IV_TCPNL=1
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 peer info: IV_PLAT=freebsd
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 peer info: IV_VER=2.6.8
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 VERIFY OK: depth=0, CN=JHB_backup, C=ZA, L=Cape Town, O=GTS Fastnet Connect
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 VERIFY SCRIPT OK: depth=0, CN=JHB_backup, C=ZA, L=Cape Town, O=GTS Fastnet Connect
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 VERIFY EKU OK
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 ++ Certificate has EKU (str) TLS Web Client Authentication, expects TLS Web Client Authentication
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 Validating certificate extended key usage
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 VERIFY KU OK
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 VERIFY OK: depth=1, CN=fastnet-internal-ca, C=ZA, L=Cape Town, O=GTS Fastnet Connect
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 VERIFY SCRIPT OK: depth=1, CN=fastnet-internal-ca, C=ZA, L=Cape Town, O=GTS Fastnet Connect
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 VERIFY WARNING: depth=1, unable to get certificate CRL: CN=fastnet-internal-ca, C=ZA, L=Cape Town, O=GTS Fastnet Connect
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 VERIFY WARNING: depth=0, unable to get certificate CRL: CN=JHB_backup, C=ZA, L=Cape Town, O=GTS Fastnet Connect
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 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 ]
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 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 ]
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Jan 23 19:21:20	openvpn	33612	156.38.137.242:1194 Re-using SSL/TLS context
Jan 23 19:21:20	openvpn	33612	Connection Attempt MULTI: multi_create_instance called

                                  The CSO is the same "JHB_backup".

                                  V lifeboyL 2 Replies Last reply Reply Quote 0
                                  • V
                                    viragomann @lifeboy
                                    last edited by viragomann

                                    @lifeboy
                                    We are searching for a line like this
                                    22283bb1-86a6-4a42-bce4-57be2e6b273c-grafik.png

                                    Obviously there is no match as mentioned above.

                                    If a CSO is applied and there are Remote Networks stated, then you also see lines about adding the routes.

                                    1 Reply Last reply Reply Quote 0
                                    • lifeboyL
                                      lifeboy @lifeboy
                                      last edited by

                                      @lifeboy At the client however, I see this is the log.

                                      Jan 23 19:31:12 	openvpn 	9101 	Initialization Sequence Completed
Jan 23 19:31:12 	openvpn 	9101 	ERROR: FreeBSD route add command failed: external program exited with error status: 1
Jan 23 19:31:12 	openvpn 	9101 	/sbin/route add -net 192.168.111.0 10.0.111.1 255.255.255.0
Jan 23 19:31:12 	openvpn 	9101 	/sbin/route add -net 192.168.161.0 10.0.111.1 255.255.255.0
Jan 23 19:31:12 	openvpn 	9101 	ERROR: FreeBSD route add command failed: external program exited with error status: 1
Jan 23 19:31:12 	openvpn 	9101 	/sbin/route add -net 192.168.131.0 10.0.111.1 255.255.255.0
Jan 23 19:31:12 	openvpn 	9101 	/sbin/route add -net 192.168.131.0 10.0.111.1 255.255.255.0

                                      The route add fails.

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

                                        @lifeboy
                                        That's bad though.

                                        Did you check "Don't add routes" in the client settings?

                                        Are these routes even added successfully?
                                        This could possibly happen if you have added the remote networks in the client settings, and also the server is pushing them. In this case you can remote the subnets from the "Local networks" box at the server.

                                        lifeboyL 1 Reply Last reply Reply Quote 0
                                        • lifeboyL
                                          lifeboy @viragomann
                                          last edited by

                                          @viragomann No, I don't have networks specced in the client. I did have before, but since removed them to make sure there's no clash.

                                          I do see this though:

                                          [2.7.0-RELEASE][roland@fw-1A.fast.za.net]/home/roland: ping 10.0.111.2
PING 10.0.111.2 (10.0.111.2): 56 data bytes
^C
--- 10.0.111.2 ping statistics ---
7 packets transmitted, 0 packets received, 100.0% packet loss
[2.7.0-RELEASE][roland@fw-1A.fast.za.net]/home/roland: ping 10.0.111.1
PING 10.0.111.1 (10.0.111.1): 56 data bytes
64 bytes from 10.0.111.1: icmp_seq=0 ttl=64 time=0.871 ms
64 bytes from 10.0.111.1: icmp_seq=1 ttl=64 time=0.088 ms
64 bytes from 10.0.111.1: icmp_seq=2 ttl=64 time=0.076 ms
^C
--- 10.0.111.1 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.076/0.345/0.871/0.372 ms
[2.7.0-RELEASE][roland@fw-1A.fast.za.net]/home/roland:

                                          Which doesn't make sense. It's almost as if the connection is not up, but it is.

                                          743ad152-d750-4cb0-b219-1e129e059d37-image.png

                                          lifeboyL V 2 Replies Last reply Reply Quote 0
                                          • lifeboyL
                                            lifeboy @lifeboy
                                            last edited by

                                            I have removed the network specs in the CSO now the route add error is gone. Still can't reach the client from the server though or even ping 10.0.111.2.

                                            Jan 23 20:33:44 	openvpn 	79155 	Protocol options: explicit-exit-notify 3, protocol-flags cc-exit tls-ekm dyn-tls-crypt
Jan 23 20:33:44 	openvpn 	79155 	Timers: ping 10, ping-restart 60
Jan 23 20:33:44 	openvpn 	79155 	Data Channel: cipher 'AES-256-GCM', peer-id: 0
Jan 23 20:33:44 	openvpn 	79155 	Initialization Sequence Completed
Jan 23 20:33:44 	openvpn 	79155 	Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Jan 23 20:33:44 	openvpn 	79155 	Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Jan 23 20:33:44 	openvpn 	79155 	Incoming dynamic tls-crypt: Using 256 bit message hash 'SHA256' for HMAC authentication
Jan 23 20:33:44 	openvpn 	79155 	Incoming dynamic tls-crypt: Cipher 'AES-256-CTR' initialized with 256 bit key
Jan 23 20:33:44 	openvpn 	79155 	Outgoing dynamic tls-crypt: Using 256 bit message hash 'SHA256' for HMAC authentication
Jan 23 20:33:44 	openvpn 	79155 	Outgoing dynamic tls-crypt: Cipher 'AES-256-CTR' initialized with 256 bit key
Jan 23 20:33:44 	openvpn 	79155 	Data Channel MTU parms [ mss_fix:1400 max_frag:0 tun_mtu:1500 tun_max_mtu:1600 headroom:136 payload:1768 tailroom:562 ET:0 ]
Jan 23 20:33:44 	openvpn 	79155 	/sbin/route add -net 192.168.161.0 10.0.111.1 255.255.255.0
Jan 23 20:33:44 	openvpn 	79155 	/sbin/route add -net 192.168.131.0 10.0.111.1 255.255.255.0
Jan 23 20:33:44 	openvpn 	79155 	/usr/local/sbin/ovpn-linkup ovpnc1 1500 0 10.0.111.2 255.255.255.0 init
Jan 23 20:33:44 	openvpn 	79155 	/sbin/ifconfig ovpnc1 10.0.111.2/24 mtu 1500 up
Jan 23 20:33:44 	openvpn 	79155 	do_ifconfig, ipv4=1, ipv6=0
Jan 23 20:33:44 	openvpn 	79155 	TUN/TAP device /dev/tun1 opened
Jan 23 20:33:44 	openvpn 	79155 	TUN/TAP device ovpnc1 exists previously, keep at program end
Jan 23 20:33:44 	openvpn 	79155 	ROUTE_GATEWAY 156.38.137.241/255.255.255.248 IFACE=vtnet1 HWADDR=bc:24:11:cb:4f:1e
Jan 23 20:33:44 	openvpn 	79155 	OPTIONS IMPORT: tun-mtu set to 1500
Jan 23 20:33:44 	openvpn 	79155 	OPTIONS IMPORT: route-related options modified
Jan 23 20:33:44 	openvpn 	79155 	OPTIONS IMPORT: route options modified
Jan 23 20:33:44 	openvpn 	79155 	OPTIONS IMPORT: --ifconfig/up options modified
Jan 23 20:33:44 	openvpn 	79155 	PUSH: Received control message: 'PUSH_REPLY,route 192.168.131.0 255.255.255.0,route 192.168.161.0 255.255.255.0,route-gateway 10.0.111.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.0.111.2 255.255.255.0,peer-id 0,cipher AES-256-GCM,protocol-flags cc-exit tls-ekm dyn-tls-crypt,tun-mtu 1500'
                                            lifeboyL 1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post