Navigation

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

    Client –-> server (OK) ---> Internet (NOT OK)

    OpenVPN
    3
    7
    1585
    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.
    • D
      dplat last edited by

      Hi everyone !

      I'm unsuccesfully trying to remotely access to the internet, as if I would be at home, using my Windows notebook OpenVPN client.
      (I have used the OpenVPN wizard to create my server & the OpenVPN Client Export Utility 1.2.4. - I have changed the IP addresses in my logs below).

      Here is the path I need:
      My Windows 8.1 notebook w/OpenVPN Client (at work) –-> My pfSense 2.1 OpenVPN Server 2.3.2 (at home) ---> Internet

      I CAN connect (from 10.2.6.2) to my OpenVPN Server, access to my home lan (192.168.1.X), but for some reason, I CAN'T access to the internet (see LOGs below).  >:(      (88.116.133.19 is my ADSL modem address in Gateway mode).

      I would appreciate very much that someone clearly tell me what I need to add/change to make it work.

      Thank you!

      Dennis

      Here is my Firewall OpenVPN rule:

      Here is my Windows client configuration:

      dev tun
      persist-tun
      persist-key
      cipher AES-256-CBC
      auth SHA1
      tls-client
      client
      resolv-retry infinite
      remote 88.116.133.19 8080 tcp
      lport 0
      verify-x509-name "CertSrvIP" name
      pkcs12 gogol-TCP-8080-UserIP.p12
      tls-auth gogol-TCP-8080-UserIP-tls.key 1
      ns-cert-type server
      comp-lzo
      verb 3

      Here is my pfSense OpenVPN Server configuration :

      dev ovpns1
      dev-type tun
      tun-ipv6
      dev-node /dev/tun1
      writepid /var/run/openvpn_server1.pid
      #user nobody
      #group nobody
      script-security 3
      daemon
      keepalive 10 60
      ping-timer-rem
      persist-tun
      persist-key
      proto tcp-server
      cipher AES-256-CBC
      up /usr/local/sbin/ovpn-linkup
      down /usr/local/sbin/ovpn-linkdown
      local 88.116.133.19
      tls-server
      server 10.2.6.0 255.255.255.248
      client-config-dir /var/etc/openvpn-csc
      tls-verify /var/etc/openvpn/server1.tls-verify.php
      lport 8080
      management /var/etc/openvpn/server1.sock unix
      max-clients 1
      push "dhcp-option DNS 8.8.8.8"
      push "dhcp-option DNS 8.8.4.4"
      push "redirect-gateway def1"
      ca /var/etc/openvpn/server1.ca
      cert /var/etc/openvpn/server1.cert
      key /var/etc/openvpn/server1.key
      dh /etc/dh-parameters.4096
      tls-auth /var/etc/openvpn/server1.tls-auth 0
      comp-lzo
      persist-remote-ip
      float
      topology subnet
      verb 2

      The OpenVPN client LOG connection :

      Sat Dec 21 10:48:48 2013 OpenVPN 2.3.2 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [eurephia] [IPv6] built on Aug 22 2013
      Enter Management Password:
      Sat Dec 21 10:48:48 2013 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
      Sat Dec 21 10:48:48 2013 Need hold release from management interface, waiting…
      Sat Dec 21 10:48:49 2013 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
      Sat Dec 21 10:48:49 2013 MANAGEMENT: CMD 'state on'
      Sat Dec 21 10:48:49 2013 MANAGEMENT: CMD 'log all on'
      Sat Dec 21 10:48:49 2013 MANAGEMENT: CMD 'hold off'
      Sat Dec 21 10:48:49 2013 MANAGEMENT: CMD 'hold release'
      Sat Dec 21 10:48:49 2013 Control Channel Authentication: using 'gogol-TCP-8080-UserIP-tls.key' as a OpenVPN static key file
      Sat Dec 21 10:48:49 2013 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
      Sat Dec 21 10:48:49 2013 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
      Sat Dec 21 10:48:49 2013 Socket Buffers: R=[128000->128000] S=[49152->49152]
      Sat Dec 21 10:48:49 2013 MANAGEMENT: >STATE:1387619329,RESOLVE,,,
      Sat Dec 21 10:48:49 2013 Attempting to establish TCP connection with [AF_INET]88.116.133.19:8080
      Sat Dec 21 10:48:49 2013 MANAGEMENT: >STATE:1387619329,TCP_CONNECT,,,
      Sat Dec 21 10:48:49 2013 TCP connection established with [AF_INET]88.116.133.19:8080
      Sat Dec 21 10:48:49 2013 TCPv4_CLIENT link local (bound): [undef]
      Sat Dec 21 10:48:49 2013 TCPv4_CLIENT link remote: [AF_INET]88.116.133.19:8080
      Sat Dec 21 10:48:49 2013 MANAGEMENT: >STATE:1387619329,WAIT,,,
      Sat Dec 21 10:48:50 2013 MANAGEMENT: >STATE:1387619330,AUTH,,,
      Sat Dec 21 10:48:50 2013 TLS: Initial packet from [AF_INET]88.116.133.19:8080, sid=7e0571bb d1cc1072
      Sat Dec 21 10:48:53 2013 VERIFY OK: depth=1, C=US, ST=, L=, O=, emailAddress=, CN=CertCAIP
      Sat Dec 21 10:48:53 2013 VERIFY OK: nsCertType=SERVER
      Sat Dec 21 10:48:53 2013 VERIFY X509NAME OK: C=US, ST=, L=, O=, emailAddress=, CN=CertSrvIP
      Sat Dec 21 10:48:53 2013 VERIFY OK: depth=0, C=US, ST=, L=, O=, emailAddress=, CN=CertSrvIP
      Sat Dec 21 10:48:56 2013 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
      Sat Dec 21 10:48:56 2013 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
      Sat Dec 21 10:48:56 2013 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
      Sat Dec 21 10:48:56 2013 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
      Sat Dec 21 10:48:56 2013 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 4096 bit RSA
      Sat Dec 21 10:48:56 2013 [CertSrvIP] Peer Connection Initiated with [AF_INET]88.116.133.19:8080
      Sat Dec 21 10:48:57 2013 MANAGEMENT: >STATE:1387619337,GET_CONFIG,,,
      Sat Dec 21 10:48:58 2013 SENT CONTROL [CertSrvIP]: 'PUSH_REQUEST' (status=1)
      Sat Dec 21 10:48:58 2013 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,redirect-gateway def1,route-gateway 10.2.6.1,topology subnet,ping 10,ping-restart 60,ifconfig 10.2.6.2 255.255.255.248'
      Sat Dec 21 10:48:58 2013 OPTIONS IMPORT: timers and/or timeouts modified
      Sat Dec 21 10:48:58 2013 OPTIONS IMPORT: –ifconfig/up options modified
      Sat Dec 21 10:48:58 2013 OPTIONS IMPORT: route options modified
      Sat Dec 21 10:48:58 2013 OPTIONS IMPORT: route-related options modified
      Sat Dec 21 10:48:58 2013 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
      Sat Dec 21 10:48:58 2013 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
      Sat Dec 21 10:48:58 2013 MANAGEMENT: >STATE:1387619338,ASSIGN_IP,,10.2.6.2,
      Sat Dec 21 10:48:58 2013 open_tun, tt->ipv6=0
      Sat Dec 21 10:48:58 2013 TAP-WIN32 device [Connexion au réseau local] opened: \.\Global{706F7949-370A-4ACF-BE2B-D721447250AE}.tap
      Sat Dec 21 10:48:58 2013 TAP-Windows Driver Version 9.9
      Sat Dec 21 10:48:58 2013 Set TAP-Windows TUN subnet mode network/local/netmask = 10.2.6.0/10.2.6.2/255.255.255.248 [SUCCEEDED]
      Sat Dec 21 10:48:58 2013 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.2.6.2/255.255.255.248 on interface {706F7949-370A-4ACF-BE2B-D721447250AE} [DHCP-serv: 10.2.6.6, lease-time: 31536000]
      Sat Dec 21 10:48:58 2013 Successful ARP Flush on interface [46] {706F7949-370A-4ACF-BE2B-D721447250AE}
      Sat Dec 21 10:49:03 2013 TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up
      Sat Dec 21 10:49:03 2013 C:\WINDOWS\system32\route.exe ADD 88.116.133.19 MASK 255.255.255.255 78.251.255.254
      Sat Dec 21 10:49:03 2013 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=25 and dwForwardType=4
      Sat Dec 21 10:49:03 2013 Route addition via IPAPI succeeded [adaptive]
      Sat Dec 21 10:49:03 2013 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.2.6.1
      Sat Dec 21 10:49:03 2013 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
      Sat Dec 21 10:49:03 2013 Route addition via IPAPI succeeded [adaptive]
      Sat Dec 21 10:49:03 2013 C:\WINDOWS\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.2.6.1
      Sat Dec 21 10:49:03 2013 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
      Sat Dec 21 10:49:03 2013 Route addition via IPAPI succeeded [adaptive]
      Sat Dec 21 10:49:03 2013 Initialization Sequence Completed
      Sat Dec 21 10:49:03 2013 MANAGEMENT: >STATE:1387619343,CONNECTED,SUCCESS,10.2.6.2,88.116.133.19

      The OpenVPN server connection LOG (in reverse order) :

      Dec 21 10:49:00 openvpn[18084]: UserIP/78.251.151.106:50644 send_push_reply(): safe_cap=940
      Dec 21 10:48:58 openvpn[18084]: UserIP/78.251.151.106:50644 MULTI_sva: pool returned IPv4=10.2.6.2, IPv6=(Not enabled)
      Dec 21 10:48:58 openvpn[18084]: 78.251.151.106:50644 [UserIP] Peer Connection Initiated with [AF_INET]78.251.151.106:50644
      Dec 21 10:48:58 openvpn[18084]: 78.251.151.106:50644 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 4096 bit RSA
      Dec 21 10:48:58 openvpn[18084]: 78.251.151.106:50644 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
      Dec 21 10:48:58 openvpn[18084]: 78.251.151.106:50644 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
      Dec 21 10:48:58 openvpn[18084]: 78.251.151.106:50644 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
      Dec 21 10:48:58 openvpn[18084]: 78.251.151.106:50644 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
      Dec 21 10:48:57 openvpn[18084]: 78.251.151.106:50644 VERIFY OK: depth=0, C=US, ST=, L=, O=, emailAddress=, CN=UserIP
      Dec 21 10:48:57 openvpn[18084]: 78.251.151.106:50644 VERIFY SCRIPT OK: depth=0, C=US, ST=, L=, O=, emailAddress=, CN=UserIP
      Dec 21 10:48:57 openvpn[18084]: 78.251.151.106:50644 VERIFY OK: depth=1, C=US, ST=, L=, O=, emailAddress=, CN=CertCAIP
      Dec 21 10:48:57 openvpn[18084]: 78.251.151.106:50644 VERIFY SCRIPT OK: depth=1, C=US, ST=, L=, O=, emailAddress=, CN=CertCAIP
      Dec 21 10:48:51 openvpn[18084]: TCP connection established with [AF_INET]78.251.151.106:50644

      1 Reply Last reply Reply Quote 0
      • T
        toverfee last edited by

        Try adding this in advanced settings (this fixed it for me):
        push "route LANNET LANNETMASK";
          e.g.: push "route 192.168.0.0 255.255.255.0 vpn_gateway";

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

          Thank you, good try, but still no internet access.

          Any guru's got a brilliant idea about what's wrong??  ???

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

            Hey, I forgot to mention this rule:

            1 Reply Last reply Reply Quote 0
            • P
              phil.davis last edited by

              The logs look OK - "redirect-gateway def1" is happening and the client end seems to be making the OpenVPN link the route to everything, as required. pfSense at home should automatically NAT that traffic out on your home WAN (Automatic Outbound NAT). If you have changed to Manual Outbound NAT then you would have to add and extra NAT rule on home WAN to NAT the traffic from the OpenVPN when going out to the internet.
              Look in /tmp/rules.debug on home pfSense and see what NAT rules it has made:

              # Outbound NAT rules

# Subnets to NAT 
table <tonatsubnets>{ 10.49.80.0/22 10.50.80.0/24 127.0.0.0/8 0.0.0.0  }
nat on $WIMAX  from <tonatsubnets>port 500 to any port 500 -> 10.49.94.1/32 port 500  
nat on $WIMAX  from <tonatsubnets>to any -> 10.49.94.1/32 port 1024:65535</tonatsubnets></tonatsubnets></tonatsubnets>

              For example, 10.49.80.0/22 is a LAN and 10.50.80.0/24 is the road warrior OpenVPN server in the above. You should see both your LAN and OpenVPN tunnel networks in table <tonatsubnets>The other thing to try is to give the tunnel network more than "/29" - I always use a bigger subnet (e.g. /24 is easy) and let OpenVPN allocate that out internally itself in /29 chunks - but I doubt that is the real problem.)</tonatsubnets>

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

                BRILLIANT! Thank you Phil!!  8)  You're a real GURU!
                Yes, I had changed to "Manual Outbound NAT" (I prefer manual, I believe it is more secure).
                Adding a simple rule did the trick!

                A few more questions:

                1. Concerning your example:

                Subnets to NAT

                table <tonatsubnets>{ 10.49.80.0/22 10.50.80.0/24 127.0.0.0/8 0.0.0.0  }

                See the 0.0.0.0 at the end?
                Well, I have the "127.0.0.0/8" rule configured in my web interface but I don't have the 0.0.0.0 NAT rule.

                Can you make a screenshot of this 0.0.0.0 rule for me, so I can add it manually?
                "Firewall: NAT: Outbound: Edit" / "Edit Advanced Outbound NAT entry"
                ( https://pfSenseAddress/firewall_nat_out_edit.php?id=X )

                BTW, I don't really understand its usefullness since everything seems to work well without it!?

                1. When my OpenVPN server is enabled with no client connection, I constantly get the following messages in my OpenVPN log (every 62 seconds) Is it normal? :

                Dec 23 11:03:14 openvpn[3427]: MANAGEMENT: Client disconnected
                Dec 23 11:03:14 openvpn[3427]: MANAGEMENT: CMD 'quit'
                Dec 23 11:03:14 openvpn[3427]: MANAGEMENT: CMD 'status 2'
                Dec 23 11:03:14 openvpn[3427]: MANAGEMENT: Client connected from /var/etc/openvpn/server1.sock
                Dec 23 11:02:12 openvpn[3427]: MANAGEMENT: Client disconnected
                Dec 23 11:02:12 openvpn[3427]: MANAGEMENT: CMD 'quit'
                Dec 23 11:02:12 openvpn[3427]: MANAGEMENT: CMD 'status 2'
                Dec 23 11:02:12 openvpn[3427]: MANAGEMENT: Client connected from /var/etc/openvpn/server1.sock
                Dec 23 11:01:10 openvpn[3427]: MANAGEMENT: Client disconnected
                Dec 23 11:01:10 openvpn[3427]: MANAGEMENT: CMD 'quit'
                Dec 23 11:01:10 openvpn[3427]: MANAGEMENT: CMD 'status 2'
                Dec 23 11:01:10 openvpn[3427]: MANAGEMENT: Client connected from /var/etc/openvpn/server1.sock

                THANK YOU very much!</tonatsubnets>

                1 Reply Last reply Reply Quote 0
                • P
                  phil.davis last edited by

                  The 0.0.0.0 thing was automagically added by the pfSense code (filter.inc 2.1-RELEASE). It is not needed - it was changed to 0.0.0.0/32 in GitHub recently then removed altogether by this commit:
                  https://github.com/pfsense/pfsense/commit/992324efad8f8c2c8144619e8c7681458560cd16
                  So you can ignore it - no special NAT rule needed for that.

                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post

                  Products

                  • Platform Overview
                  • TNSR
                  • pfSense
                  • Appliances

                  Services

                  • Training
                  • Professional Services

                  Support

                  • Subscription Plans
                  • Contact Support
                  • Product Lifecycle
                  • Documentation

                  News

                  • Media Coverage
                  • Press
                  • Events

                  Resources

                  • Blog
                  • FAQ
                  • Find a Partner
                  • Resource Library
                  • Security Information

                  Company

                  • About Us
                  • Careers
                  • Partners
                  • Contact Us
                  • Legal
                  Our Mission

                  We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                  Subscribe to our Newsletter

                  Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                  © 2021 Rubicon Communications, LLC | Privacy Policy