Filter on LAN



  • I know it's not possible at the moment to filter in OpenVPN connections (in fact there is no tun tab in firewall section), but should be possible to filter (in LAN tab) connections from some address in road warrior's pool to some IP,s/ports in LAN ? I've tryied it, and dont get it working, so i'm doing something wrong, or is not technically possible ?

    Thank youu!!



  • You cannot block on the LAN-tab connections NOT COMMING from the LAN-tab.
    What you can do is block traffic originating from the LAN-subnet destined for the VPN subnet.

    If you want to block your VPN from getting to the LAN subnet… just dont push a route for the LAN subnet and the VPN client will never even know that there is another subnet.



  • @GruensFroeschli:

    You cannot block on the LAN-tab connections NOT COMMING from the LAN-tab.
    What you can do is block traffic originating from the LAN-subnet destined for the VPN subnet.

    And this policy only applies to LAN tab ? in WAN this would be completly non sense …
    Is this a feature or some kind of limitation to be solved in future releases ?
    Lan tab seems to me the right central point to define access policies from many other subnets to LAN. 
    Then i guess that with IPSEC these type of lan access rules should be defined in ipsec tab.
    Sure i need some additional reading about filtering with pfsense.

    @GruensFroeschli:

    If you want to block your VPN from getting to the LAN subnet… just dont push a route for the LAN subnet and the VPN client will never even know that there is another subnet.

    I'm already doing the suggested routing trick, but is security by obscurity, and in my case not really obscure, because :

    I must grant access to a server in lan, but not whole subnet to one particular user. So i disabled the general push routes, and added to this user a custom push route to only this server. But the user can always add a manual route to the whole subnet, guessing that exist seeing the server ip address.

    Thank you anyway.



  • @jmhoms:

    And this policy only applies to LAN tab ? in WAN this would be completly non sense …
    Is this a feature or some kind of limitation to be solved in future releases ?
    Lan tab seems to me the right central point to define access policies from many other subnets to LAN. 
    Then i guess that with IPSEC these type of lan access rules should be defined in ipsec tab.
    Sure i need some additional reading about filtering with pfsense.

    Traffic is filtered on the Interface on which traffic comes in.
    So traffic comming in on the LAN-Interface will only be processed from the rules you define on the LAN tab.

    What do you mean in WAN this would be completly non sense?
    Do you mean that if you create a rule on WAN blocking traffic from the LAN?
    This would be nonsense.

    @jmhoms:

    I'm already doing the suggested routing trick, but is security by obscurity, and in my case not really obscure, because :

    I must grant access to a server in lan, but not whole subnet to one particular user. So i disabled the general push routes, and added to this user a custom push route to only this server. But the user can always add a manual route to the whole subnet, guessing that exist seeing the server ip address.

    Thank you anyway.

    Well if you have on the LAN interface a rule that only allows the server to talk back you limit the traffic to one-way.
    Even if the client adds a route manually he wont get an answer to requests.



  • @GruensFroeschli:

    Traffic is filtered on the Interface on which traffic comes in.

    well, i see that logic, no point here.

    @GruensFroeschli:

    So traffic comming in on the LAN-Interface will only be processed from the rules you define on the LAN tab.

    Surely i haven't understood well your sentence in your previous message.
    Maybe the best is try to clarify with an example.
    A traffic generated on a TUN net, with dest LAN net, if i'm not wrong :
    1: enters TUN interface (traffic come in, but no TUN tab)
    2: exits TUN interface
    3: enters LAN interface (traffic come in, with source vpn net and dest lan net)
    4: exits LAN interface

    So, whats the problem in filter this packet in point 3 ?

    @GruensFroeschli:

    You cannot block on the LAN-tab connections NOT COMMING from the LAN-tab.
    What you can do is block traffic originating from the LAN-subnet destined for the VPN subnet.
    What do you mean in WAN this would be completly non sense?
    Do you mean that if you create a rule on WAN blocking traffic from the LAN?
    This would be nonsense.

    so, i think, if the behaviour is the same to WAN tab,
    You cannot block on the WAN-tab connections NOT COMMING FROM the WAN-tab.
    Then, i think, external internet traffic is NOT COMMING FROM WAN tab, is COMMING ON WAN … so i cannot filter it (which is obviously false). So surelly i haven't understood well your sentence (my english is really poor, so better don't entry in a syntactic affair).

    @GruensFroeschli:

    Well if you have on the LAN interface a rule that only allows the server to talk back you limit the traffic to one-way.
    Even if the client adds a route manually he wont get an answer to requests.

    If traffic (TCP) is originated in VPN net, i guess that a state is mantained, and the return traffic is allowed, so you thing that explicitly denying that will do the job? (I tried it before do the post and don't worked for me, maybe i haven't do it well, but i put the rule in the first place …) I will try to capture some packets, maybe will help me to understand.

    Thanks for your help.



  • @jmhoms:

    Surely i haven't understood well your sentence in your previous message.
    Maybe the best is try to clarify with an example.
    A traffic generated on a TUN net, with dest LAN net, if i'm not wrong :
    1: enters TUN interface (traffic come in, but no TUN tab)
    2: exits TUN interface
    3: enters LAN interface (traffic come in, with source vpn net and dest lan net) <– NO
    4: exits LAN interface

    So, whats the problem in filter this packet in point 3 ?

    The problem is that the traffic seen from the Firewall is not entering the LAN interface in point 3.
    The Firewall filters against the outside.
    Not against the inside.

    @jmhoms:

    If traffic (TCP) is originated in VPN net, i guess that a state is mantained, and the return traffic is allowed, so you thing that explicitly denying that will do the job? (I tried it before do the post and don't worked for me, maybe i haven't do it well, but i put the rule in the first place …) I will try to capture some packets, maybe will help me to understand.

    I'm sorry yes you are right.
    I dont know what i was thinking when i suggested that ^^"
    This only prevents access from the LAN to the clients.

    I think what you are trying to do is not possible right now.
    Filtering OpenVPN is on the wishlist.

    Not pushing a route to the client for the rest of the network is so far your only "protection".
    But hey… how many users are out there that know how to add a route ;)



  • @GruensFroeschli:

    The problem is that the traffic seen from the Firewall is not entering the LAN interface in point 3.
    The Firewall filters against the outside.
    Not against the inside.

    I guess you mean that the filters are applied with out instead of in from the gui.
    And surely there is a good reason, so will browse the filtering section.
    I'm just curious, because i'm used to put the major part of custom rules with in policies.

    @GruensFroeschli:

    I'm sorry yes you are right.
    I dont know what i was thinking when i suggested that ^^"
    This only prevents access from the LAN to the clients.

    I think what you are trying to do is not possible right now.
    Filtering OpenVPN is on the wishlist.

    Not pushing a route to the client for the rest of the network is so far your only "protection".
    But hey… how many users are out there that know how to add a route ;)

    Good news that this is already in the whishlist. I'm new to OpenVPN, but very happy at the momment ("remote" is a good friend).

    The route solution is acceptable for some (dumb) users, and it's usefull in a really temporal way.
    Maybe to stay a long time, would be possible to add some pf rules from an script (gui independent), anyway have been doing setups in text mode for a long time before pfSense (and by the way i really miss rdr).

    GruensFroeschli, thanks for your time and help.


Log in to reply