I need to filter DHCP requests so that a dhcp server located on the lan of a specific port on a RUTX11 will not be reached from any client on any of the other ports. I have set the physical WAN-port to act as a LAN port and since this is bridged, between eth0 (LAN ports) and eth1 (WAN port), I presume it is possible to set up a filter. But how? I need to filter all UDP to and from ports 67 an 68 I think.
Hi,
Currently, your desired configuration seems quite confusing. Could you please explain the end goal you’re aiming for with the configuration? Are you intending to have a separate LAN network for the WAN port or something different?
Best regards,
Marijus
Yes, i agree it is confusing. I will try to explain: one vendor is using ip and ethernet in their own special way. They use a complete b-net (172.16.0.0/16) and one of the servers is also a dhcp server on this net. Everything is bridged and the dhcp server provides no default route to the clients. So it is impossible to connect that network to internet. What I have come up with is to bridge the network through the rutx11, making the rutx11 the dhcp server on the network, for the other ports, setting a range of dhcp adressess that very unlikely will collide on the 172.16 network and allowing terminals (e.g. a mobile) to connect to the internet simultaneously as connecting to the proprietary network, via wifi or even wired at any of the other ports of the Rut. At least I want to test if this is possible. The big problem then, is that the DHCP-server might answer before the DHCP server in the rut so I need to filter that traffic.
The simplest solution would be to put the relevant lan port of the RUTX11 in a separate vlan (3 ?), set it to off in vlan1 and untagged in vlan3, create a new wan interface with this eth0.3 physical setting and set the protocol to dhcp client.
This way it will acquire a 172.16.0.0/x address from the second dhcp server. You’ll then have to create a new zone in the firewall menu, enable masquerading or add routes.
The dhcp packets coming from 172.16 will be stopped at the eth0.3 interface level.
I have done several similar setups in the past (for stubborn Raymarine equipments on boats …) no issue to report.
2 Likes
I´ll give it a try. This is Garmin, but they seem similar stubborn.
This topic was automatically closed after 15 days. New replies are no longer allowed.