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

    PfSense fully exposed to WWW over OpenVPN Client

    Firewalling
    4
    11
    1.9k
    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.
    • J
      JoelLinn
      last edited by

      Just digged through my Graylog2 server and saw some unusual amount of sshd messages.
      I have two OVPN clients running that are used to access locale based  content.
      It seems that if you connect to those public IPs, everything exposed to the LAN is also exposed to it.

      How can I treat these Interfaces like the WAN interface to increase security?

      FIX:
      Mind that there are not only the interfaces you create and assign to your client connections.
      The OpenVPN tab in the rules is where you simply don't want a allow any rule.

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

        Can you post a screenshot of your VPN firewall rules?

        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
        • J
          JoelLinn
          last edited by

          There are no extra rules on the VPN interfaces.
          I once tried to activate the block private and bogon networks in the interface settings, but couldn't make any connection after that.

          Of course there is no NATing done by my VPN provider, I have my very own IPs.

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

            Has to be some rules either on the OpenVPN tab (covering all the OpenVPNs), or the individual OpenVPN interfaces assuming they're assigned.

            1 Reply Last reply Reply Quote 0
            • J
              JoelLinn
              last edited by

              Totally not thought about that tab.
              There is a pass all rule that was created for the openvpn server.
              That definitely can explain the behaviour.
              Can I just add block rules above for any traffic to the interface adresses? Will that fix the problem and only  leave over traffic that's NATed?

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

                The firewall rules on the OpenVPN tab work just like any other interface rules.  You can pass or block any connections initiated from the OpenVPN clients.

                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
                • C
                  cmb
                  last edited by

                  Change your rule on the OpenVPN tab to specify the tunnel network of that remote access OpenVPN instance as the source instead of any.

                  1 Reply Last reply Reply Quote 0
                  • J
                    JoelLinn
                    last edited by

                    I now have two rules applying to OpenVPN.

                    • Allow from 172…...(VPN tunnel network) to any

                    • Allow from WAN adress to any

                    without the second rule i was not able to establish Client connections from pfSense.

                    I guess it should be secure by now. What do you guys think? :)

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

                      You will never receive traffic into OpenVPN from WAN address (and if you did you'd probably want to drop it) so I'm not sure what that rule is for.

                      I've re-read your posts a couple times and it's unclear to me exactly what you're talking about.  In order to know what a firewall rule does, we need to know what interface it's on.

                      https://doc.pfsense.org/index.php/Firewall_Rule_Troubleshooting

                      Be sure that the rules are on the proper interface. Imagine sitting inside of the pfSense box. Sure, it's a little crowded in there, but this can help. Imagine packets flying in from the different networks that the pfSense box ties together. The rules will be placed on the interface they entered from. If a packet is going from the LAN to the pfSense box, then out to the Internet, the rules still enter on the LAN. If a packet is coming from the Internet to the pfSense box, the rule goes on the WAN interface.

                      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
                      • J
                        JoelLinn
                        last edited by

                        Sure there is no traffic into OpenVPN from the WAN adress, but I thought there is traffic out of OpenVPN to establish the client connections.
                        Unfortunately the assumption that the second rule is needed was a wrong conclusion because the vpn provider seems to have upstream problems and connection outages behind the OpenVPN endpoint(temp. outages without log entries on my side), sorry for the confusion.
                        To prevent further confusion here are some screenshots.
                        No rules on UK and US  interfaces.

                        If there is no more confusion left I hereby declare the question as answered. Simply didn't mind the OpenVPN interface

                        pf1.png
                        pf1.png_thumb
                        pf2.png
                        pf2.png_thumb

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

                          What, exactly, do you want to have happen?  Where do you want connections to originate and to what do you want them to be able to connect?

                          What do you want to block?  On what interface does that traffic arrive into pfSense?

                          So UK and US are pfSense interfaces assigned to the OpenVPN client instances?  If so, then you don't need any rules at all.  Your pfSense node makes an outbound connection (out WAN) on UDP/53.  You would need to make special rules to block such traffic.

                          You also have an OpenVPN server defined?  What is that for?  Where does it fit into the picture?

                          If you want to run an OpenVPN server you will need firewall rules on the incoming interface (usually WAN) for the listening port (default UDP/1194).  This is for the establishment of the OpenVPN tunnel.  After the tunnel is established, connections from OpenVPN clients arrive into pfSense on the OpenVPN tab or the appropriate OpenVPN assigned interface.

                          Connections from your client computers arrive on your LAN interface and are governed by the rules found there.

                          Connections coming into pfSense on your US connection are allowed by the rules on your OpenVPN tab, then your US tab.  Connections coming into pfSense from your UK tab are allowed first by the rules on your OpenVPN tab then your UK tab.  When I use assigned interfaces I usually delete all the rules on the OpenVPN tab.

                          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
                          • First post
                            Last post
                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.