Allow only established connections (incoming)

  • Hi,

    Am I right that the default behavior (without any rule) is to allow all incoming traffic?

    How can I allow incoming traffic that is a response(!) to an established outgoing connection only?

    How can I allow incoming connections that matche a specific port AND are a response to an established connection?


  • No!

    It happens by default..

    If I understand your third question.. Do you mean static port? Pfsense randomizes ports by default.. its a security measure. But maybe Im not catching your meaning.

    Pfsense by default is ready to go and totally secure. After the initial default setup you can safely surf without worry whether somebody will be able to come in from outside and ruin your day.

    Your clients on the LAN are another conversation.

  • @chpalmer said in Allow only established connections (incoming):


    ??? So all incoming traffic is blocked if no (really none) rules are defined?

    It happens by default..

    So all incoming traffic is blocked by default but all incoming established connections are always allowed?

    If I understand your third question.. Do you mean static port? Pfsense randomizes ports by default.. its a security measure. But maybe Im not catching your meaning.

    I want to make rules like: "Allow only incoming http and https (source port 80, 443) and only if it's a response to an established connection)" "drop all other incoming"

  • All incoming unsolicited traffic is not allowed by default.

    All outgoing traffic is allowed by default (there is a rule in place on the LAN interface.. again by default) and the return traffic is allowed.

    Pfsense is a stateful firewall.

  • @chpalmer What happens if I use multiple vlans? Wan to any vlan is still blocked and every vlan to wan traffic ist allowed?

    What happens if I apply a routing between two vlans. Can they communicate with each other unrestricted?

  • LAYER 8 Global Moderator

    Default rule is deny (just not shown in the gui), if you create a vlan its default is NO rules - so deny..

    You could have 1000 vlans behind pfsense, default for unsolicited traffic to your wan IP would still be blocked.. Nothing is getting to your networks behind pfsense unless you forward it.. If if the traffic is public behind pfsense and routed to you - still it would be denied without a rule allowing the traffic.

    Since your default rule on lan is any any, it would be able to talk to any vlans you create and get a response because the state was created - but the vlan would not be able to create unsolicited traffic to the lan from vlan X without you creating rules on the vlan X interface to allow traffic.

    What happens if I apply a routing between two vlans.

    This question seems to come up quite a bit, there is no need to create any routing in pfsense for networks/vlans directly connected to it... If you create vlan or even a native network on an another interface in pfsense - it will know how to route any traffic between networks its directly attached to. You would just need to create firewall rules to allow the traffic you want.. The only time routing comes into play is when some network X is not directly attached to pfsense.

  • @johnpoz where do I have to place the rule for incoming traffic to the vlan?

    As far as I understand rules that I add to the WAN tab will apply for incoming traffic from the internet and rules I add to lan will to outgoing. So should a rule added to a vlan apply for outgoing traffic of the vlan?

  • @johnpoz I read some more posts.

    If the informations I found are correct then firewall rules are applied if the data enters the interface. For WAN the default is block for lan the default is allowed.

    With two Vlans I have 4 interfaces with this default rules:
    WAN =deny all
    LAN =allow all (All traffic without a vlan tag goes here?)
    VLAN1= allow all
    VLAN2= allow all

    So connection from WAN to any other interface ist blocked but the connect lan, VLAN1, Vlan2 is not blocked and the communication between the three lans (lan, vlan1, vlan2) is not blocked.

    The easiest way is to block the internal ip adresses of the other lans for each lan. Like: block ip of vlan1 and 2 in lan, block ip of lan and vlan2 in vlan1, etc. This should do the work.

    Is this understanding correct? Thx

  • LAYER 8 Global Moderator

    Yes rules are evaluated as traffic enters the interface from the network the interface is connect too. They are evaluated top down, first rule to trigger wins, no other rules are evaluated.

    If you don't want lan to go to vlan1

    Then above your any any rule, put a block above that blocks source lan net dest vlan1 net

    Duplicated this for any traffic you don't want to allow... Simple way to do it if you don't want vlans to talk to each other is just create an alias with all the rfc1918 space in them, and put that above you any any rule that allows internet..

    Here is a typical setup to allow a vlan to talk to internet and pfsense for services but not any other vlans on your network.


    So my test vlan/network can ping pfsense test IP, can ask it for dns, can ask it for ntp.. Then all other access to firewall IPs is blocked (this prevents say hitting the web gui via your wan IP from this network)

    Then block access to any rfc1918 space (your other vlans)

    Last rule allows access to anything else... This basic sort of setup would allow a vlan/network to access services off pfsense (ping for connectivity check).. But block all other access other than internet - adjust as you want to allow this vlan to talk to your other vlans - putting those rules above your block to other vlans.

    This assumes your other vlans are using rfc1918 space.. You could just block access to pfsense wan address to prevent access to say your public IP for web gui... But easier to just use the built in this firewall alias that is any IP that pfsense might have.

    I like to use rejects on local side rules, no reason for the client to just retrans trying to get somewhere you are blocking - might as well just let them know right away they are not getting there.. This is normally fine locally, but not something you would ever want to do on your public facing interfaces.

Log in to reply