Hi guys,
I am sorry to ask such a stupid question but I am really lost and have absolutely no clue why it happens....
I am running a PPTP server using address pool 192.168.3.5-10 for the pptp clients. The local address of the pptp server interface is 192.168.3.1, dns is 192.168.3.1.
There is a masquerade for source 192.168.3.0/24 to the isp uplink port so the clients can access the internet and proxy-arp on the local lan port.
Thats a pretty standard config and works fine....
What I am trying to do, is to restrict some of the addresses from the lan range 192.168.1.0 so they can't be accessed form the pptp so I created a common drop rule on the forward chain for dropping 192.168.3.0/24 source and 192.168.1.X/24  destination and placed this rule before the "accept from 192.168.3.0/24" rule.
But that doesn't trigger! Any idea why? The active connections do have 192.168.3.X address and there is no other rule for 192.168.3.0 causing the drop to be bypassed - even when placed on the top of the forward chain, it does have no impact....
Where I am missing the point? Thanks!

If you want to block this type of traffic I think you have to block on input chain.

Hi guys,
I am sorry to ask such a stupid question but I am really lost and have absolutely no clue why it happens....
I am running a PPTP server using address pool 192.168.3.5-10 for the pptp clients. The local address of the pptp server interface is 192.168.3.1, dns is 192.168.3.1.
There is a masquerade for source 192.168.3.0/24 to the isp uplink port so the clients can access the internet and proxy-arp on the local lan port.
Thats a pretty standard config and works fine....
What I am trying to do, is to restrict some of the addresses from the lan range 192.168.1.0 so they can't be accessed form the pptp so I created a common drop rule on the forward chain for dropping 192.168.3.0/24 source and 192.168.1.X/24  destination and placed this rule before the "accept from 192.168.3.0/24" rule.
But that doesn't trigger! Any idea why? The active connections do have 192.168.3.X address and there is no other rule for 192.168.3.0 causing the drop to be bypassed - even when placed on the top of the forward chain, it does have no impact....
Where I am missing the point? Thanks!

Hi maara,
Are you trying to drop traffic to specific hosts on the 192.168.1.0/24 network?
If so then you need to remove the /24 from the destination address. For example, if you want to drop traffic to 192.168.1.1 then you need this rule: Another way to do this is to say that traffic coming from the PPTP interface cannot access this host, like this: hope that helps.
tslytsly

PS, input chain is only for traffic headed for one of the router's addresses, if the dst-address does not belong to the router then it goes in the forward chain.

maara,

Trust me and try what I said. Your PPTP clients connect to 192.168.3.1 which is an internal address of the router.
Traffic does not pass through forward chain.  I checked on one of my routers.

Hi everyone,

Many many thanks all for your response - it made me to realize few things...
1) There must be a "allow from 192.168.3.0/24" on the input chain otherwise it doesn't resolves at all
2) The filtering I need to do must be really on the forward chain as it "passes through the router" between the subnets
3) Its all about the routes and the implementation of the pptp client on the devices I tested on

First, I was trying on my ipad - the ipad was connected on the local wifi and even I have checked to route all the traffic to the vpn (expecting I will truly simulate the outside access), it simply doesn't work.. The internet access was through the vpn but the internal addresses were accessed outside the vpn, directly using my wifi, making me to think the rules are not being triggered (and in fact they were not)
Second, I was trying on my android phone using the LTE - works fine and all the rules are working as expected, unless I manually specify the route on the phone vpn connection to "192.168.3.0/24" - at this moment, the firewall rules are bypassed (still don't know why).

I made very basic mistakes but must say that they are still grey areas in understanding why it is as described above...