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

    How to configure OpenVPN client for XeroBank

    OpenVPN
    3
    8
    9.4k
    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
      mikeg
      last edited by

      I'm attempting to configure a pfSense OpenVPN client for XeroBank's privacy service.  The account credentials that I'm using work with OpenVPN.  I'm using a pfSense 2.0-RC3 guest in VirtualBox 4.0.12 on Ubuntu 10.10 x64, with WAN NATed to the host, and LAN connected to an internal network.

      In configuring the client, I've followed http://forum.pfsense.org/index.php?topic=24435.0.html and http://forum.pfsense.org/index.php/topic,29944.0.html.  In pfSense's OpenVPN system log, I see the following TLS error:

      TLS: Initial packet from [server etc]
      TLS Error: cannot locate HMAC in incoming packet from [server etc]

      What might be causing that?

      The OpenVPN config file from XeroBank contains the following lines:

      client
      dev tun
      proto udp
      remote [foo].xerobank.com 1194
      resolv-retry infinite
      nobind
      persist-tun
      tls-client
      ca xbca.crt
      cert xerobank.crt
      key xb.key
      dh xb-dh2048.pem
      keepalive 20 200
      cipher BF-CBC
      cipher AES-256-CBC
      tls-remote vpngate
      ns-cert-type server
      route-delay 2
      redirect-gateway def1
      explicit-exit-notify 3
      comp-lzo
      verb 3

      I've used the following settings in the pfSense OpenVPN client:

      Server Mode: Peer to Peer (SSL/TLS)
      Protocol: UDP
      Device Mode: tun
      Interface: WAN
      Local port:
      Server host or address: [foo].xerobank.com
      Server port: 1194
      Proxy host or address:
      Proxy port:
      Proxy authentication extra options:
      Server host name resolution: Infinitely resolve server
      TLS Authentication: Enable authentication of TLS packets
      Peer Certificate Authority: xbca.crt
      Client Certificate: xerobank.crt (CA xbca.crt) [with xb.key]
      Encryption algorithm: BF-CBC (128-bit)
      Hardware Crypto: No Hardware Crypto Acceleration
      Tunnel Network:
      Remote Network:
      Limit Outgoing Bandwidth:
      Compression: Compress tunnel packets using the LZO algorithm
      Type-of-Service: [either way]

      Advanced: keepalive 20 200;ns-cert-type server;route-delay 2;redirect-gateway def1;explicit-exit-notify 3;verb 3

      Adding "tls-client", "tls-remote vpngate" and/or "persist-tun" to the Advanced options had no apparent effect.  Neither did copying xb-dh2048.pem to /var/etc/openvpn/, and adding either "dh xb-dh2048.pem" or "dh /var/etc/openvpn/xb-dh2048.pem" to Advanced options.

      With TLS Authentication turned off, I get a tunnel, but it doesn't work:

      [expected /sbin/route etc]
      Initialization Sequence Completed
      Authenticate/Decrypt packet error: cipher final failed

      1 Reply Last reply Reply Quote 0
      • E
        ericab
        last edited by

        The OpenVPN config file from XeroBank contains 2 ciphers.

        XeroBank uses AES-256-CBC

        remove the reference to BF-CBC.

        also for the sake of troubleshooting, change "verb 3", to "verb 5"; and copy paste any issues you may have from the log then here.

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

          Thanks, ericab  :)

          @ericab:

          The OpenVPN config file from XeroBank contains 2 ciphers.

          It's my understanding that the redundancy is intentional.  Is that correct?

          @ericab:

          XeroBank uses AES-256-CBC

          Yes, I see in successful connections (using OpenVPN) that it uses "Cipher 'AES-256-CBC' initialized with 256 bit key" and "160 bit message hash 'SHA1' for HMAC authentication" for the data channel, and "TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA" for the control channel.

          @ericab:

          remove the reference to BF-CBC.

          I've changed the Encryption algorithm setting to "AES-256-CBC".

          @ericab:

          also for the sake of troubleshooting, change "verb 3", to "verb 5"; and copy paste any issues you may have from the log then here.

          I've changed "verb 3" to "verb 5".  I've checked the Type-of-Service box ("Set the TOS IP header value of tunnel packets to match the encapsulated packet value").  The Advanced items are "dh /var/etc/openvpn/xb-dh2048.pem;keepalive 20 200;ns-cert-type server;route-delay 2;redirect-gateway def1;explicit-exit-notify 3;verb 5".

          Here's the relevant piece of the log, obfuscated slightly:

          Jul 31 HH:19:59 	openvpn[61891]: SIGUSR1[soft,tls-error] received, process restarting
          Jul 31 HH:19:59 	openvpn[61891]: Restart pause, 2 second(s)
          Jul 31 HH:20:01 	openvpn[61891]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
          Jul 31 HH:20:01 	openvpn[61891]: Re-using SSL/TLS context
          Jul 31 HH:20:01 	openvpn[61891]: LZO compression initialized
          Jul 31 HH:20:01 	openvpn[61891]: Control Channel MTU parms [ L:1558 D:166 EF:66 EB:0 ET:0 EL:0 ]
          Jul 31 HH:20:01 	openvpn[61891]: Socket Buffers: R=[42080->65536] S=[57344->65536]
          Jul 31 HH:20:01 	openvpn[61891]: RESOLVE: NOTE: {foo}.xerobank.com resolves to {N} addresses
          Jul 31 HH:20:01 	openvpn[61891]: Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ]
          Jul 31 HH:20:01 	openvpn[61891]: Local Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-client'
          Jul 31 HH:20:01 	openvpn[61891]: Expected Remote Options String: 'V4,dev-type tun,link-mtu 1558,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 0,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-server'
          Jul 31 HH:20:01 	openvpn[61891]: Local Options hash (VER=V4): '{nnnnnnnn}'
          Jul 31 HH:20:01 	openvpn[61891]: Expected Remote Options hash (VER=V4): '{mmmmmmmm}'
          Jul 31 HH:20:01 	openvpn[61891]: UDPv4 link local (bound): [AF_INET]10.0.2.15
          Jul 31 HH:20:01 	openvpn[61891]: UDPv4 link remote: [AF_INET]{N.N.N.N}:1194
          Jul 31 HH:20:01 	openvpn[61891]: TLS: Initial packet from [AF_INET]{N.N.N.N}:1194, sid={rrrrrrrr rrrrrrrr}
          Jul 31 HH:20:01 	openvpn[61891]: TLS Error: cannot locate HMAC in incoming packet from [AF_INET]{N.N.N.N}:1194
          Jul 31 HH:20:04 	openvpn[61891]: TLS: Initial packet from [AF_INET]{N.N.N.N}:1194, sid={rrrrrrrr rrrrrrrr}
          Jul 31 HH:20:04 	openvpn[61891]: TLS Error: cannot locate HMAC in incoming packet from [AF_INET]{N.N.N.N}:1194
          ...
          Jul 31 HH:21:00 	openvpn[61891]: TLS: Initial packet from [AF_INET]{N.N.N.N}:1194, sid={rrrrrrrr rrrrrrrr}
          Jul 31 HH:21:00 	openvpn[61891]: TLS Error: cannot locate HMAC in incoming packet from [AF_INET]{N.N.N.N}:1194
          Jul 31 HH:21:01 	openvpn[61891]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
          Jul 31 HH:21:01 	openvpn[61891]: TLS Error: TLS handshake failed
          Jul 31 HH:21:01 	openvpn[61891]: TCP/UDP: Closing socket
          Jul 31 HH:21:01 	openvpn[61891]: SIGUSR1[soft,tls-error] received, process restarting
          
          1 Reply Last reply Reply Quote 0
          • N
            Nachtfalke
            last edited by

            I think there is a problem with the xb.key file.
            In the servers config there is a seperate file xb.key and in the clients config there isn't.
            Can you add this line in your clients.conf and the put the according xb.key in the clients folder ?

            key xb.key
            
            1 Reply Last reply Reply Quote 0
            • M
              mikeg
              last edited by

              @Nachtfalke:

              I think there is a problem with the xb.key file.
              In the servers config there is a seperate file xb.key and in the clients config there isn't.
              Can you add this line in your clients.conf and the put the according xb.key in the clients folder ?

              key xb.key
              

              Thank you.  I used xb.key for xerobank.crt in Certificate Manager.  It's now found in /var/etc/openvpn/ as client1.key, along with client1.ca, client1.cert, client1.conf, client1.tls-auth, and xb-dh2048.pem (which I added manually).

              FWIW, here's client1.conf compared with the XeroBank config file:

              [Edit4:  I unchecked TLS authentication in the GUI, and now it works.  The TLS error "cannot locate HMAC in incoming packet" was indeed telling me that I had a TLS-authentication mismatch.  When I initially tried connecting without TLS authentication, I didn't yet have DH set up properly.  Anyway, I thank everyone who helped or even thought about helping.  Once I get traffic routed, I'll write up a how-to.]

              [Edit3: I added "tls-remote vpngate" back to pfSense Advanced.  Still no joy.]
              [Edit2: Is it advisable to directly edit client1.conf?]
              [Edit: I don't know why the table is oddly colored.]

              | pfSense | XeroBank |
              | dev ovpnc1 | dev tun |
              | dev-type tun | {null} |
              | dev-node /dev/tun1 | {null} |
              | writepid /var/run/openvpn_client1.pid | {null} |
              | #user nobody | {null} |
              | #group nobody | {null} |
              | script-security 3 | {null} |
              | daemon | {null} |
              | keepalive 10 60 | keepalive 20 200 |
              | ping-timer-rem | {null} |
              | persist-tun | persist-tun |
              | persist-key | {null} |
              | proto udp | proto udp |
              | cipher AES-256-CBC | cipher AES-256-CBC |
              | {null} | cipher BF-CBC |
              | up /usr/local/sbin/ovpn-linkup | {null} |
              | down /usr/local/sbin/ovpn-linkdown | {null} |
              | local 10.0.2.15 | nobind |
              | tls-client | tls-client |
              | client | client |
              | lport 0 | {null} |
              | management /var/etc/openvpn/client1.sock unix | {null} |
              | remote [foo].xerobank.com 1194 | remote [foo].xerobank.com 1194 |
              | ca /var/etc/openvpn/client1.ca | ca xbca.crt |
              | cert /var/etc/openvpn/client1.cert | cert xerobank.crt |
              | key /var/etc/openvpn/client1.key | key xb.key |
              | comp-lzo | comp-lzo |
              | passtos | {null} |
              | resolv-retry infinite | resolv-retry infinite |
              | dh /var/etc/openvpn/xb-dh2048.pem | dh xb-dh2048.pem |
              | keepalive 20 200 | {see above} |
              | tls-remote vpngate | tls-remote vpngate |
              | ns-cert-type server | ns-cert-type server |
              | route-delay 2 | route-delay 2 |
              | redirect-gateway def1 | redirect-gateway def1 |
              | explicit-exit-notify 3 | explicit-exit-notify 3 |
              | verb 5 | verb 3 |

              1 Reply Last reply Reply Quote 0
              • N
                Nachtfalke
                last edited by

                Hi,

                on the left (client) side you have two time "keepalive".
                Further I am not sure if is correct, that both sides are using "tls-client". I think the client side should use "tls-server".

                But I am no expert.

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

                  @Nachtfalke:

                  …on the left (client) side you have two time "keepalive".

                  Thank you.  I wasn't clear about the columns.  Both are clients.  The left column is the client config generated by the pfSense OpenVPN client set-up GUI.  The right column is a client config provided by XeroBank.  It's my model, as it were, in that I know that it works.

                  I do have two keepalive lines.  The "keepalive 10 60" line seems to be pfSense's default.  I don't see in the GUI where it's set.  The "keepalive 20 200" line is from the  client config provided by XeroBank.

                  @Nachtfalke:

                  Further I am not sure if is correct, that both sides are using "tls-client". I think the client side should use "tls-server".

                  As I've noted, both are client scripts.

                  @Nachtfalke:

                  But I am no expert.

                  Well, neither am I, as I've demonstrated in this thread!  The TLS error "cannot locate HMAC in incoming packet" was clearly pointing to a TLS-authentication mismatch between client and server.  I had googled that error, and had found numerous comments to that effect.  Yet I was just too stubborn to see it, because I'd already failed with TLS authentication disabled in the GUI.  However, as I posted here, the client actually did connect with TLS authentication disabled (although it couldn't decrypt packets).  In retrospect, I see that packet decryption failed because I hadn't yet properly set up SSL/TLS authentication for the pfSense client.

                  As I now (vaguely) appreciate, "TLS authentication" for pfSense means using a shared persistent TLS key ("client1.tls-auth") which is generated by the client (indicated by the terminal "1" in "tls-auth /var/etc/openvpn/client1.tls-auth 1").  What XeroBank's OpenVPN servers expect, OTOH, is periodically generating SSL/TLS keys cooperatively based on the shared DH parameters file ("xb-dh2048.pem") – which is accomplished by "dh /var/etc/openvpn/xb-dh2048.pem".

                  Now I need to set up routing.

                  Thanks again to everyone who helped in any way.  I believe that this thread has done it's job, unless any y'all want to hijack it.

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

                    I've managed to create an OpenVPN client on pfSense that connects to XeroBank.  I've also managed, at least partially, to secure the VPN connection.  However, I'd appreciate criticism and suggestions.

                    To summarize, I'm using a pfSense 2.0-RC3 guest in VirtualBox 4.0.12 ("pfSense").  The WAN interface is NATed to the VirtualBox host, and the LAN interface is connected to a VirtualBox internal network ("pfSLAN").  Also connected to pfSLAN is an Ubuntu Maverick guest ("Ubuntu").

                    With ovpnc1 up, I see new "def1 type" routes, and traceroute at pfSense shell on interface ovpnc1 to internet sites shows expected routing via XeroBank's exit node.  Enabling Outbound NAT for LAN to OpenVPN allows Ubuntu to access the internet via ovpnc1.  Use OpenVPN to connect to vpntunnel.se (or similar) and Re: How to create an OpenVPN client to a public OpenVPN provider offered key insights, BTW.

                    In System: General Setup, I've specified a public DNS server (XYZ.com) and disabled "Allow DNS server list to be overridden by DHCP/PPP on WAN".  I've disabled DNS Forwarder, and specified XeroBank's internal DNS servers (10.244.1.1 and 10.244.2.1) in DHCP Server on LAN.  Just to be safe, I also created firewall rules to block LAN access to XYZ.com's DNS servers.

                    With ovpnc1 down, Ubuntu can ping nothing except pfSense.  With ovpnc1 up, packet captures on WAN confirm that traffic from Ubuntu is restricted to ovpnc1.  That is, the only IP addresses that I see are pfSense (10.0.2.15), its VirtualBox gateway (10.0.2.2) and XeroBank's OpenVPN server.  Steve Gibson's DNS Nameserver Spoofability Test reveals that Ubuntu can access only XeroBank's internal DNS servers.

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