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

OpenVPN routing

Scheduled Pinned Locked Moved OpenVPN
8 Posts 3 Posters 1.8k 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.
  • S
    SalSolo
    last edited by Jun 21, 2014, 7:26 PM

    Hi all.
    I have been running pfsense for a while now and are extremely happy with it .. so now I have decided to try using the openVPN option for it to create tunnels from client to my network.

    Basically it is up and running .. I can connect any client I need and they can access any local resources so that direction is working … but I cannot get the other way to work.

    Description of network:
    internal network xx.xx.xx.xx/16 --> pfsense as gateway --> openVPN network yy.yy.yy.yy /24
    I can ping from yy.yy.yy.yy to xx.xx.xx.xx and access all resources but I cannot ping from xx.xx.xx.xx to yy.yy.yy.yy or acces anything in that direction.

    I have googled it a lot and I can gather I am propably missing a rule in my NAT but for my life I cannot figure out the exact syntax and where to put it.

    pfsense is running in a virtual machine on esxi 5.5. (promiscious mode is enabled on the virtual switch).

    I hope someone here can give me some pointers to where to look next?
    Bear in mind that even if I have been running with pfsense for a while I am only famiiar with the gui ..it has covered my needs so far so I lack knowledge of the cli part.

    Help!!!! :) :) :)

    1 Reply Last reply Reply Quote 0
    • H
      heper
      last edited by Jun 21, 2014, 9:10 PM

      are you sure it's not just a firewall rule that is not working as expected?

      check your "internal-network' firewall tab and place a rule all the way on top (make it a PASS, PROTO any, dest: openvpn_subnet

      1 Reply Last reply Reply Quote 0
      • S
        SalSolo
        last edited by Jun 21, 2014, 9:37 PM

        Not sure of anything at this point :)
        … but my very first rule on wan is: pass, proto any, dest: any

        On LAN tab first rule is: pass, proto any, source: lannet, dest: any

        On OpenVPN tab: pass, proto any, source and destination any

        I do not have any block rules at all at the moment ..only port forwarding rules.

        1 Reply Last reply Reply Quote 0
        • S
          SalSolo
          last edited by Jun 24, 2014, 11:19 AM

          Just an update - issue is still not solved.
          From my point of view it looks like the openVPN tunnel only works one way …from client to server.
          All rules and setting applied indicates this should be a 2-way communication .. but it is not happening.
          IT seems to me like I need to add routes between the LAN and WAN interface in the same way that I push out the route for the clients but how do I do that?

          1 Reply Last reply Reply Quote 0
          • S
            SalSolo
            last edited by Jun 26, 2014, 9:37 AM

            Yay, a positive update :)

            I think I finally broke through my issue :)
            I was missing both an interface and some additional rules on my outbound tab.
            This link helped me get on track and hopefully it can help others as well.

            I still need some testing but icmb goes through now which it didn't before.

            http://www.bodenzord.com/archives/324

            1 Reply Last reply Reply Quote 0
            • J
              johnpoz LAYER 8 Global Moderator
              last edited by Jun 26, 2014, 12:35 PM

              So you didn't just use the wizard that would create all the stuff for you?

              An intelligent man is sometimes forced to be drunk to spend time with his fools
              If you get confused: Listen to the Music Play
              Please don't Chat/PM me for help, unless mod related
              SG-4860 24.11 | Lab VMs 2.7.2, 24.11

              1 Reply Last reply Reply Quote 0
              • S
                SalSolo
                last edited by Jul 2, 2014, 1:08 PM

                I did use the wizard but it did not create the needed interface for commnucation both ways .. after running the wizard all clients could connect to network and everything worked fine from their perpective but I could not initiate communication from the server side.

                After adding that interface and rules I could.

                1 Reply Last reply Reply Quote 0
                • S
                  SalSolo
                  last edited by Jul 2, 2014, 1:33 PM

                  Now moving on to the next challenge :)
                  I thought I was in the clear as I can ping both ways and access standard items both ways so I am pretty confident that the setup so far is on the right track …but I think I am missing something.

                  I need to connect to a specific port on the vpn network from the internal network. When I try it netstat on the client side is actually reporting it as established but no data will flow. When looking closely I can see that netstat reports the connection done between the client and the openVPN interface and not the source as I expected. See screenshot enclosed .. the source is 10.0.0.18

                  Is this the root of my problem and if so how do I make sure the communication flows back?

                  ![Screen Shot 07-02-14 at 02.53 PM.JPG](/public/imported_attachments/1/Screen Shot 07-02-14 at 02.53 PM.JPG)
                  ![Screen Shot 07-02-14 at 02.53 PM.JPG_thumb](/public/imported_attachments/1/Screen Shot 07-02-14 at 02.53 PM.JPG_thumb)

                  1 Reply Last reply Reply Quote 0
                  8 out of 8
                  • First post
                    8/8
                    Last post
                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                    This community forum collects and processes your personal information.
                    consent.not_received