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

    Firewall Rules for second network

    Scheduled Pinned Locked Moved Firewalling
    15 Posts 2 Posters 7.5k 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.
    • C
      cmb991
      last edited by

      I'm trying to setup our network so it can pull this one shared folder off of another network.  The two networks are connected via cat5e from our pfsense firewall to the other network's switch.  Our network needs to be able to access \192.168.0.10\FOLDER .  It seems I am able to access anything on that other network as long as I have valid credentials.

      What I'm trying to do is prevent the other network from accessing any of our files.  Is there a way to do this with the firewall?  TCP is blocked on the firewall, but UDP is not.  Thats the only restrictions I have in place.

      I had asked the question above on another forum and they gave me the following:

      OPT1 Firewall

      Rule 1:

      Action: Pass
      Interface: Opt1
      Protocol: TCP
      Source: TYPE = Single Host or Alias ; ADDRESS = 192.168.0.10 / 32
      Source Port Range: FROM = 135 ; TO = 135
      Destination: TYPE = Network ; ADDRESS = 10.1.10.0 / 24
      Destination Port Range: ANY
      Description: Allow My Network to Access files on other network

      Rule 2:

      Action: Pass
      Interface: Opt1
      Protocol: UDP
      Source: TYPE = Single Host or Alias ; ADDRESS = 192.168.0.10 / 32
      Source Port Range: FROM = 137 ; TO = 138
      Destination: TYPE = Network ; ADDRESS = 10.1.10.0 / 24
      Destination Port Range: ANY
      Description: Allow My Network to Access files on other network

      Rule 3:

      Action: Pass
      Interface: Opt1
      Protocol: TCP
      Source: TYPE = Single Host or Alias ; ADDRESS = 192.168.0.10 / 32
      Source Port Range: FROM = 139 ; TO = 139
      Destination: TYPE = Network ; ADDRESS = 10.1.10.0 / 24
      Destination Port Range: ANY
      Description: Allow My Network to Access files on other network

      Rule 4:

      Action: Pass
      Interface: Opt1
      Protocol: TCP
      Destination: TYPE = Single Host or Alias ; ADDRESS = 192.168.0.10 / 32
      Destination Port Range: FROM = 135 ; TO = 135
      Source: TYPE = Network ; ADDRESS = 10.1.10.0 / 24
      Source Port Range: ANY
      Description: Allow My Network to Access files on other network

      Rule 5:

      Action: Pass
      Interface: Opt1
      Protocol: UDP
      Source: TYPE = Network ; ADDRESS = 10.1.10.0 / 24
      Source Port Range: ANY
      Destination: TYPE = Single Host or Alias ; ADDRESS = 192.168.0.10 / 32
      Destination Port Range: FROM = 137 ; TO = 138
      Description: Allow My Network to Access files on other network

      Rule 6:

      Action: Pass
      Interface: Opt1
      Protocol: TCP
      Source: TYPE = Network ; ADDRESS = 10.1.10.0 / 24
      Source Port Range: ANY
      Destination: TYPE = Single Host or Alias ; ADDRESS = 192.168.0.10 / 32
      Destination Port Range: FROM = 139 ; TO = 139
      Description: Allow My Network to Access files on other network

      Rule 7:
      Action: Reject
      Interface: Opt1
      Protocol: UDP/TCP
      Source: TYPE = Single Host or Alias ; ADDRESS = 192.168.0.10 / 32
      Source Port Range: ANY
      Destination: TYPE = Network ; ADDRESS = 10.1.10.0 / 24
      Destination Port Range: ANY
      Description: Reject anything else but allowed traffic between explicit src & Dest

      Rule 8:
      Action: Reject
      Interface: Opt1
      Protocol: UDP/TCP
      Destination: TYPE = Single Host or Alias ; ADDRESS = 192.168.0.10 / 32
      Destination Port Range: ANY
      Source: TYPE = Network ; ADDRESS = 10.1.10.0 / 24
      Source Port Range: ANY
      Description: Reject anything else but allowed traffic between explicit src & Dest

      Rule 9:
      Action: BLOCK
      Interface: Opt1
      Protocol: UDP/TCP
      Destination: TYPE = ANY
      Destination Port Range: ANY
      Source: TYPE = ANY
      Source Port Range: ANY
      Description: DROP Remaining packet

      WAN FIREWALL:

      Action: Pass
      Interface: WAN
      Protocol: TCP
      Source: TYPE = ANY
      Source Port Range: 1723 (PPTP)
      Destination: TYPE = ANY
      Destination Port Range: ANY
      Description: Allow PPTP connections

      Action: Pass
      Interface: WAN
      Protocol: TCP
      Source: TYPE = ANY
      Source Port Range: 443 (HTTPS)
      Destination: TYPE = ANY
      Destination Port Range: 443 (HTTPS)
      Description: Allow HTTPS connections

      Action: Pass
      Interface: WAN
      Protocol: TCP
      Source: TYPE = ANY
      Source Port Range: 80 (HTTP)
      Destination: TYPE = ANY
      Destination Port Range: 80 (HTTP)
      Description: Allow HTTP connections

      Action: Pass
      Interface: WAN
      Protocol: TCP/UDP
      Source: TYPE = ANY
      Source Port Range: 53 (DNS)
      Destination: TYPE = ANY
      Destination Port Range: 53 (DNS)
      Description: Allow DNS lookup

      Action: REJECT
      Interface: WAN
      Protocol: ANY
      Source: TYPE = ANY
      Source Port Range: ANY
      Destination: TYPE = ANY
      Destination Port Range: ANY
      Description: Rejects all ports

      LAN FIREWALL:

      Action: Pass
      Interface: WAN
      Protocol: TCP
      Source: TYPE = ANY
      Source Port Range: 443 (HTTPS)
      Destination: TYPE = ANY
      Destination Port Range: 443 (HTTPS)
      Description: Allow HTTPS connections

      Action: Pass
      Interface: WAN
      Protocol: TCP
      Source: TYPE = ANY
      Source Port Range: 80 (HTTP)
      Destination: TYPE = ANY
      Destination Port Range: 80 (HTTP)
      Description: Allow HTTP connections

      Action: Pass
      Interface: WAN
      Protocol: TCP/UDP
      Source: TYPE = ANY
      Source Port Range: 53 (DNS)
      Destination: TYPE = ANY
      Destination Port Range: 53 (DNS)
      Description: Allow DNS lookup

      Action: REJECT
      Interface: WAN
      Protocol: ANY
      Source: TYPE = ANY
      Source Port Range: ANY
      Destination: TYPE = ANY
      Destination Port Range: ANY
      Description: Rejects all ports

      Does this look right?

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

        You need to choose either source port or destination port for the rules.  Not both at the same time due to how NAT works.

        e.g.

        On LAN:
        Action: Pass
        Interface: WAN
        Protocol: TCP
        Source: TYPE = Network ; ADDRESS = 10.1.10.0 / 24
        Source Port Range: ANY
        Destination: TYPE = ANY
        Destination Port Range: 443 (HTTPS)
        Description: Allow HTTPS requests

        On WAN:
        Action: Pass
        Interface: WAN
        Protocol: TCP
        Source: TYPE = ANY
        Source Port Range: 443 (HTTPS)
        Destination: TYPE = Network ; ADDRESS = 10.1.10.0 / 24
        Destination Port Range: ANY
        Description: Allow HTTPS connections

        As to the sharing thing, you can simply restrict access between the 2 networks to only the specific file share host's IP.  However, I highly recommend that you actually work on Systems security to begin with.

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

          What would you recommend system security wise?  I just changed the way the firewall was, which fixed the wan issue.  There really isn't more I can see that has to be done.  Ports are closed from the outside other than HTTP, HTTPS, and DNS.  Any other recommendations?

          Also, do I need to have the PPTP port open on the WAN firewall if I'm using the built in PPTP with pfSense or is that automatically opened?

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

            Right now I have this on the PPTP VPN firewall rules, so would I need that for the WAN also?

            Action: Pass
            Interface: PPTP VPN
            Protocol: *
            Source: TYPE = PPTP Clients
            Source Port Range: *
            Destination: TYPE = LAN Subnet ; ADDRESS = 10.1.10.0 / 24
            Destination Port Range: *
            Gateway: 10.1.11.1
            Description: Allow PPTP Connections

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

              Lets forget about the second network issue for now.  I thought I had this firewall setup correctly, but its not working fully. I'm trying to check email, ex. pop.comcast.net via Outlook … Thunderbird... Doesn't matter what client.  Comcast is an example of the email server.  It uses Port 110.  I have 110 listed in the LAN and WAN, but its not letting me check it.  Same for FTP.  The FTP port 21 isn't in the screen shots because I added it after, but its the same settings as the others with the exception of the port... should be 21.

              Here is screen shots of the following rules I have set in place:
              LAN - http://delranems.org/chris/pfSense/LAN.png
              WAN - http://delranems.org/chris/pfSense/WAN.png
              PPTP VPN - http://delranems.org/chris/pfSense/PPTPVPN.png

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

                @cmb991:

                What would you recommend system security wise?  I just changed the way the firewall was, which fixed the wan issue.  There really isn't more I can see that has to be done.  Ports are closed from the outside other than HTTP, HTTPS, and DNS.  Any other recommendations?

                Also, do I need to have the PPTP port open on the WAN firewall if I'm using the built in PPTP with pfSense or is that automatically opened?

                On PPTP, yes, you need to allow PPTP port on WAN.  Also, the appropriate subnet assigned to PPTP clients need to have another set of rules to allow it access to your LAN(s).

                As for systems security, you can start by disable automatic file shares in windows.  Make sure all file shares require a username & password to mount.  Also, this means that all computer user accounts should have unique passwords assigned.
                Even common fileshares should have a fixed password/ username to ensure that unauthorized users don't gain access.  Only users who need access to the fileshares will hold the password.
                Alternatively, if you had set unique usernames and passwords for all clients, set the explicit sharing permissions and add each user account manually to be allowed to read/ write/ execute on the share.
                If you have a Domain and AD server, customized security can be loaded upon logon.  If not, registry scripts and vbscripts are a good way to securing the systems by blacklisting what the clients can access.

                Edit:
                Your PPTP rule on WAN is incorrect.  In this instance, the remote computer is the client.  Hence, the rule should have the destination port as PPTP.  Not the source port.

                You need to understand some basic networking concepts.  Basically, if you have a client and server hosting certain services, this is how the data flow occurs:
                Source –--> Destination format
                client (random port: 49152) –sends request for data--> server (service port: 80)
                server (service port: 80) --returns requested data--> client (random port: 49152)

                So you see, the server's port doesn't change.
                Data returns from the same port that it is requested from.  Since your PPTP server is the pfsense box, then remote clients will connect to the pfsense as the destination and the service port of 1723.  Similarly, your pfsense to send data back to the clients with the source port of 1723.

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

                  On the FTP issue, search the forums for "FTP helper".  The main issue is that port 21 is used to establish a connection.  Once that connection is established, the server & client negotiate to open up more ports for data transfer.
                  Unfortunately, since you only allowed 21, the data packets coming in on other ports are dropped by pfsense (it wasn't involved in the negotiation process and doesn't know what additional ports to allow through).

                  To help solve this, there is a ftp proxy which helps the firewall get involved in the negotiation process.  TBH, you seem like you need a real full UTM appliance with working Layer 7 more than a pfsense box if you want to be that anal on clamping down the connections.

                  IMO, you don't need such an anal WAN side ACL.  By default, due to how NAT works, the WAN already rejects incoming connections that are not initiated by a client on the internal network.
                  You can simply ditch the deny all rule on the WAN rules.  Your clients are already restricted in what connections are allowed to be initiated due to the LAN side rules.

                  Basically, you only need:

                  Allow source any, destination WAN address w/ port PPTP on the WAN rules list to allow the PPTP connections to be established.  If you need web access to the firewall, duplicate the rule for HTTP(s) instead of PPTP.  Ditto for SSH.

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

                    As for the PPTP issue, I already had seen that last night and changed it.  The other issue with the PPTP clients connecting but not being able to see anythign on the network, I had the PPTP server address the same IP as pfSense was.  Once I changed the IP to an unused IP and the network, everything went fine.

                    @dreamslacker:

                    As for systems security, you can start by disable automatic file shares in windows.  Make sure all file shares require a username & password to mount.  Also, this means that all computer user accounts should have unique passwords assigned.
                    Even common fileshares should have a fixed password/ username to ensure that unauthorized users don't gain access.  Only users who need access to the fileshares will hold the password.
                    Alternatively, if you had set unique usernames and passwords for all clients, set the explicit sharing permissions and add each user account manually to be allowed to read/ write/ execute on the share.
                    If you have a Domain and AD server, customized security can be loaded upon logon.  If not, registry scripts and vbscripts are a good way to securing the systems by blacklisting what the clients can access.

                    As for the system security, all of that has already been done a while ago when I first setup this network.  Security is setup on each folder that is shared out.  It goes by the username that the person is logged in with.  If they don't have access to that folder, it will just deny their access, it won't let them try to use a different username and password unless they log off and log back in as another user.  Even the printers require certain usernames to print to them.  I think security wise as for file sharing and internal networking, I am good.  The only time a user will be prompted with a username nad password is if they are connected via PPTP and are not on the domain, or they are connected to our network via wireless or wired and are not on the domain.

                    Now for the FTP issue, I'm not trying to be anal with the firewall.  I just don't want users playing games such as WoW or any type of high bandwidth usage game.  So I figured if I block all incoming connections other than what I allow, it will prevent them from doing so unless the game uses port 80 as a fallback such as AIM or Skype or Yahoo do.

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

                      Right.  That all looks fine.  The thing is, if you block the outgoing connections on other ports, then it follows that the games will be blocked.  By virtue of the NAT, a client must open an outbound connection before a remote host can pass through on the WAN.
                      Since you're already blocking the "illegitimate" connections going out (on your LAN side block all), it follows that you don't need to restrict on the WAN side.  You just need to remember that connections are a two-way thing.
                      The restricting on the WAN side is more useful for PBR and perhaps, to stop attacks on the WAN.  For the latter, using an IDS like SNORT with accompanying rules as a IPS is probably more useful.

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

                        So what you are trying to say is just remove all of the rules on the WAN side, including the block all?  Then, in theory, I wouldn't have to open a port on the WAN side since there is no block and just manage the firewall mostly on the LAN side?

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

                          I also can't seem to ping … ex. DES-DC4, but I can ping its ip.  Am I missing a port?  I don't see any that I could be missing..

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

                            @cmb991:

                            So what you are trying to say is just remove all of the rules on the WAN side, including the block all?  Then, in theory, I wouldn't have to open a port on the WAN side since there is no block and just manage the firewall mostly on the LAN side?

                            Yes.  In effect, you remove all the WAN side rules including the block all except for services you need to specifically allow on WAN.
                            Such rules that need to be there would be OVPN allow rule and port forwards (NAT) rules.
                            Also, if you need to allow WebGUI access remotely, then you need to allow HTTP/ HTTPS (depending on which you use) destined for the WAN address as well.

                            What can't you ping?  If you want to ping the WAN address, you need to add an allow rule on WAN for ICMP.

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

                              Sorry, I forgot to finish that statement.  I connected via PPTP and I'm able to ping an ip (10.1.10.4) but when I try to ping des-dc3 or any other name, its unable to reach the destination.  I thought maybe I'm missing a rule somewhere?  Or maybe my dns forward isn't right?

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

                                @cmb991:

                                Sorry, I forgot to finish that statement.  I connected via PPTP and I'm able to ping an ip (10.1.10.4) but when I try to ping des-dc3 or any other name, its unable to reach the destination.  I thought maybe I'm missing a rule somewhere?  Or maybe my dns forward isn't right?

                                Did you add an allow rule for the OpenVPN subnet to ping any destination?  Presumably, you did not include an allow all due to security.

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

                                  I have to allow OpenVPN even though I'm using the PPTP on pfSense and not OpenVPN?  Also, I can't seem to make an ftp connection to any ftp.  I tried ports 21, 20, 1023, 1026, 1027.  Should I just remove the block on the LAN and move it to the WAN?

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