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

    Site2Site between two pfSenses - no response from Server

    Scheduled Pinned Locked Moved OpenVPN
    11 Posts 4 Posters 2.3k Views
    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.
    • M
      marvosa
      last edited by

      We can't even begin to troubleshoot without more info.

      Post your server1.conf and client1.conf.

      1 Reply Last reply Reply Quote 0
      • C
        crach
        last edited by

        Hi marvosa,

        Thanks for your reply, but I can't post the complete config files, because pfsense is storring a lot of passwords in cleartext … and the server-side is in production use.
        If you can say me, which sections are of intrest, I can post these.

        On the server I've allready two clients and one server (for clients).

        Some more infos about the server:

        • Interface: One of our WAN-Ports (this one assigned to this IP)
        • Local Port: 11941 (not used by anything else

        Client:

        • Interface: WAN
        • Server host: serverhostname
        • Server port: 11941

        Both:

        • Server Mode: P2P with Shared Key
        • Protocol: UDP
        • Device Mode: tun
        • Tunnel Network: 172.18.1.0/24

        Many thanks

        1 Reply Last reply Reply Quote 0
        • chpalmerC
          chpalmer
          last edited by

          Did you create a firewall rule on the WAN of the server allowing the incoming traffic to the WAN on port 1194?

          Triggering snowflakes one by one..
          Intel(R) Core(TM) i5-4590T CPU @ 2.00GHz on an M400 WG box.

          1 Reply Last reply Reply Quote 0
          • C
            crach
            last edited by

            @chpalmer:

            Did you create a firewall rule on the WAN of the server allowing the incoming traffic to the WAN on port 1194?

            Yes, I did. Not to port 1194 but to 11941, because I've an other instance on this port. I've activated logging on this port and can see the incomming packets from the client.

            1 Reply Last reply Reply Quote 0
            • chpalmerC
              chpalmer
              last edited by

              Yea- missed that  11941.

              Your tunnel IP different than your LAN IP's at either end?

              Triggering snowflakes one by one..
              Intel(R) Core(TM) i5-4590T CPU @ 2.00GHz on an M400 WG box.

              1 Reply Last reply Reply Quote 0
              • DerelictD
                Derelict LAYER 8 Netgate
                last edited by

                What's in the OpenVPN log on the client?

                Chattanooga, Tennessee, USA
                A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                Do Not Chat For Help! NO_WAN_EGRESS(TM)

                1 Reply Last reply Reply Quote 0
                • M
                  marvosa
                  last edited by

                  craCH, I've never seen clear text passwords configured, defined or posted in an openvpn config.  The two configs are responsible for establishing an encrypted tunnel, I find it hard to believe you have clear text passwords defined in your configs… and if so, for what?

                  If there's something you don't want advertised (e.g. public IP's), just mask it.  Other than public IP's, your configs will have the same directives posted in the same order as everyone else, which is helpful in identifying the issue.

                  You've said the client's connections are being logged, are they coming in on the correct port and on the right protocol?  What are you seeing on the OpenVPN tab in the Firewall section?  Have you double checked the cipher?  Have you tried changing the port?

                  1 Reply Last reply Reply Quote 0
                  • C
                    crach
                    last edited by

                    Hi all,

                    Yes, the Client-IPs on each side are different (10.99.1/24 on the client side and 10.10.0.0/16 on the server-side)

                    In the OpenVPN-Log on the Client side (repeating every minute):

                    Dec 27 20:19:21 	openvpn[28073]: UDPv4 link remote: [AF_INET]212.x.x.4:11941
                    Dec 27 20:19:21 	openvpn[28073]: UDPv4 link local (bound): [AF_INET]87.x.x.190
                    Dec 27 20:19:21 	openvpn[28073]: Preserving previous TUN/TAP instance: ovpnc1
                    Dec 27 20:19:21 	openvpn[28073]: Re-using pre-shared static key
                    Dec 27 20:19:21 	openvpn[28073]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
                    Dec 27 20:19:19 	openvpn[28073]: SIGUSR1[soft,ping-restart] received, process restarting
                    Dec 27 20:19:19 	openvpn[28073]: Inactivity timeout (--ping-restart), restarting
                    

                    @marvosa:
                    I thought you want the pfsense-config-file … there are passwords in cleartext (at many parts). Where can I find the openvpn-config-files? I've pfsense at both sides.

                    1 Reply Last reply Reply Quote 0
                    • M
                      marvosa
                      last edited by

                      The client-side log is not going to say much, we need to see the log from the server-side.

                      The OpenVPN configs are in /var/etc/openvpn

                      1 Reply Last reply Reply Quote 0
                      • C
                        crach
                        last edited by

                        As written, there is no Log on the server side … not one line (about this instance)

                        OK ... problem found ;) I've set the server to the WAN-Interface ... but he have to listen to a virtual ip on this interface ... so he tried to bind to the main ip instead of the virtual ip address.
                        I've changed the interface and one second later, the client was connected.

                        Anyway ... many thanks for your inputs ...
                        Kind regards

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