Site2Site between two pfSenses - no response from Server



  • Hi,

    I've set up two pfSenses one with a openvpn server, the other one with a openvpn client.
    The client is trying to initiate the connection, what I can see on the server's firewall log (logging pass packets). Even if I capture the packets, they are comming in.

    But … no response from the server. No Log-Entry ... nothing.

    Any idea what that can be?

    Many thanks in advanced and marry christmas.



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

    Post your server1.conf and client1.conf.



  • 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



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



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



  • Yea- missed that  11941.

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


  • LAYER 8 Netgate

    What's in the OpenVPN log on the client?



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



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



  • 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



  • 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


Log in to reply