Solved rdr dont work on my client machine

hello,is the firt time I had to say "the problem is my FreeBSD"..but well

the scenario is this, I have a proxy/firewall with PF , in the rules I had one to redirect all traffic for port 53 to my internal dns server
so no matter if the user change his dns in network settings always will pass from my dns server

Code:
rdr  on $int_if  proto { tcp , udp } from <red_local>  to any  port 53 -> 192.168.1.254  port 53

<red_local> is a table with the list of local ip that I want to have this redirect (to exclude servers and "special" users)

and my FreeBSD box is in that table...

I tested it with Windows machines and its works,no matter what dns i put, allways pass to 192.168.1.254
but my box not, respect %100 the /etc/resolv.conf file

and more, in tcpdump (in proxy) there is notting and 192.168.1.3 is my machine

Code:
tcpdump -i em1 -n -e -tttt src host 192.168.1.3 and port 53

when I change the src host I see the others machines redirecting to my internal dns
 
To get this straight, you have the rdr rule on some machine you use as firewall (let's assume ipv4 address 192.168.1.1) and expect it to redirect a connection coming from 192.168.1.3 to anywhere else port 53 to be redirected to 192.168.1.254.

If this doesn't work and you don't even see anything with tcpdump on the firewall, there's only one possible explanation: Your route "outside" from your client (probably the default route) doesn't have your firewall as a gateway. IOW, you somehow have a route to the outside world that bypasses the firewall. Check your routing tables and maybe try traceroute to some public address to see where your traffic is going. You might use some VPN tunnel or you indeed have a way outside from your local network around your firewall.
 
Code:
     Redirections cannot reflect packets back through the interface they
     arrive on, they can only be redirected to hosts connected to different
     interfaces or to the firewall itself.
pf.conf(5)
 
That's interesting, but then it shouldn't work for any client? Unless the windows clients tested are indeed in a different subnet on another interface. Still the traffic should be visible with tcpdump...
 
That's interesting, but then it shouldn't work for any client? Unless the windows clients tested are indeed in a different subnet on another interface. Still the traffic should be visible with tcpdump...

yes,in the windows client works fine
 
This doesn't really help. Maybe you can provide your network structure? What local networks exist (e.g. 192.168.1.0/24 seems to be one of them), what interfaces does your firewall have, which client is part of which network?

If you just have this one local network and it contains all your clients as well as the dns server, the rdr rule indeed cannot work at all, according to the manpage SirDice quoted.
 
To get this straight, you have the rdr rule on some machine you use as firewall (let's assume ipv4 address 192.168.1.1) and expect it to redirect a connection coming from 192.168.1.3 to anywhere else port 53 to be redirected to 192.168.1.254.

If this doesn't work and you don't even see anything with tcpdump on the firewall, there's only one possible explanation: Your route "outside" from your client (probably the default route) doesn't have your firewall as a gateway. IOW, you somehow have a route to the outside world that bypasses the firewall. Check your routing tables and maybe try traceroute to some public address to see where your traffic is going. You might use some VPN tunnel or you indeed have a way outside from your local network around your firewall.

Yes,I have the default route point to the firewall
 
I miss some information..sorry

the firewall is in the 192.168.1.1
the dns server is in a jail
inside the firewall with the ip
192.168.1.254

the firewall has two network interfaces,one is the 192.168.1.0/24 and other is one to the internet provider 200.41.xxx.xxx/255.255.255.248

and all my users had the default gw 192.168.1.1
 
I suggest you configure your DHCP service to provide the correct DNS address. Regular users are not allowed to change those settings, so there's no risk of anyone trying to use an alternate DNS. You can further enforce this by blocking all outgoing traffic from clients to the outside world directly (which is a good idea in any case). So even if they manage to change the setting they would simply get time-outs and fail to get it to work. This effectively forces them to always use your DNS server.

What are you using for DNS? BIND? You can easily configure that for a chroot(8) environment, making the jail unnecessary, and simplifying the configuration (KISS principle).
 
the dns server is in a jail
inside the firewall with the ip
192.168.1.254

So, I assume this doesn't use vnet, therefore the packet doesn't have to leave the firewall host again and the restriction from the manpage shouldn't apply.

Then, did you check the routing on your FreeBSD client? Either a redirection rule is applied (and then there's no way for a client to circumvent it) or it isn't.

From a security perspective: hosting services in jails on the firewall host isn't great. For good security, the firewall should be a separate box that only does the routing, rewriting and filtering. In a private/home installation, you don't want to have more than one machine running, so there's a "nearly as good" solution: Use a virtual machine for the firewall (using pci-passthrough for the network interfaces). Then, host services in jails on the host system, use the vnet option with epair(4) devices and configure bridges as needed.

This way, you can have your services in a different subnet than your clients, so there will be no doubt with rdr rules. You also achieve fine-grained control over which services can be accessed from which client, because all the traffic has to pass your firewall.

It's only "nearly as good" as a separate firewall host because there's no guarantee that you can't break out of a vm. But I'd say for a home installation, this is a fair deal.
 
I suggest you configure your DHCP service to provide the correct DNS address. Regular users are not allowed to change those settings, so there's no risk of anyone trying to use an alternate DNS. You can further enforce this by blocking all outgoing traffic from clients to the outside world directly (which is a good idea in any case). So even if they manage to change the setting they would simply get time-outs and fail to get it to work. This effectively forces them to always use your DNS server.

What are you using for DNS? BIND? You can easily configure that for a chroot(8) environment, making the jail unnecessary, and simplifying the configuration (KISS principle).

that's it!, only allow conections to port 53 to my dns server instead to allow to outside


for DNS I use bind, I dont hear about the bind and chroot metod,but I chequed out
thanks,and yes,the KISS principle rules

forget..the users can change the network settings..they are administrators!! yes is crappy but the it department is a mess away from my hands
 
for DNS I use bind, I dont hear about the bind and chroot metod,but I chequed out
thanks,and yes,the KISS principle rules

forget..the users can change the network settings..they are administrators!! yes is crappy but the it department is a mess away from my hands
So this isn't a private installation? Then at least have a vm (better some dedicated hardware) as a firewall. Of course it all depends on your actual security requirements. They might be quite low if any user has admin rights on his client. Still, a firewall should a) control *any* traffic between subnets and b) expose as little services itself as possible. Just my thoughts of course.
 
So this isn't a private installation? Then at least have a vm (better some dedicated hardware) as a firewall. Of course it all depends on your actual security requirements. They might be quite low if any user has admin rights on his client. Still, a firewall should a) control *any* traffic between subnets and b) expose as little services itself as possible. Just my thoughts of course.

yes,is not a private/home instalation, I would like to have some vm hosts,but the hardware is cheap..
and again yes,the users has admin rights but I found the solution that give SirDice , the rules in the PF allow only outgoing
traffic to port 53 to the internal dns, no more..so, if a client change their DNS wont have internet
also block external access to proxy ports except that point to my proxy
 
Back
Top