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

PfSense fully exposed to WWW over OpenVPN Client

Scheduled Pinned Locked Moved Firewalling
11 Posts 4 Posters 1.9k 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.
  • J
    JoelLinn
    last edited by Jan 16, 2015, 10:56 PM Jan 16, 2015, 12:57 AM

    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
    • C
      chpalmer
      last edited by Jan 16, 2015, 1:00 AM

      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 Jan 16, 2015, 1:03 AM

        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 Jan 16, 2015, 1:55 AM

          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 Jan 16, 2015, 6:24 AM

            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
            • D
              Derelict LAYER 8 Netgate
              last edited by Jan 16, 2015, 6:47 AM

              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 Jan 16, 2015, 8:10 PM

                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 Jan 16, 2015, 9:33 PM

                  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
                  • D
                    Derelict LAYER 8 Netgate
                    last edited by Jan 16, 2015, 10:15 PM

                    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 Jan 16, 2015, 10:50 PM

                      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
                      • D
                        Derelict LAYER 8 Netgate
                        last edited by Jan 16, 2015, 11:58 PM

                        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
                        11 out of 11
                        • First post
                          11/11
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
                          This community forum collects and processes your personal information.
                          consent.not_received