Hi, my dhcp configuration seems to be somewhat off 1) I don''t put dhcp on any interface, however, there is no problem starting dhcp client on my net interfaces eth0, eth1 2) shorewall isn''t "started" on eth0 because it detected there was no IP 3) When I plug in the network cable I guess netfilter isn''t fully limiting eth0? 4) At some point during the interface coming up, one stray packet from dhcp port 67, to my net ip port=68 arrives, this is then forwarded and appears to try and exit via the next entry in my default routing table (the route makes sense, but not why the packet is being forwarded when it''s destination is the eth0 ip ?) 5) Once the interface is up, my scripts start "shorewall enable eth0" and at this point I can''t repro the effect from outside using netcat... I''m kind of stumped on the details here. How should I configure shorewall so that it does restrict this interface listed as optional, which is down at shorewall start? Also how to block the stray packet which is bringing up my demand dial ppp link? I can see it on the forward chain, but I''m stumped figuring out how I should set a rule to target that? Any thoughts on why my stack tries to forward this one packet (addressed to the new eth0 ip)? Thanks Ed W ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2
On 04/19/2012 01:58 PM, Ed W wrote:> Hi, my dhcp configuration seems to be somewhat off > > 1) I don''t put dhcp on any interface, however, there is no problem > starting dhcp client on my net interfaces eth0, eth1 > 2) shorewall isn''t "started" on eth0 because it detected there was no IP > 3) When I plug in the network cable I guess netfilter isn''t fully > limiting eth0?No it isn''t. There is no difference in the filter rules for an optional interface when it is down as opposed to up.> 4) At some point during the interface coming up, one stray packet from > dhcp port 67, to my net ip port=68 arrives, this is then forwarded and > appears to try and exit via the next entry in my default routing table > (the route makes sense, but not why the packet is being forwarded when > it''s destination is the eth0 ip ?)Sounds like the ''local'' routing table hasn''t been updated yet by the DHCP client.> 5) Once the interface is up, my scripts start "shorewall enable eth0" > and at this point I can''t repro the effect from outside using netcat... > > > I''m kind of stumped on the details here. How should I configure > shorewall so that it does restrict this interface listed as optional, > which is down at shorewall start?There is currently no way to do that. Optional interfaces were created to allow multiple uplinks where a program like LSM can bring the links up and down, based on the ability to pass traffic through the link.> > Also how to block the stray packet which is bringing up my demand dial > ppp link? I can see it on the forward chain, but I''m stumped figuring > out how I should set a rule to target that?Do you block forwarded DHCP traffic?> > Any thoughts on why my stack tries to forward this one packet (addressed > to the new eth0 ip)?Again, sounds like the local routing table hasn''t yet been updated. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2
Hi> Do you block forwarded DHCP traffic?Well, that''s my conundrum. I have rules saying "any any 58", but those aren''t obviously limiting things. I *was* also using the DHCPfwd(ALLOW) action, but further down in my ruleset. I have since removed that while I experiment, getting confused on whether I tested this config.. More broadly I''m getting myself confused on where/how shorewall should generate certain rules so that I can check the iptables output rather than just measure the end result. I will come back to this later In the meantime I have limited PPP demand dial with this: pass-filter ''not port 68 and not(icmp[0]==3 && icmp[1]==3)'' The icmp port unreachable is the main thing for me. Basically my default zone rules "REJECT" the stray packet to port 68, which in turn generates the icmp port unreachable, which then triggers the demand dial. The above is an example of how tcpdump syntax to filter just certain icmp packets (mentioning this for the benefit of google, not you...)>> Any thoughts on why my stack tries to forward this one packet (addressed >> to the new eth0 ip)? > Again, sounds like the local routing table hasn''t yet been updated.I will look into this further in the future. Many thanks for confirming the basic problem Ed W ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2