Re: tcp bad checksum on reply-to packets

2003-03-28 Thread jared r r spiegel
On Thu, Mar 27, 2003 at 02:31:00PM -0500, David Powers wrote: [ I was experimenting with a recent build of -current (3/25/2003) ... a tcpdump -vv on both ends showed ... do I just have a bad build of current? ] this might not be wholly relavant, but i was in a similar boat recently, expe

Re: L2 broadcast and NAT state

2003-03-28 Thread Trevor Talbot
On Friday, Mar 28, 2003, at 02:50 US/Pacific, Daniel Hartmeier wrote: And this is where your packet gets dropped, due to the M_BCAST flag: Just to make sure: the destination IP address of the ICMP echo reply is not a broadcast address on IP level, right? According to the networks and netmasks, it'

Re: another pf question

2003-03-28 Thread HKSPKS
Thanks for everyone who pitched in info, I appreciate it... I've been on a sort of quest to master pf in the past week, and things are going well. Adam Wenzel

Re: security at mac address level

2003-03-28 Thread Dries Schellekens
On Fri, 28 Mar 2003, Dries Schellekens wrote: > On Fri, 28 Mar 2003, Doros Eracledes wrote: > > > Is there a way to make sure that only requests > > from specific mac address can access my > > pf protected database server? > > May be if it's not possible using pf, i could use a level 1 switch? Yo

Re: L2 broadcast and NAT state

2003-03-28 Thread Daniel Hartmeier
On Fri, Mar 28, 2003 at 02:33:49AM -0800, Trevor Talbot wrote: > >And this is where your packet gets dropped, due to the M_BCAST flag: > > >You should see the counter increase in netstat -p ip output: > > Yep, this is it. Thanks for tracking this down. Just to make sure: the destination IP add

Re: L2 broadcast and NAT state

2003-03-28 Thread Trevor Talbot
On Friday, Mar 28, 2003, at 02:09 US/Pacific, Daniel Hartmeier wrote: The frame arrives at $ext_if, and enters if_ethersubr.c ether_input(). Since the destination mac address is ff:ff:ff:ff:ff:ff, the mbuf gets an M_BCAST flag attached. Due to this flag, the destination mac address is not compar

Re: security at mac address level (fwd)

2003-03-28 Thread Berk D. Demir
On Fri, 28 Mar 2003, Doros Eracledes wrote: > Is there a way to make sure that only requests > from specific mac address can access my > pf protected database server? This is something out of pf's scope. You can consider using a bridged firewall setup and enforce layer2 access control via brconfi

Re: L2 broadcast and NAT state

2003-03-28 Thread Daniel Hartmeier
On Fri, Mar 28, 2003 at 01:37:10AM -0800, Trevor Talbot wrote: > >Are you running a bridge, or just IP forwarding? > > Just IP forwarding. > > The device does IP forwarding as well. It has been configured to > forward a set of IPs ($problem_addr among them) to the ethernet link > connected to t

Re: L2 broadcast and NAT state

2003-03-28 Thread Trevor Talbot
On Friday, Mar 28, 2003, at 00:14 US/Pacific, Daniel Hartmeier wrote: On Thu, Mar 27, 2003 at 05:17:30PM -0800, Trevor Talbot wrote: $ext_if: mac broadcast: $remote > $problem_addr: icmp echo reply pflog0: pass in on $ext_if: $remote > $problem_addr: icmp echo reply ..and that's the last I see o

Re: security at mac address level

2003-03-28 Thread Dries Schellekens
On Fri, 28 Mar 2003, Doros Eracledes wrote: > Is there a way to make sure that only requests > from specific mac address can access my > pf protected database server? > May be if it's not possible using pf, i could use a level 1 switch? pf(4) filters at layer 2 (IP) and 3 (TCP, UDP, ...). If you

security at mac address level

2003-03-28 Thread Doros Eracledes
Is there a way to make sure that only requests from specific mac address can access my pf protected database server? May be if it's not possible using pf, i could use a level 1 switch?

Re: L2 broadcast and NAT state

2003-03-28 Thread Daniel Hartmeier
On Thu, Mar 27, 2003 at 05:17:30PM -0800, Trevor Talbot wrote: > $ext_if: mac broadcast: $remote > $problem_addr: icmp echo reply > pflog0: pass in on $ext_if: $remote > $problem_addr: icmp echo reply > > ..and that's the last I see of it. This is from a -current snapshot, > early March. > > W